Jump to content
  • Advertisement
Sign in to follow this  
imnotbncre8ive

Few questions regarding D3D9 and D3DXSprite

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

I'm not a DirectX veteran, and I had a question or two that I hope you can help me out with. I'm writing the graphics portion for a 2D game engine. Don't need anything fancy for it, mostly just want to draw a lot of sprites, and preferably have it scale nicely if lots of particle effects are added later. In the middle of writing my code (using a vertex buffer), I came across D3DXSprite in the DirectX 9.0c documentation, and it definitely sounds really convenient. It even claims that it will handle the batching for me to minimize texture state changes. I had an idea of how to go about that, but I suppose I don't mind letting others do the work if it will perform just as well. My question is: is D3DXSprite fast enough to scale well with large numbers of draw calls and sprites, or should I just use vertex buffers and avoid having to rewrite code later? I am under the impression that using D3DXSprite is the fast and easy way but scales poorly, while vertex buffers require more management but runs a lot faster. Another thing that I came across was: if I made a vertex buffer of, arbitrarily, 1000 vertices so that I could draw at most 250 textured quads in a single draw call, and those vertices are set to default unit-width, unit-length, centered at (0,0) coordinates, can I use matrices to rotate/translate each quad differently and then draw them all in a single call? Or can you only apply a single composite transformation vertex per draw call. What I mean by that is, when you call SetTransform(myMatrix), does myMatrix apply to all 1000 vertices in my vertex buffer? Or can I use SetTransform(myMatrix2) and so that 500 of my vertex buffer vertices are transformed by myMatrix and the other 500 are transformed by myMatrix2? From what I understand, myMatrix will transform all 1000 vertices in the vertex buffer. If this is true, than setting default vertices and using matrix transforms on each set of four would result in another draw call for each quad I want to render, and that is not recommended for speed. What I am doing at the moment is simply Lock()-ing the vertex buffer (with D3D_DISCARD) and setting the vertex data manually, before calling DrawPrimitive once to draw all, let's say, 5000 of my vertices. Is this a bad way of doing this? I understand that Lock()s should be kept to a minimum, but in a game, I expect a significant portion of my vertex data to change between frames, and one of the Gamedev articles on using vertex buffers recommended using a Dynamic vertex buffer for this. I'm coding for DirectX Graphics 9.0c in C++. Thanks for all your time.

Share this post


Link to post
Share on other sites
Advertisement
ID3DXSprite used to be slow, but it's quite speedy now. Not sure how it scales when drawing tons, but a quick test of a huge particle system should answer that in a few minutes.

SetTransform will apply to all sprites. You could use a shader and an array of matrices, but it may not be worth the trouble. For sprites it's common to use XYZRHW coordinates where the coords are in pixels, and won't go through any vertex processing (neither fixed pipe transforms or vertex shader). Usually you just make a dynamic buffer and write new transformed data into it each frame.

Share this post


Link to post
Share on other sites
I see, so I won't know about D3DXSprite until I actually go and test its limits. I guess for now I will stick with vertex buffers since I am already part-way down that route. Perhaps later I will try D3DXSprite.

Thanks for clarifying the bits about 2D, vertex buffers, and transforms. Definitely clears stuff up for me.

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!