Early version with opening doors but hardly anything else:
Much later version with sliding walls, triggers, and enemy AI being tested:
Severe performance issues in the latter.
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
[tweet]
@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.
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.
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.
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.
@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]
