Textured Quad Performance
Author
I have a generic sprite class, and I am worried about the performance. Drawing 4000 sprites (which would be 8000 polys) I get a mere 50 fps. Im running a XP 2100, and a raedon 9500 pro. This is in release mode with the retail dx runtime, and PresentInterval set to immediate . This seems on the low side.
Lets me give you a brief description. It uses one vertex buffer with 4 vertices. Every sprite the vertices and texture coords are changed with matrix translations, and it is drawn (DrawPrimative). It all works perfectly except for the relatively poor performance. So is there something I am doing wrong?
If you''re doing a DrawPrimitive() call per sprite and have one vertex buffer per sprite, then that''s very likely to be the problem.
Batch up the sprites you need to render in a frame into a single vertex buffer and render all the sprites which use the same texture using ONE Draw*Primitive*() call.
Add the offset that you''re currently using the matrices for to the actual vertices as you add the sprites to the buffer.
--
Simon O''Connor
3D Game Programmer &
Microsoft DirectX MVP
Batch up the sprites you need to render in a frame into a single vertex buffer and render all the sprites which use the same texture using ONE Draw*Primitive*() call.
Add the offset that you''re currently using the matrices for to the actual vertices as you add the sprites to the buffer.
--
Simon O''Connor
3D Game Programmer &
Microsoft DirectX MVP
My experience has been that excessive amount of calls to DrawPrimitive can be rather expensive, and if you''re doing 4000 of them every frame, then there you go.
To support my claim, I give an example of drawing splines in my level editor. Each spline was broken up into 32 points, with lines used to connect the dots. My first pass to accomplish this was the "just get it working" approach where I used my DrawLine function 31 times per spline. Internally the drawline uses a vertex buffer of 2 elements and DrawPrimitive(line list...) to draw 1 line. Yup, not very efficient for batch operations. The framrate went from 160 (0 splines) to 40 (20 splines = 620 lines). Well, that was a terrible way of doing it.
The next approach was using a 32 element buffer (not vertex buffer), filling it with the spline points and then using DrawPrimitiveUP(line strip...) with it. The framerate went from 160 (0 splines) to 155 (20 splines = 620 lines). With 100 splines (3100 lines) the framerate was still around 140. So you can see, cutting down on function calls, and DrawPrimitive specifically, did me a world of good.
Now, there are other factors (besides DrawPrimitive) in my example that affected the outcome, so I am not stupid enough to say I quadrupled my framerate by using line lists or anything. Function call overhead (parameter passing to DrawLine) was probably killing me in the brute force attempt. But, I think it''s still indicative that the less functions you call, and the less you call DrawPrimitive, the faster the rendering goes...
I''d suggest setting up a batching system where you have vertex buffer that can hold a lot (100+) of sprite vertex data at once. When you''ve drawn enough sprites to it, unlock it and render it, and start over. Only problem with that is you''d have to make sure every sprite in a particular batch uses the same texture. That can be a big or small problem depending how you set up your bitmaps.
To support my claim, I give an example of drawing splines in my level editor. Each spline was broken up into 32 points, with lines used to connect the dots. My first pass to accomplish this was the "just get it working" approach where I used my DrawLine function 31 times per spline. Internally the drawline uses a vertex buffer of 2 elements and DrawPrimitive(line list...) to draw 1 line. Yup, not very efficient for batch operations. The framrate went from 160 (0 splines) to 40 (20 splines = 620 lines). Well, that was a terrible way of doing it.
The next approach was using a 32 element buffer (not vertex buffer), filling it with the spline points and then using DrawPrimitiveUP(line strip...) with it. The framerate went from 160 (0 splines) to 155 (20 splines = 620 lines). With 100 splines (3100 lines) the framerate was still around 140. So you can see, cutting down on function calls, and DrawPrimitive specifically, did me a world of good.
Now, there are other factors (besides DrawPrimitive) in my example that affected the outcome, so I am not stupid enough to say I quadrupled my framerate by using line lists or anything. Function call overhead (parameter passing to DrawLine) was probably killing me in the brute force attempt. But, I think it''s still indicative that the less functions you call, and the less you call DrawPrimitive, the faster the rendering goes...
I''d suggest setting up a batching system where you have vertex buffer that can hold a lot (100+) of sprite vertex data at once. When you''ve drawn enough sprites to it, unlock it and render it, and start over. Only problem with that is you''d have to make sure every sprite in a particular batch uses the same texture. That can be a big or small problem depending how you set up your bitmaps.
Author
Thanks for the help S1CA, and foofightr. It was quite frustrating getting it to work (no one told me you have to define the data in the vertex definition in a certain order!!!), but it seems to work fine. Filling the screen with 10,000 sprites gets me arround 70 fps. Is this resonable given my hardware running on 800x600?
Thanks again guys. The tutorials I''ve been reading kept contradicting each other, so this is a big help.
Thanks again guys. The tutorials I''ve been reading kept contradicting each other, so this is a big help.
quote:
Filling the screen with 10,000 sprites gets me arround 70 fps. Is this resonable given my hardware running on 800x600?
That''s pretty amazing in my book! Anyway we can get a peek at the code? My texture quad class is pretty slow for now (compared to that!)
cb
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
