Hacker News new | comments | show | ask | jobs | submit login
PICO-8 Lighting: Part 2 – Stitching Lines Together (hackernoon.com)
82 points by springogeek on Feb 17, 2017 | hide | past | web | favorite | 12 comments

Light and shadows in 2D fascinates me. Even more than 3D. There are countless ways to optimizes stuff like this and, compared to 3D, you're actually able to get really atmospheric results even on low end devices. Stuff like soft shadows with shadow penumbra and antumbra are actually possible to implement with high quality without insane performance hits.

Thanks to the author for sharing the implementation step by step.

Here are some other fascinating examples of 2D light and shadow:






Your previous article made me remember about and subsequently purchase PICO-8. I've been hooked since then.

If anyone out there is considering buying PICO-8, go do it! It's so much fun.

Really good read. Now, I am going to refresh the profile page until part 3 appears.

Author of the article here, glad you liked it!

To save on the wear-and-tear on your F5/Cmd+R keys, the plan is for that to happen next Thursday.


Medium _does_ have RSS feeds...

That was a joke.

PICO-8 has 1MB of Lua RAM available, is this more efficient than precomputing the light levels/breakpoints and using it for each frame?

It was actually precomputed at one point, but there are two things that make it less appealing. They don't feature in the article until part #3, unfortunately.

The first is flexible range - the light has adjustable brightness which makes it bigger/smaller. The second is the flickering effect applied to each line. Both these things mean that any access to the precomputed table would have to be scaled anyway, which would remove most of its benefit - to the point where all it would save would be one subtraction (sqrt() is taken from a precalculated table in the final version).

Could you memoize the table for each brightness? (presumably flickering is +/- brightness).

Sure, it's possible, and flickering is indeed the same as scaling the brightness (but randomly each line). I was under the impression that the table needed would be too big, but now that I actually calculated it (max_range^2*light_levels), it's nothing back-breaking.

I'm concentrating more on the game right now than on making the engine even faster, but I'll try to look into before writing the next part - thanks!

Very cool demo. I remember RPGs on the SNES looking line this. I'm guessing that the colors on this are gamma corrected. Are you doing a linear conversion then going back to a gamma corrected palette when building the fills table?

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact