Sign in to follow this  
unreason

An interesting 2D render method

Recommended Posts

unreason    139
I've hit on an interesting new (to me at least) method for rendering batches of 2D quads. I load a texture map with several related tiles on it, for example, all the different pictures for a particular character in the game. I build a vertex buffer, with a different quad for each tile in the texture map. Each quad has the same coordinates, same everything, except the uv texture coordinates, which map to the quad's tile. So tile 0 in the texture maps to quad 0, tile 1 to quad 1, and so on. You move the quad using matrices. The result is, that on each render cycle, you never need to create a vertex buffer, it's already created. Where you really get an advantage is if you want to draw several of these sprites, all in different stages of their animations. If you draw them together, you don't need to change textures, because they're all using the same texture. You don't need to change vertex buffers, because they're all using the same buffer. And, as I said, you don't need to create or alter any vertex buffers; they're already made, and movement is accomplished through transformations. The result is that you can print the sprites out pretty efficiently, without having to change any render settings. Does anyone think talking about this might make a good gamedev article?

Share this post


Link to post
Share on other sites
Stru    118
You need to batch them as well. Drawing one at a time will be slow. Its much better to have a few hundred in a vertex buffer and use one draw for them all, and using matrix transforms sort of gets in the way of batching.

Share this post


Link to post
Share on other sites
unreason    139
Quote:
Original post by Stru
You need to batch them as well. Drawing one at a time will be slow. Its much better to have a few hundred in a vertex buffer and use one draw for them all, and using matrix transforms sort of gets in the way of batching.


But if you don't use transforms, don't you have to keep remaking your vertex buffers again and again? Isn't that slow in and of itself?

Share this post


Link to post
Share on other sites
Agony    3452
When you say "remaking your vertex buffers", do you literally mean making calls to pDevice->CreateVertexBuffer(), or do you just mean locking them and filling them with new information? Because the first is absolutely not necessary at all.

As for filling in new vertex data each frame, if you use your vertex buffers properly, and with the correct flags when creating and locking them, then it's not really that big of a problem. Just about everything I've seen or read about tends to refill at least one dynamic vertex buffer with new data every frame. It's no biggy that I've noticed.

In addition, if all the tiles remain in the same location, at least relative to each other, and all that changes are A) a small shift of all tiles to get a scrolling effect, and B) what section of the texture each tile references, then you can use streams in DirectX 9 to help you out. The vertex positions would be in one stream, and would be static. The texture coordinates for each vertex would be another stream, and would be stored in a dynamic buffer, which you would update each frame. And then either object or camera transformations could be applied to offset everything, if you have scrolling effects.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this