Spent this week making a little Worms/Scorched Earth terrain demo. Tried making one of these with my first ever #pico8 project and ran into massive performance issues due to using pset.

This uses tline and a 2D array of vertical slices. Destroying the terrain earth shrinks a slice, or cuts/slices it into two. Perf is good, as terrain is destroyed, there are more slices, but less to draw! Second gif shows this in action.

Code/cart is here https://www.lexaloffle.com/bbs/?tid=140579

Tline Terrain Demo (Worms/Scorched Earth terrain)

@Powersaurus don’t get it - why not drawing circles on top on the terrain?

@fsouchu @Powersaurus because then the time to draw each frame would go up linearly with the number of circles?

(Also it would make it harder to have a parallax background show through the hole, or to implement physics stuff like disconnected regions falling down)

@nicklockwood @fsouchu @Powersaurus I imagine it's also an issue for collision detection - instead of having to add a check for if you're in a "Hole" and figuring out where the "Hole" ends, you continue to check collision, and specifically gravity, against the "Next slice/piece of terrain that is in the direction of your movement.".
@AT1ST @fsouchu @Powersaurus I think that would be OK because you'd have the list of holes and could just do collision checks against the circles. Although then collision detection time would also go up linearly with the damage to the terrain, just like the rendering

@nicklockwood @AT1ST @fsouchu

Good discussion. I went with this (whilst knowing about the circles method), partly due to lack of familiarity with render-to-texture (which would allow for the parallax background), but also with keeping collisions in mind. I think this might be cheaper with more things colliding.

I haven't tried out the hi-mem/render-to-tex, but I'd like to see how it compares. I think it would have to be a lot of circles before it got expensive at least to draw.

...

@nicklockwood @AT1ST @fsouchu The point about falling terrain is a good one though - that's not something I was thinking of, but I think this method gives the flexibility to do that easily.

@Powersaurus @nicklockwood @fsouchu Just to clarify, I wasn't thinking of the terrain itself falling down and needing to collide with the other terrain, but the player or enemy going into the cavern, and then walking into a part of the cavern that has a gap in it...and needing to determine when they stop falling from them.

Like, the "J" shaped hole you have in the second video, with that small bend with some area to stand on.

@AT1ST @nicklockwood @fsouchu ah I see I think?

If you test for a collision with one circle, you still have to test others because of overlaps, even if one reports a collision. You might be able to fix that by dividing the space, but that does seem trickier.

@Powersaurus @nicklockwood @fsouchu Yeah, that was my concern with just using circles and iterating through them for collision; the bottom of one circle might be the top of another circle, or the mid-radius point of another, and so the first circle's bottom isn't the ground of that particular circle-group-thing.

@AT1ST @Powersaurus @fsouchu if you were going to render the terrain as a single large texture anyway, maybe a cheaper option would be to do collisions using pixels.

Assuming the background is a unique color (or has an alpha value of zero, or whatever) then you could just check if every pixel under the character is a background pixel or not.