Jump to content
  • Advertisement
Sign in to follow this  
lordloxley

2D on DirectX9 multiframe sprite

This topic is 3526 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

Hi, I've just picked up some books and various online tuts on 2D games using D3D 9. The consensus is that the best way to do that is with textured quads (as opposed to using the "new" 3dSprite interface) Well, I haven't work with DX for a while (more than 5 years). Last time the approach to animate a multiframe 2D sprite was to have a bunch of small surfaces with a frame each. I haven't been able to recreate that functionality with the textured quad approach. I've come up with a sprite class that holds one large texture (image)with all the sprite's animation frames in it and then on each render cycle I calculate the correct coordinates to draw to the scene (probably somebody already done it this way). My question: is there a way to load a large image then pick small frames inside and store them in small textures or whatever object is needed, so the engine don't have to calculate the frame on each cycle. If not, doesn't the old approach was faster? I mean, 1 128x128 image + calculations vs 9 32x32 images and no calculations. (assuming a 9 frame sprite) As an analogy, the old way was like having 9 rubber stamps and use one on each cycle. Now you only have a big stencil with 9 images and you have to move it around on each cycle to get the correct image and paint just the selected frame on the scene. Thanks for any help you can provide.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by lordloxley
Hi, I've just picked up some books and various online tuts on 2D games using D3D 9.

The consensus is that the best way to do that is with textured quads (as opposed to using the "new" 3dSprite interface)
Not nessecarily, ID3DXSprite is plenty fast for most uses. The only real reason not to use it is if you need to integrate your sprites with other parts of your game engine in some way, or you have non-standard usage patterns which would make your own version more efficient.

Quote:
Original post by lordloxley
Well, I haven't work with DX for a while (more than 5 years). Last time the approach to animate a multiframe 2D sprite was to have a bunch of small surfaces with a frame each.

I haven't been able to recreate that functionality with the textured quad approach. I've come up with a sprite class that holds one large texture (image)with all the sprite's animation frames in it and then on each render cycle I calculate the correct coordinates to draw to the scene (probably somebody already done it this way).

My question: is there a way to load a large image then pick small frames inside and store them in small textures or whatever object is needed, so the engine don't have to calculate the frame on each cycle.

If not, doesn't the old approach was faster? I mean, 1 128x128 image + calculations vs 9 32x32 images and no calculations. (assuming a 9 frame sprite)


As an analogy, the old way was like having 9 rubber stamps and use one on each cycle. Now you only have a big stencil with 9 images and you have to move it around on each cycle to get the correct image and paint just the selected frame on the scene.

Thanks for any help you can provide.
It's certainly possible, you can just create multiple smaller textures, and use UpdateSurface, StretchRect, or just Lock, memcpy and Unlock to update the smaller textures.
However, that'll be terrible for performance; the key thing to getting good performance in D3D is reducing the number of batches (DrawPrimitive / DrawIndexedPrimitive calls, basically). If you have multiple textures, you can only draw one or two sprites at a time. If you have most or all of the sprites on one large texture, you can draw every single sprite in a single draw call.

Internally, ID3DXSprite manages a large dynamic vertex buffer, which it Lock()s when you call Begin(), adds to when you call Draw(), and Unlock()s and renders when you call Flush() or End(). That's pretty much the best you can get for performance - you'll almost certainly be faster locking a vertex buffer every frame and using that, rather than making multiple DrawPrimitive calls. I made a Journal Entry about all this a while ago, which may be of interest.

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!