Log In  


Early version with opening doors but hardly anything else:

Cart #nuzukeheba-0 | 2019-05-06 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
12

Much later version with sliding walls, triggers, and enemy AI being tested:

Cart #sudugpir-0 | 2019-05-06 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
12

Severe performance issues in the latter.

12


1

The floor mapping is very fast (well, within pico limits!) - clever trick to iterate over 2 columns at the same time.


Thank you! most likely something I learned from the PCGPE article on texture mapping back in the day. In any case nothing as elaborate as the tricks @Powersaurus has used in his much faster implementation. Actually I submitted this following a twitter thread on how doors can be generalised in order to implement pushwalls


@Powersaurus main trick for the floor is to reduce resolution (every 4 pixels iirc).
You can do something similar by reducing horizontal resolution (say render every 2 pixels) but keep vertical resolution.


Unfortunately this wouldn't work for the game I had planned as it uses pressure plates as triggers to open doors / pushwalls, and they are already fairly difficult to tell apart with the current implementation. Low resolution screen and textures proved quite limiting for a 1st-person puzzle maze.


1

Tile based move then? quite frankly you will struggle keeping 30fps with what you have on screen without some more compromises :/


This is a typical case of cart before the bull, I carried on adding functionality without regard for performance and then it became quite difficult to isolate where it was going. A console-like development cycle (vertical slice at 10fps, optimise later) doesn't quite work in PICO-8.


On the other hand pico game codebase is small enough to go through extensive refactoring without loosing much time.
Having a slow but working game is still a good tactic.


Unfortunately in this case the codebase has become too large for me to manage on the embedded editor (I was working on this during my commute on a PocketCHIP). I need to find a way to do so on a bigger screen with a device I can still use on a crammed train. I tried running PICO-8 with UserLand on a Android tablet but unfortunately SDL binaries don't work with the X client. If Zep releases an Android cart player I may be able to side-edit the contents. It seems this is landing soon, I just hope it can load locally-stored carts.


1

hey! I was doing the same (until my pocktchip died!).
I was using a dedicated text editor (Textastic on iphone), automatically synced with pchip via ssh.
Once I was happy with code change, I swapped to vnc to see the results.
All that fully remote by connecting to the pchip wifi hotspot (eg pchip stays in the bagpack).

@Maca see my github for the proper wifi setup: https://github.com/freds72/pocketchip


Wow! That's a pretty awesome setup, with the additional plus of preventing confused looks from fellow commuters. I must try it and get some further use from my PocketCHIP.


1

This is really nice.


1

I'm impressed by the moving doors that will actually block where they should, and the comparative performance with mapped textures and everything.

Maybe someday I'll be able to render a 3-D scene.


1

@zlg: a raycaster is a great place to start! I'm happy to help explaining the code, @Powersaurus write-ups make for a great reference ( @Powersaurus">https://medium.com/ @Powersaurus) and Fabien Sanglard's Game Engine Black Book is also really useful (http://fabiensanglard.net/gebbwolf3d/index.html).



[Please log in to post a comment]