n00b Vertex Buffer Question
Author
Hey everyone, I want to make a game like half-life 2, where do I start?!?! No really.... Im just kidding. I'm much more level headed than that. I actually have a question about the vertex buffer. I have been following some of andy pikes tutorials which im sure most of you are familiar with. I understand that the vertex buffer must be initialized prior to starting the game loop and rendering but Im not sure about something. Do you have to initialize all of your vertexes before even starting the rendering process or can they be thrown in dynamically during the rendering process. For example, with pong, would I initialize all vertexes prior to entering the game loop/render loop or should I do that after. I am trying to create a class for each object this is why I am asking, so I know were to put everything. Thanks for any help in advance.
Well if you have alot of vertices, like terrain for example, you would create them and them put them into a vertex buffer during the setup phase of your application. You could do it at run time each frame but it would be incredibly slow. So in your case for a simple game like pong i would put the paddles and the ball in each of their own buffers, for simplicity and the surrounds in another.
ace
ace
You can write to a vertex buffer anytime you want. However, in order to access a vertex buffer (or a section), you must Lock it. While you have it locked, the renderer cannot render it and will wait until it is unlocked. If you try to lock a vertex buffer that is being rendered, Lock will wait until the rendering is done before returning (or tell you that you can't lock it).
static vs. dynamic
Vertex data that never (or rarely) changes should be written once to a "static" buffer. The renderer can skip a lot of time-consuming work with static buffers, but updating a static buffer is expensive. "Dynamic" buffers are used for vertex data that changes every frame or every few frames. In pong, the paddles and balls don't change shape, so their vertexes should go in static buffers.
static vs. dynamic
Vertex data that never (or rarely) changes should be written once to a "static" buffer. The renderer can skip a lot of time-consuming work with static buffers, but updating a static buffer is expensive. "Dynamic" buffers are used for vertex data that changes every frame or every few frames. In pong, the paddles and balls don't change shape, so their vertexes should go in static buffers.
If you're wondering if you need to dynamically change the vertices in a vertex buffer to make the ball and paddles move, the answer is a resounding "NO!" You use matrix transformations to do that. The Andy Pike tuts show you how to do that as well :)
Just a suggestion, you can put the ball, the paddle, walls all in one huge vertex buffer and load at setup. Then at the render loop you just render what is necessary. This will save the time of setting the streamsource multiple times.
Author
That's actually what I wound up doing. I actually have another question if I may. I currently have the two paddles visible, but I am having trouble creating the circle. Which primitive is best suited for this? I tried using D3DPT_TRIANGLEFAN and setting the initial vertex as the center of the circle but Im not so sure this is the most practical way. Any help would be appreciated.
I disagree that these objects should have their own vertex buffers... it's usually bad practice in a 2D situation. You should look into using textured quads with a single dynamic vertex buffer.
Which is the answer to your question... you don't use a triangle fan to make a ball, you use 2 triangles that form a square (quad) and then a texture with transparency (.PNG is recommended). The same with every other 2D object in the game. Six vertices per "sprite".
You CAN load everything into a large static vertex buffer and then offset your quads using a matrix transform, render, repeat sequence. But, this is slower. You will be sending extremely few polygons to the GPU per drawPrimitive, which is not what you want. For sprites, text, etc. dynamic buffers are usually better.
Either way, the idea is to group your sprites by texture because then you can render ALL the sprites of the same texture using one drawPrimitive. Then, set your next texture and repeat. The real "secret" to this is that by using texture coordinates on your vertices your paddle, ball, walls, and whatever else can all be on one large texture (using Photoshop or whatever to combine the images). So basically for a simple game you can draw the entire screen in one drawPrimitive. Which is very fast, and if you use dynamic buffers it is still brutally fast for large numbers of sprites even if they are moving every frame! The vertex buffer locking flags are very important, as I was saying in the 'Fast Text' thread...
Which is the answer to your question... you don't use a triangle fan to make a ball, you use 2 triangles that form a square (quad) and then a texture with transparency (.PNG is recommended). The same with every other 2D object in the game. Six vertices per "sprite".
You CAN load everything into a large static vertex buffer and then offset your quads using a matrix transform, render, repeat sequence. But, this is slower. You will be sending extremely few polygons to the GPU per drawPrimitive, which is not what you want. For sprites, text, etc. dynamic buffers are usually better.
Either way, the idea is to group your sprites by texture because then you can render ALL the sprites of the same texture using one drawPrimitive. Then, set your next texture and repeat. The real "secret" to this is that by using texture coordinates on your vertices your paddle, ball, walls, and whatever else can all be on one large texture (using Photoshop or whatever to combine the images). So basically for a simple game you can draw the entire screen in one drawPrimitive. Which is very fast, and if you use dynamic buffers it is still brutally fast for large numbers of sprites even if they are moving every frame! The vertex buffer locking flags are very important, as I was saying in the 'Fast Text' thread...
Author
Yeah, I guess I was trying to make things a little too hard. I was trying to write a class to draw a circle polygon using triangles. I guess I will want to expolore that in the future. I got pretty far with the algorithm but I seem to be missing something. Anywho I did wind up putting all of the vertexes in one static buffer, after what you guys said it really didnt make sense to me to make them dynamic either. You guys are a life saver.
Quote:Original post by jrmiller84
Anywho I did wind up putting all of the vertexes in one static buffer, after what you guys said it really didnt make sense to me to make them dynamic either.
I still don't understand why you think this... remember that your goal in DirectX is to render as many polygons as possible (up to a limit, which is high) per DrawPrimitive call. If you are using static buffers to render things like balls, paddles, etc. it gets very slow. I used to do it this way and saw massive speed increases when I switched over to properly done dynamic buffers... now, when it comes to simple games I am all for doing 'whatever works', just know that that is what you are doing! A set matrix call per sprite? Ugh...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
