Jump to content
  • Advertisement
Sign in to follow this  
DvDmanDT

[2d] destructable terrain/textures?

This topic is 4814 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone... I'm creating a 2d game at the moment (more like thinking about creating it).. Think Worms or even better: Liero.. I'm using Direct3d for this, but I want to be able to add OGL support later on.. Now, a map will have a foreground, a background, and it'll also have different materials (some map pieces will be easy to destroy, other harder, other impossible and so on).. So, how would I store this? The map could be rather big (say 8192x8192 pixels), so I would preferr to split it into several textures.. So that leads me to create the map as a grid system.. Anyway.. How would you go about handling destructable terrain in a case like this? * I have to store all materials somehow.. * Parts of the foreground may be blown away, but there can be additions to it as well So.. Should I just keep the background unmodified, draw it first, then draw the foreground over it, and just make the foreground a dynamic surface/texture with transparency in it, and lock/modify/unlock each time something happends? Any comments and/or directions appreciated..

Share this post


Link to post
Share on other sites
Advertisement
I would use an orthogonal projection matrix, and render the layers in front-to-back order, to reduce overdraw. I'd split the terrain into a bunch of reasonable sized dynamic textures (512x512 or something similar - be sure to check the card supports the size you try to use), and lock the texture to edit the alpha values to determine if a pixel is transparent or not.
When you lock the texture, make sure to lock the smallest possible region, to reduce the amount of data you have to copy around at Lock() or Unlock().
If you split the terrain into several smaller textures, then scolling shouldn't be too much of a problem. Obviously larger textures mean more efficient rendering, but more memory usage. A 8192x8192 map viewed at 800x600 might need 2x2 4096x4096 textures displayed at once in it's worst case, but it might only need 4x3 256x256 textures.

Share this post


Link to post
Share on other sites
Ok, this raises a few questions:

* What's the largest recommended texture size?
* What pool should I store it in (when using DX)? managed?
* How would I do that front first, then back rendering? ZBuffer? Not possible if I use orthogonal projection? Or did I miss something here?
* When doing that orthogonal thingy, do you mean I should use D3DFVF_XYZRHW or do you mean something else?

Thanks!

Share this post


Link to post
Share on other sites
Quote:
Original post by DvDmanDT
* What's the largest recommended texture size?
* What pool should I store it in (when using DX)? managed?
* How would I do that front first, then back rendering? ZBuffer? Not possible if I use orthogonal projection? Or did I miss something here?
* When doing that orthogonal thingy, do you mean I should use D3DFVF_XYZRHW or do you mean something else?

I don't really know what the recommended texture size is, your best bet would be to try several and profile the results. I'd guess at 1024x1024 or 2048x2048.
If you're using a dynamic texture, you can't use the managed pool, so the default pool would be what you want.
Yes, you use the z-buffer to mask out what pixels don't need to be drawn. You can use the z-buffer with an orthogonal projection matrix, yes

By an orthogonal projection matrix, I mean use D3DXMatrixOrthoLH or D3DXMatrixOrthoOffCenterLH instead of D3DXMatrixPerspectiveFovLH or D3DXMatrixPerspectiveOffCenterLH.
The program I'm working on at the moment (a tile-based map editor) uses an orthogonal projection matrix. When I set up the matrices, I have this code:

// Setup matrix //
D3DXMATRIX matrix;
D3DXMatrixOrthoOffCenterLH(&matrix,0.0f,1024.0f,768.0f,0.0f,1.0f,100.0f);
pDevice->SetTransform(D3DTS_PROJECTION,&matrix);
D3DXVECTOR3 vEye(0.0f,0.0f,-50.0f), vAt(0.0f,0.0f,0.0f), vUp(0.0f,1.0f,0.0f);
D3DXMatrixLookAtLH(&matrix,&vEye,&vAt,&vUp);
pDevice->SetTransform(D3DTS_VIEW,&matrix);


That creates a viewing volume that looks 2D, uses a screen area of 1024x768, has a z-range of 1-100, and has the camera 50 units away in the Z direction.
An orthogonal projection matrix makes things look like they're not 3D by not making objects further away smaller. Think of it like how a CAD package draws the top, front and side views of something in wireframe mode.

Share this post


Link to post
Share on other sites
By recommended texture size, I meant more like.. What can I expect to work on everything worth supporting?

Anyway, thanks alot, you've been very helpful!

rating++

Share this post


Link to post
Share on other sites
Quote:
Original post by DvDmanDT
By recommended texture size, I meant more like.. What can I expect to work on everything worth supporting?
Every card supports at least 256x256 textures, but if a card only supports that texture size, you're unlikely to get anything else in your game working.
My Voodoo 2 had a maximum texture size of 1024x1024. I'd say that 1024x1024 would work nicely.

There was a site which has been mentioned here which has a database of graphics cards and their caps (including maximum texture size). The search feature is down, but you might be able to find the thread(s) via google.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!