Jump to content
  • Advertisement
Sign in to follow this  
quincyq

vertex buffer inquiry

This topic is 5410 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 there, Currently I am trying to write my first DirectX9 2D engine using textured quads with vertex buffers to draw my sprites and tiles. My tiles are in a tileset template .png file. When switching to different tiles from the same texture I have to constantly change the vertex buffers to reflect the tile position in that texture. Now i'm thinking that having many textures (which is stored in a list) and the constant updating of the vertex buffer will likely slow down my game when more tiles and sprites are added in the future. Is there a more efficient way of handling this? Hopefully i have made myself clear

Share this post


Link to post
Share on other sites
Advertisement
I'm not sure I completely follow you, but can't you just fill a vertex buffer with all the tiles/sprites you need for one frame, then do a single DP call on this?

Share this post


Link to post
Share on other sites
are you sure you really need to rebuild your vertex buffer every frame? thats slow, even with dynamic vertex buffers.

why not just have 1 vertex buffer, for all your sprites, set to a stardard size (say 64x64). then just change the textures for it as you render each quad, and transform the quad to where it needs to go.

pseudo code would be something like:
on game startup:
- load all textures
- create single static vertex buffer, and set it as the active one in the Direct3DDevice

in render loop (looping through n quads):
- set texture for quad n
- set transform matrix for quad n
- render quad n
- n = n + 1

the only draw back with this method is, that all your sprites would have to be the same size, whell unless you scaled them at the same time you transformed them to where they need to go on the screen.

but this is going to be alot!! faster than using a dynamic vertex buffer and rewriting the data for each quad in use, per frame. thats alot of locking and unlocking!

good luck



EDIT:

oh, i might have missread your post, sorry... wait so you have multiple tiles per texture file? ok thats a good optimization, so you wont have to switch textures nearly as much.

so it sounds like you have 1 texture, with many tiles in it, and 1 vertex buffer per texture.

and this is slow b/c you must be constantly reentering the texture coords to get it to draw the right tile out of the texture, for each quad your drawing... ok so the solution is to, have 1 big vertex buffer, big enough to hold 1 quad for each tile in the texture file.

so you have a texture file with say 30 64x64 tiles, when you open the file youll create a static vertex buffer, with 30 quads inside it, one for each of the tiles in the file.

then youll set up the texture coordinates for each quad to map to its respective tile in the texture file.

youll also need to create an index buffer too, so you can easily refer to each quad inside the vertex buffer.

then so as youre rendering youll simply call DrawIndexedPrimitive and refer to the correct indicies and vertices for the particular quad you want to render, and bam!

no more constantly reentering data into the vertex buffer just to setup textcoords!

hope i explained this well enough. make sense?

Share this post


Link to post
Share on other sites
Quote:
Original post by hlivingstone
then so as youre rendering youll simply call DrawIndexedPrimitive and refer to the correct indicies and vertices for the particular quad you want to render, and bam!

no more constantly reentering data into the vertex buffer just to setup textcoords!



Except that you are calling DrawIndexdedPrimitive for every quad!
I think filling one buffer (double buffered of course) per frame and one DP call (per texture batch) should be fine.

Share this post


Link to post
Share on other sites
"Except that you are calling DrawIndexdedPrimitive for every quad!"

yeah except that way you cant do alpha blending that way..if he was going to do so at al...

but good point, it might be beter to build a vertex buffer of quads for each texture (tileset) and render it. So this way your batching your calls per textures (rendering all the quads that use the texture in 1 call). Which would eliminate lots of drawprimitive calls, however you couldnt have anything overlap or alphablending in this case...but if this is just for background tiles and not like character sprites or anything, that shouldnt be a prob.

Share this post


Link to post
Share on other sites
Thanks for all the replies!

I think I might have badly phrased my problem...
Currently I have only one vertex buffer where the x, y, u and v coordinates are constantly updated to reflect the position to blit on screen.

My process is:
- Set texture
- Calculate x, y, u and v which is passed to my blitter function
- Draw tiles/sprites

The problem is when drawing the tiles/sprites which may be in different textures i have to constantly switch textures and recalculate the x, y, u and v's. I just think that having to do all this constantly will slow down my game when there are many textures.

The index buffer idea sounds very useful in keeping track of my tiles/sprites in a texture + batching the blitting to each frame sounds very efficient!

Share this post


Link to post
Share on other sites
I suppose that depends on how many texture switches you need to do, and what else you are doing in the frame. Around 100 or so, you would probably be fine. Just fill the VB once at the start of the frame though.
You could cache commonly used tiles together in one large texture, or if you have a decent enough shader you can store several textures on different samplers and encode which sampler to use in the VB stream.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!