Inspired by the coding train video where he makes a falling sand game in JS. https://youtu.be/L4u7Zy_b868?si=YdIuL0No-k8LfCeD
It was fun to try my hand at it. I didn't include everything he did due to the processing limitation of the pico 8. But you can edit the code to change the size of the sand.
A nice application of the coding train video.
There are a few simple array optimization that can be done to speed up things :
in updategrid,
- you rebuild the tempgrid array at the start, and copy all the values form to grid to tempgrid one by one
- you modify tempgrid with sand rule by looking at grid only
- you copy all the values of tempgrid to grid
It is possible to get rid of the two array values copying and of the array creation :
in _init(), create grid and tempgrid.
in updategrid()
- start with the sand logic, with a final tempgrid[x][y]=grid[x][y] if nothing has moved for the current cell.
- Exchange grid and tempgrid at the end (the array references, not the values)
grid,tempgrid=tempgrid,grid
That should probably be enough for 64x64 grid.
It is barely possible to do 30FPS 128x128 sand (others have done it) but it would need a rewrite with direct pixel manipulation using pokes and also use an alternative for flr(rnd(2)) that is pretty costly in resource if called for each pixel. You can for example create a reference random array in _init() and look into it for your random values.
Another trick I've seen is to leave a 1 pixel border of black sand (two blacks in the display palette) that stops the real sand from falling sideways off the grid or down below the screen, so all the border tests (things like x!=gridacross) can be removed for a bit more CPU saving.
Plus the real sand grid becomes 126x127 instead of 128x128. (arguably a cheat optimization).
[Please log in to post a comment]
