Log In  

Cart #demo_realtime_sdf-0 | 2021-10-23 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
11

The final image is an adaptation of the image from the Principles of painting with math tutorial by Inigo Quilez.

I'm using fixed time-steps and the animation is intentionally a bit slow so "real time" might be fudging the truth a bit but I thought I wouldn't be able to animate these things at all and it turns out I was wrong. I just needed to trade off time for space in time honoured fashion. That's why there's a "loading screen" at the start: most of the time intensive calculations are being done up front. I used the SDF utility I posted the other day—not strictly necessary of course, you can just write the functions directly—to create all the signed distance functions used for the animations and then converted them to arrays by pre-calculating all the distances and turning distance checks into a simple table lookup.

This animation uses 8 such tables and takes up about 661kB (including all the code, other variables, etc.) so fits fairly comfortably in the 2MB of available lua memory.

This is mostly a proof of concept thing so the code isn't super well documented or elegant and I'm kind of just manually stringing together all the individual animations. Improvements could certainly be made but overall I'm pretty happy with how it came out.

Ideally I'd like to be able to generate the SDFs and convert them to tables from a separate cart (or another language/external tool/whatever) and export the data so it could be used in other carts. I don't know much about image/data compression algorithms so if anyone can point me towards one that might be suitable it would be greatly appreciated.

  1. The data is a 1D array of distances—which can be fractional—so each array stores a full 32-bits per pixel for every pixel on the PICO8 display. It's not image data as such so there's no requirement for it to be viewable as an image, though that might be neat.
  2. I'm not too worried about how long it takes to compress the data but fast decompression with a low-ish token count would be great.
  3. By the same token, I don't necessarily need optimal compression. Good enough is...good enough.

I thought about run length encoding but I don't think distance fields are good candidates for that in general since many rows change value every pixel.

Anyway, I hope you enjoy it. Comments, criticism, suggestions all welcome!

P#99070 2021-10-23 17:33

1

woah

P#99102 2021-10-25 02:49
1

W O A H H H

P#99121 2021-10-25 18:49
1

So I've spent a couple weeks learning about and playing around with compression so thought I'd post an update. I'm updating in a comment rather than the post itself because the animation is not exactly the same as the original. In particular, the palm tree sdfs do not compress well and wouldn't fit on the cart. So this version of the animation stops earlier than the one in my original post. But it nearly eliminates the loading time since decompressing the data is much faster than generating it in the first place.

Cart #compressed_sdf_animation-0 | 2021-11-05 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
1

I'll probably write a separate post on the compression itself on the off-chance anyone is interested, including the fact that I can actually fit more on the cart by compressing less which was entirely counter-intuitive. But that's for another day.

P#99638 2021-11-05 18:20

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 19:16:21 | 0.013s | Q:24