2D graphics: Surface copies vs. Sprites
Author
I recently broke into the DirectX world doing 2D graphics. I wrote some graphics functions that create surfaces and then copy directly from those surfaces to the back buffer. It seems to be very efficient with around 650 frames per second with 100 "game objects". I am pretty sure that this graphics routine will be good enough for my current project, but I have more projects planned down the road. So here is my question:
I have seen that DirectX has a "sprite" helper class that is based not off of surface copies, but "textured quads" (ie. square meshes with a textured overlay). Aside from implementation (coding) differences, what makes one method different from another? Are the sprites made using the "sprite" helper function faster than surface copies? Is the difference in speed significant or marginal? Are there any other advantages to using the "sprite" helper class or creating my own textured meshes? At some point I will be doing some 3D graphics, but for now the games that I am making are 2D.
My current setup is that I am programming using VB.NET with DirectX 8. This has proven difficult because VB.NET can't use pointers the way that DirectX8 for VB (VB6) requires. I got around the issue by making a few C# functions that just take my VB.NET input and convert it to the necessary formats for DirectX8. For my program, an offscreen surface is made for each game object type, and then the DirectX8 "copyrects" function is used to copy frames from those surfaces to the backbuffer.
Using CopyRects should be reasonably efficient. Using sprites won't necessarily be faster.
One advantage of sprites is that they can be transformed (rotated, scaled, ...), and do other things that you can do in 3D but not with a simple rectangular copy. Whether that's of any help to you would depend on your app.
One advantage of sprites is that they can be transformed (rotated, scaled, ...), and do other things that you can do in 3D but not with a simple rectangular copy. Whether that's of any help to you would depend on your app.
Using the sprite class should be more efficient, but probably not by much. If you use the sprite class however, you get the benifits from doing 3D like free alpha blending and clipping, which you'd have to do manually with CopyRects().
I'd highly recommend going for the sprite helper class, or writing your own sprite functionality with a dynamic vertex buffer.
I'd highly recommend going for the sprite helper class, or writing your own sprite functionality with a dynamic vertex buffer.
Making explcit surface copies is risky. It might work very fast on one video card and very slowly on another that doesn't expose the buffers in the same way. The bottom line is that there is nothing standard about it so you don't know how it will work on a specific card. Using textured quads manually or via the Sprite class uses the standard 3D pipeline present on all video cards so it is guaranteed to be efficient now and for some time in the future too. Since video cards these days are so heavily optimzed towards 3D graphics, doing 3D graphics that look like 2D is generally much faster than doing classical 2D graphics.
I recommend using Sprite for rendering, especially if you're drawing many sprites with the same texture. The only drawback of Sprite that I've found is that it's tricky to use a pixel shader with it, where I had to fall back to rendering manual textured quads.
I recommend using Sprite for rendering, especially if you're drawing many sprites with the same texture. The only drawback of Sprite that I've found is that it's tricky to use a pixel shader with it, where I had to fall back to rendering manual textured quads.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
