Log In  

59

Cart [#37081#] | Copy | Code | 2017-02-02 | Link
59


EDIT: Part 2 of the article is now up!

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 :).

Read part 1 and part 2 of the write-up.

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 :).

lighting realtime demo


P#37083 2017-02-02 12:57

::

super cool shader!

P#37085 2017-02-02 13:09

::

This is great—thanks for writing it up. Using a look-up table for every two-pixel pair is really clever.

P#37090 2017-02-02 16:22

::

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.

P#37094 2017-02-02 21:40

::

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!

P#37096 2017-02-02 22:51

::

Now that's jawdropping, amazing demo!

P#37102 2017-02-03 02:09

::

I always love good lighting system and this looks beautiful. stunning work!

P#37103 2017-02-03 02:46

::

this is so epic!!

P#37104 2017-02-03 06:47

::

Wow this is some code relevant to my interests that I definitely need to study. Amazing.

P#37106 2017-02-03 08:06

::

Thanks for the kind words, everybody :)

@Scathe @bitJericho:

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!

P#37119 2017-02-03 19:29

::

I see you made the front page at hacker news. Good job! https://news.ycombinator.com/item?id=13598182

P#37291 2017-02-08 13:33

::

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?

P#37292 2017-02-08 14:08

::

@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.


P#37293 2017-02-08 14:42

::

FWIW, this chugs hard on the PocketCHIP. Pushes CPU to near 100% running 0.1.10c

P#37313 2017-02-09 14:07

::

Incredible!

P#37318 2017-02-09 17:42

::

Excellent demo, and I loved your write up.

Runs great in the browser @60fps on my phone. :-)

P#37337 2017-02-10 23:16

::

@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).


P#37389 2017-02-12 13:09

::

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.

P#37391 2017-02-12 14:27

::

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.

P#37395 2017-02-12 17:17

::

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.



P#37418 2017-02-13 08:04

Log in to post a comment

user:
password:

New User | Account Help
:: New User
X
About | Contact | Updates | Terms of Use
Follow Lexaloffle:
Generated 2017-02-23 18:28 | 0.090s | 1835k