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 :).
Here is part 1,part 2, part 3 and part 4 of the write-up - if you have an hour, you can read them all in one go :).
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 :).
This is great—thanks for writing it up. Using a look-up table for every two-pixel pair is really clever.
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.
I don't know. At 30fps this demo looks fine (I tested it), and that means you have over 50 percent of the cpu left to make a game out of it. Really stunning work!
I always love good lighting system and this looks beautiful. stunning work!
Wow this is some code relevant to my interests that I definitely need to study. Amazing.
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!
I see you made the front page at hacker news. Good job! https://news.ycombinator.com/item?id=13598182
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?
@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.
FWIW, this chugs hard on the PocketCHIP. Pushes CPU to near 100% running 0.1.10c
Excellent demo, and I loved your write up.
Runs great in the browser @60fps on my phone. :-)
@morningtoast
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).
I agree...for games trying to push limits, it certainly won't be do-able. I didn't realize it wasn't running P8 and full speed...that's double unfortunate.
As much as I love my PocketCHIP, the more Pico-8 evolves the more it becomes less viable.
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.
That lighting effect is mind blowing.
I'm looking at that thinking... there's no way any computer or console could have had the processing power to pull that off, during the fake time period that Pico-8 would have been "out" :)
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.
[Please log in to post a comment]
