tline_terrain_demo

Cart File | Forum Post |

	More cartridges by Powersaurus

More Cartridges [View All]

 

tline_terrain_demo

by Powersaurus

Cart #tline_terrain_demo-0 | 2024-03-10 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

5

Tline Terrain Demo

Worms/Scorched Earth deformable/destructible terrain demo.

Arrow keys move target
X to destroy terrain
O to toggle debug mode, showing the vertical slices.

Maybe of use to someone?

For a long time I have wondered how to make Worms/Scorched Earth style terrain and make it work reasonably well. My first ever (unreleased) game on pico-8 was a Worms clone, that used a 2D array of pixels and pset to draw the terrain. It blew the CPU budget and was slooooooow.

Micro Murder on Pico-8 managed a really slick solution drawing circles over the top of the terrain, but I wondered if there was another way. Fast forward some years and I'm still thinking about it. Most discussion about this type of terrain suggests some form of bitmap to store the terrain.

This implementation uses a 2D array of vertical slices, then uses tline to draw a bit of the texture for each vertical slice. An explosion either shrinks one end of a slice, or carves it into two, removing the original slice. See the code for more.

Terrain graphics come from my game The Wizard Pig.

Nice demo, big Worms fan! With video memory remapping introduced in 0.2.4 (https://www.lexaloffle.com/bbs/?tid=45538) and now with high memory remapping in 0.2.6 (https://www.lexaloffle.com/bbs/?tid=140421) you could also remap to draw to upper memory instead of the screen (e.g. poke(0x5f55,0x80)), draw your terrain and add some circles etc. of your transparent color (default 0) on top, and then revert that while remapping the spritesheet to the same memory area (poke(0x5f55,0x60), poke(0x5f54,0x80)) and use spr or sspr to draw the results (with your transparency added) to the screen.

@kozm0naut

Thanks! I hadn't tried the memory remapping mainly due of lack of familiarity. Interested to give it a go now to see what the tradeoffs are.

Looks neat and it's a pretty clever idea, I did not expect slice-based terrain rendering would work that well.

How does the performance degrades over damage and scale with the terrain's dimensions? I have Worms Armageddon in mind and some of the weapons dig a lot of small pixels or circle (like the Molotov cocktail), I suppose that'd create a lot of pressure on the rendering?

Next step, the collision? ;D

@Eiyeron

Thanks!

The nice thing is performance actually gets better with more damage as despite there being more slices to draw, there's still a smaller area to draw. Certainly beats my attempt years ago using pset and a screen's worth of null checks :(

Video here shows a hacked together 4x as wide terrain and a smaller area carved out. CPU usage drops slowly as more terrain is removed.

I think this should work ok for collision too. If storing the positions of "damage" or destroyed terrain I think more work is required to keep track of what is overlapping in case an object is within more than one of these areas. With this approach, you lookup the slices for x value and then have a fixed set of terrain to test.

Looks great! Looks like you've got a promising prototype here. I also dig a lot the Worms-style texturing of the level, makes me want to throw bananas like it's 1999.