So, I've been working on a game again (which now has a name: Dank Tombs), and it includes a really swanky real-time lighting engine. Working on it was a blast and I learned a lot of good stuff when optimizing it, so I decided to clean up the code, share it here and write a series of posts on it so that others can benefit as well :).

::

::

Yo dawg, I heard you like dynamic lighting and shadows. I like dynamic lighting and shadows too. Amazing work! Dat CPU usage, though... let's hope we can all maybe come together and find a way to optimize this, because it seems like it could potentially limit what more could be done with a game that uses it. I'm actually amazed you got it to work on PICO-8 at all to be honest, but if we can get that CPU usage down further, that would just be insane.

::

::

Indeed, one of the reasons I worked so hard to get it running in 60FPS was to make it usable for a more complex game at 30FPS :) The CPU usage also depends on the radius needed, and whether shadows are on or not (both adjustable), so even 60FPS might be salvageable.

::

::

Cool! Thanks for the write up. I didn't know the pico-8 simulated a memory space that you can peek and poke. Maybe we could do something cool with the audio with that knowledge too, maybe there are memory mapped registers for the sound card?

::

::

I've pretty much given up on thinking of PocketCHIP as a viable platform for PICO-8 games, though. The biggest reason being that the keyboard is very inconvenient for any game requiring even a bit of dexterity.

As it also turns out, it's not able to "emulate" PICO-8 at full speed, but that probably only matters for 1% of games and demos (like mine, heavily relying on Lua's execution speed being able to match the "official" PICO-8 cycle counts).

::

just tried on my phone (moto g, I think 2nd gen). shows the same cpu usage as my desktop (90%+ between the columns and the entrance) while being 2 or 3 times slower. having a reliable stat(1) would certainly help in that context...

regarding this particular (awesome) tech demo, showing it off at 60 fps might be misleading. the effect seems far more suitable to adventure or rpg than real arcade/action. so going for 30 fps seems like a no brainer.

::

The actual game is going the 2D Zelda route, with more focus on the puzzle aspects than action ones. For now, it's running 60fps, with the caveat that I want it to still work well when the 30fps slowdown happens.

The whole performance conundrum is interesting. The demo is running at 60FPS on all platforms where Lua itself is not a bottleneck - i.e. where the only limitations are PICO-8's artificial ones.

Problems start when Lua execution is actually slower than the artificial limits forced by PICO-8 - which certainly might be the case on a weaker phone going through all the layers involved in PICO-8's browser versions - where the Lua VM is emulated inside a Javascript VM (the number of layers of indirection boggles the mind).

I don't think it would be a problem if we had native PICO-8 versions for mobiles, but that'll probably be a while still.

::

Seriously though, this is exactly the kind of thing that makes me happy Pico-8 exists. You went through all this trouble because of the limitations, but you reached a result that is very interesting on its own merit and looks better than most 2d light solutions in games that didn't have any limitations. I mean, why would they try palette swapping if they're working on a modern engine capable of fancy techniques? But it turns out pixel art light seems to agree more with palette swapping.