 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| How To: Worms' destructible terrain |
|
 |
Antonym Member since: 8/5/2008 From: Monterrey, Mexico |
|||
 Posted - 2/7/2009 6:11:09 PM |
||||
| I was wondering, if any of you played the worms game the terrain was destructible, how did they do it? The reason I am asking this is because I want to do something similar I am trying to create an asteroids-like game and wanted the asteroids to not just get killed and spawn smaller ones but to actually get gradually destroyed with each shot, get chipped away. Shot paths with your ship through asteroids. If anyone has any info on the subject it would be greatly appreciated. [Edited by - Antonym on March 7, 2009 3:12:21 PM] |
||||
|
||||
|
dpadam450 Member since: 11/18/2005 From: Bellevue, WA, United States |
|||
|
Posted - 2/7/2009 6:13:19 PM |
||||
| Simple way would be to update a mask bitmap. |
||||
|
||||
|
Antonym Member since: 8/5/2008 From: Monterrey, Mexico |
|||
|
Posted - 2/7/2009 6:14:43 PM |
||||
| Could you elaborate? |
||||
|
||||
|
Wyrframe Member since: 6/29/2000 From: Canada |
|||
|
Posted - 2/7/2009 6:35:07 PM |
||||
| 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). |
||||
|
||||
|
Antonym Member since: 8/5/2008 From: Monterrey, Mexico |
|||
|
Posted - 2/7/2009 6:50:49 PM |
||||
| 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. |
||||
|
||||
|
Zahlman Moderator - Game Programming Member since: 1/9/2004 From: Toronto, Canada |
||||||||
|
Posted - 2/7/2009 7:17:11 PM |
|||||||||
Quote: Of course it's possible. Worms did it :) Quote: That's what Google or Wikipedia is for. Quote: It depends what "loaded texture" means for you; in particular, what API you're using. Quote: 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: 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: 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: 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: 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. As a general rule, if you post in For Beginners and your code contains the word 'char', you have a bug. std::string roxors teh big one one one one. "OMG! I'm so happy! I have "1 Friends"!!!" -- coldacid "Basically whenever you invoke the dread ellipses construct you leave the happy world of type safety." -- SiCrane "I mean, if you had sex for every time O'Reilly used the word Patriotism you'd be almost as awesome as Chuck Norris." -- tthibault <triforce101> uh im not a noob i finished the game |
|||||||||
|
|||||||||
|
dpadam450 Member since: 11/18/2005 From: Bellevue, WA, United States |
|||
|
Posted - 2/7/2009 7:57:31 PM |
||||
| 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. |
||||
|
||||
|
Antonym Member since: 8/5/2008 From: Monterrey, Mexico |
|||
|
Posted - 2/7/2009 8:11:04 PM |
||||
| 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. |
||||
|
||||
|
janta Member since: 2/7/2006 |
|||
|
Posted - 2/7/2009 8:29:42 PM |
||||
Quote: bitmap |
||||
|
||||
|
ernow Member since: 3/9/2001 |
|||
|
Posted - 2/8/2009 4:04:45 AM |
||||
| 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... |
||||
|
||||
|
Schildpad Member since: 1/18/2005 |
|||
|
Posted - 2/8/2009 4:42:27 AM |
||||
| 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. |
||||
|
||||
|
Antonym Member since: 8/5/2008 From: Monterrey, Mexico |
|||
|
Posted - 2/8/2009 4:52:21 AM |
||||
| 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. |
||||
|
||||
|
Antonym Member since: 8/5/2008 From: Monterrey, Mexico |
|||
|
Posted - 3/7/2009 3:39:05 PM |
||||
| 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. void Direct3D::EditTexture(SpriteInstance *sprt_instance) { LPDIRECT3DTEXTURE9 &tex = sprt_instance->sprt->tex; D3DLOCKED_RECT rect; int width = sprt_instance->sprt->width; int height = sprt_instance->sprt->height; DWORD* bits = new DWORD[width*height]; tex->LockRect(0, &rect, 0, 0); memcpy(bits, rect.pBits, sizeof(DWORD)*width*height); tex->UnlockRect(0); //What now? What do I do with 'bits'? How do I know which pixels are white or black? tex->LockRect(0, &rect, 0, 0); memcpy(rect.pBits, bits, sizeof(DWORD)*width*height); tex->UnlockRect(0); } |
||||
|
||||
|
Zahlman Moderator - Game Programming Member since: 1/9/2004 From: Toronto, Canada |
|||
|
Posted - 3/7/2009 7:56:16 PM |
||||
| 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. |
||||
|
||||
|
Antonym Member since: 8/5/2008 From: Monterrey, Mexico |
|||
|
Posted - 3/7/2009 8:10:03 PM |
||||
| 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? |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
