How To: Worms' destructible terrain

Simple way would be to update a mask bitmap.

Could you elaborate?

Create a 1-bit bitmap/texture for your asteroid; set opaque pixels to 1 and the rest to 0. When you shoot at the asteroid, use this bitmap for precise collision detection; it's only a collide if it hids the asteroid's bounding box/circle and it hits a solid pixel on this bitmap. Swept tracing might be required for fast-moving bullets, so they don't skip over single pixels.

When the asteroid is hit, draw a circle of 0s around the point that was hit; this erases some of the mass of the asteroid. You may wish to keep a count of opaque pixel for the asteroid, and decrement it whenever you erase a "1" pixel from the bitmap. You might want to do disjoint-set tests and make your asteroid break into smaller pieces, then just destroy outright any pieces under a size threshold (say, 20 opaque pixels).

Interesting, so it is possible.

A bitmap is an image type? I've heard the term several times before but I never knew what it meant, is it something you set with code or is a property of the loaded texture?

Do you think this could be implemented along with a physics library(Box2D)?

Draw a circle of 0s? I don't get this part I draw several small sprites? I draw a circle-shaped opaque sprite on the spot? Would this mean impact 'holes' can't vary in size/I'd have to make several different opaque circle sprites for the different impact sizes?

Disjoint-set tests? What's that?

Using this method would allow the following?
Say a large asteroid is shot through being divided into two, the two separate parts would then become two separate objects?
Destroyed parts of an asteroid would no longer count for collision?

Thanks.

Quote:

Original post by Antonym Interesting, so it is possible.

Of course it's possible. Worms did it :)

Quote:

A bitmap is an image type? I've heard the term several times before but I never knew what it meant,

That's what Google or Wikipedia is for.

Quote:

is it something you set with code or is a property of the loaded texture?

It depends what "loaded texture" means for you; in particular, what API you're using.

Quote:

Do you think this could be implemented along with a physics library(Box2D)?

It depends what you think "this could be implemented" means, and "along with". There's nothing about using a physics library that would prevent you from doing anything with bitmaps. There's also not likely to be anything in the physics library that would help you do anything with bitmaps.

Quote:

Draw a circle of 0s? I don't get this part I draw several small sprites? I draw a circle-shaped opaque sprite on the spot?

You draw a circle of 0 bits on the 1-bit bitmap/texture.

Basically, every pixel of the 1-bit texture corresponds to a pixel of the actual terrain, but just records the binary information "is this part of the terrain solid?". When you hit something with a weapon, some region (typically circular or something similar) becomes non-solid (because it was destroyed), so you set all the corresponding bits to 0, meaning "no, this little bit is not solid any more".

Quote:

Would this mean impact 'holes' can't vary in size/I'd have to make several different opaque circle sprites for the different impact sizes?

You could do it with sprites (in a 1-bit texture, "opaque" has little meaning, everything is basically just either black or white), or with some kind of graphics primitive, depending.

Quote:

Disjoint-set tests? What's that?

A test to see whether or not a set is disjoint. The set in this case is the set of still-there parts of the asteroid. Disjoint basically means "in more than one piece". If you can't trace a path through the asteroid from each pixel to each other pixel, then it isn't all in one piece. Which means you might want to start treating each piece as a separate smaller asteroid.

Quote:

Using this method would allow the following? Say a large asteroid is shot through being divided into two, the two separate parts would then become two separate objects? Destroyed parts of an asteroid would no longer count for collision?

That's exactly the idea. Although the "destroyed parts no longer count for collision" is already accounted for by the bitmap technique, assuming you're doing per-pixel collision.

If you dont know what a bitmap is, then you should probably try to learn easier things? Do you know how to code at all? I've just never heard of even a non-programmer, not knowing what a jpeg, or bitmap is.

I am using DirectX.

So a bitmap is just an image format like jpeg, png etc?

What I meant with the physics library is, right now I detect my collisions using a physics library, it uses shapes I define per object. I think this means I would have to abandon the physics library and code for pixel by pixel collision.

With the disjoint test how do you separate/divide the object? If the test would turn out to be true.

Quote:

Original post by Antonym So a bitmap is just an image format like jpeg, png etc?

bitmap

Your physics engine might have an option to alter the mesh of the objects it is testing for collisions. Instead of using the bitmap option you might go for the manipulation of the collision mesh. It depends on the physics engine...

I wouldn't abandon the physics library. You only have to start the pixel collision detection once you have a collision between a bullet and your bounding shape.

The problem I have with the physics library is that it goes like this.
You define a body for your objects. Then you define a number of shapes with vertices to build the 'shape' of the body the object will use. This is indeed the 'shape' of the object taken into account for the collisions. If I would make objects with destructible forms/'shapes' updating them to fit/accomodate to their new shape after a part of them had been destroyed with the collision would be I think quite the feat.

Sorry for the double post but I am still trying to implement this. So far I load a texture, a bitmap and get the bits however I don't know what's next. How do I read the bits to know which pixels are black or white. Is there an algorithm or something?

Here's the code I used to get the bits, a comment showing the part where I am stuck.

Every element of 'bits' represents a pixel. It is a DWORD (32-bits), i.e. a 32-bit RGBA (possibly in a different order) colour value.

Thanks I am able to read and edit the pixels of a texture now.

Now to draw the shapes/circles/impact holes on the texture. I've thought of a way to do it but have some doubts about it.

I have texture A, an object, and texture B, an impact hole. I could read texture B only taking into account say the white parts(The image being a black rectangle with a white spot in the middle for the impact) and passing those bits on to texture A. However how would I change the location of the object's texture where the impact hole bits are passed.

Is there a better method?