The Falling Sand game has been around a long time, but I didn't see a Pico-8 port.
The reason for that is: it's really hard to get a decent-sized grid to run at full speed on the Pico. This implementation runs a little slower than 15FPS (when running the simulation) on my machine, so it isn't quite as smooth as I'd like, but still pretty playable. In the future, I'd love to post a faster version, but I've hit a bit of a wall with the Lua optimizations I'm already aware of.
If you're not familiar with Falling Sand, the basic idea is that you're simulating a bunch of elements in a grid, where different elements react in different ways - oil floats on water, fire burns wood, plants grow when watered, and so on. It's fun to play around and build things, but there's no goals or progression, really.
Have fun!
a tradeoff i used for mine (which isn't as complete as i'd like) was to use the sprite sheet to represent where everything was, and then draw everything using sspr, which is much faster. unfortunately, the way i did it limited me to a maximum of eight materials (though i ran out of time to implement even that many before my submission date), and i see you have more.
Yours is quite fast - I'm pretty impressed! I liked the UI, too.
I couldn't determine if any of your elements react or decay - I think that's where most of my time is spent, as opposed to drawing.
Some of my inner loops are tight enough that the change from calling a custom function to aliasing peek/poke to local variables and calling them with the simplest possible pointer arithmetic was the largest savings, and accounted for half of the CPU time in early testing.
sand floats on water
I have found a bug where eventually there will be too many objects on screen and the game will crash. Not sure how to fix it but thought I'd just let you know
Pico-8 has limeted memory so I'll just cap it off before memory runs out.
Here's a question for axnjaxn how do you check for neighbouring
particles?
I knew this could be done at a faster level and higher resolution. Nicely done, @Matcha155.
I think what will really help here is to turn the elements into components. That is no X/Y coordinates are recorded in any of the dots, instead the screen itself is scanned and reacts according to the medium placed upon it.
Doing so you could fill the screen with these elements and there would be no speed change whatsoever.
I did this years ago with my fireball program for instance.
https://www.lexaloffle.com/bbs/?tid=27955
Likely this can also be done at least for wood and water.
Still I'm starting to use Löve instead of pico-8 and there is no pget method in löve so how do I do it without pget?
[Please log in to post a comment]
