EDIT: All articles are now up, see below for links!
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 :).
This is just a demo, so most of the cart is showing off the tech.
Controls: (O)/(X) change the light radius, d-pad walks around
If you want to explore the cartridge for yourself, the best place to start from is probably _draw() - it references all the interesting stuff and clearly shows what order things happen in.
The code is under a CC-BY-SA license, so feel free to repurpose stuff :).
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.
Thanks for the kind words, everybody :)
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.
I'm open to more optimizations, though!
@bitJericho Yup. To be honest, I never expected the article to have "mainstream" hacker appeal, so I'm... pleasantly surprised, to say the least :).
@enderoute As far as I know, nobody found a way control the audio output itself directly (which would let us do all sorts of crazy stuff!).
But you can directly change the SFX memory, which is useful for dynamic pitch (I think Pico Racer uses this for the classic 8-bit engine revving effect) or packing more SFX into the limited space.
That's unfortunate, thanks for the info.
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.
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.
Now do normal mapping! =D
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.
Log in to post a comment