🔒 Locked

a single vertex buffer ?

Started by k0lpA Jun 29, 2004 at 2:43 PM 10 replies 2.1k views

Original Post

Jun 29, 2004 at 2:43 PM

I would like my game to run faster... for now, every sprite(textured quads) has its own vertex buffer. I guess having only 1 vertex buffer to update would make it run faster... I have thought of a way to do it and I would like to know if it would work. here is the new render() function I thought of:


Render()
{
int Number,i;
	Number = SpritesPreRender();

	App.D3D_device->SetVertexShader(MyVertex);

	App.D3D_device->SetStreamSource(0,SpritesVB,sizeof(TexVertex));

	for(i=0;i<Number;i++)
	{
		App.D3D_device->SetTexture(0,STextures);

		App.D3D_device->DrawPrimitive(D3DPT_TRIANGLELIST,i*6,2);
	}

	App.D3D_device->SetTexture(0,NULL);
	App.D3D_device->EndScene();
	App.D3D_device->Present( NULL, NULL, NULL, NULL );
}

SpritePreRender() returns the number of sprites that needs to be rendered and gives them a unique number from 0 to last sprite.The sprites textures are stored in STextures[Sprite Unique Number] in SpritePreRender().

DrunkenHyena

Jun 29, 2004 at 2:48 PM

That will make it go faster, but not by as much as you'd hope. You'd get a much bigger improvement by reducing your Draw calls. Do any of those sprites use the same texture? If so, sort your sprites by the texture they use and then draw many of them with a single call.

If they don't share textures, or don't often share textures you can combine textures into a larger texture page.

Zipster

Jun 29, 2004 at 2:50 PM

Consolidating your vertex buffers as much as possible is a very good idea.

From looking at your code, you could even cut down on the number of vertices by using an index buffer combined with triangle strips / fans. As it is now, you have six vertices per quad when all you really need is four.

Stephen R

Jun 29, 2004 at 2:50 PM

A nicer way would be to have a single vertex buffer containing only one quad. Then you could use matrices to scale and translate that single quad.

It means a smaller and much more flexible situation.

Zipster

Jun 29, 2004 at 3:47 PM

It actually degrades performance when you change the transformation matrices too often. It would also be difficult to work with only one quad.

Stephen R

Jun 29, 2004 at 3:53 PM

Hmm, well you're probably right. I use it on my 2d apps out of necessity and it doesn't slow down noticably.

k0lpA

Jun 29, 2004 at 5:14 PM

thx guys, I will try to regroup my sprites with the same textures as Drunken Hyena said... and btw I learned everything I know on D3D on ur site ;)

I will also try to use index buffers !

Raloth

Jun 29, 2004 at 5:20 PM

Quote:
Original post by DrunkenHyena
That will make it go faster, but not by as much as you'd hope. You'd get a much bigger improvement by reducing your Draw calls.

I feel the need to be harsh here.

I've noticed a recurring theme with DrunkenHyena's posts: they aren't always correct.

Switching vertex buffers is more expensive than draw calls. That is of course ignoring the fact that he can't reduce the number of draw calls until he combines the buffers in the first place.

Now, combining the textures as he said is most definitely a good idea, but I wish the rest was just as correct.

hplus0603

Jun 29, 2004 at 5:26 PM

Actually, in DirectX9, switching vertex buffers is much cheaper than in previous versions.

Thus, the comment that it won't help "as much as you'd hope".

For 2D, you want to get the API out of the way, and let the card go fill bound. To do that, I would:

1) bake all vertices into a single list, using a single index list to draw them all (0,1,2,0,2,3 ...)
2) bake all textures into one large texture sheet
3) use the CPU to translate and rotate the sprite position/sizes/rotations into vertices into the buffer

That way, you should be able to reduce your calls to one set-up call per texture sheet, and with a modern-sized texture for sheeting, you may not need more than one or two.

Raloth

Jun 29, 2004 at 11:34 PM

Cheaper != Cheap

My main gripe is that he didn't seem to realize that batches can't be reduced until the number of vertex buffers is.

DrunkenHyena

Jun 30, 2004 at 10:27 AM

Quote:
Original post by Raloth
My main gripe is that he didn't seem to realize that batches can't be reduced until the number of vertex buffers is.

Say you have 10 sprites. These sprites are split evenly between 2 textures, so 5 sprites per texture. To draw a batch of 5 sprites you need to have a VB large enough for 5 sprites. This means the highest number of VBs you COULD have would be 2. This is a reduction from 10 VBs to 2. From 10 VB changes, to 2.

Batching your calls automatically reduces your VB changes. I can't imagine a way to batch your calls WITHOUT reducing your VB changes. Can you?

So I stand by my statement. Just reducing your VB swaps will improve performance, going to the next step of batching will improve it a far more.

DrunkenHyena

Jun 30, 2004 at 10:29 AM

Quote:
Original post by Raloth
I feel the need to be harsh here.

I've noticed a recurring theme with DrunkenHyena's posts: they aren't always correct.

That is a recurring theme with every member of humanity. And I disagree that there is any reason to be harsh. You seem to have some issue with me, but I can't imagine why.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.