Archived

This topic is now archived and is closed to further replies.

how many polygons...

This topic is 5309 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

that a commercial game, like Warcraft 3 or Unreal Tournament, usually have on screen? I just completed my sprite class (using a textured quad) that I now can start drawing some stuff on screen. I set the number of sprites to 100, all worked good. FPS is ~75 (vsync). Then I changed it to 5000. FPS dropped down to ~20 O_O! If each sprite has 2 polygons, 5000 sprites make it 10000 polygons rendered on screen. It can''t be that slow...

Share this post


Link to post
Share on other sites
Most video cards are not polygon limited. They are fill rate limited (the number of pixels being put to the screen each frame). If those quad''s are big (and drawing alot of pixels), it can be slow.

If a game out there has more polygons, its probably because the polygons they are drawing are very tiny on the screen.

Share this post


Link to post
Share on other sites
5000 sprites = 5000 calls to DrawPrimitive, that''s what slows it down. You have to batch all the sprites into vertex buffers, and render them using as little DrawPrimitives as you can.

To do that, you must create a dynamic vertex buffer and fill it in with all your quads information, then render using a texture, when drawing a different sprite, change the texture and refil the vertex buffer with new sprite squads. Or you can put all your sprites into one buffer, and then use DrawIndexedPrimitive for each texture.

hope that helps

Share this post


Link to post
Share on other sites
quote:
Original post by billybob
you can't call SetTexture for every quad either, you have to set the texture, and then draw all the quads that use it
But how am I going to keep track of that?

Let's take 5000 spinning balls on screen as an example (the spinning balls are textures, not rotated by program).
Each sprite has its own spinning rate (how fast it changes the frame). Consider each box is a ball, and A, B, C are different textures. At one frame, the condition might be like this:

+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A | | B | | C | | B | | A | | C |
| | | | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+

but then, on the next frame, it could be like this:

+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| B | | C | | C | | A | | A | | C |
| | | | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+

How do manage so that each time I SetTexture(A), it knows which balls to draw, I SetTexture(B), it knows which balls to draw?

[edited by - alnite on June 3, 2003 12:31:47 AM]

Share this post


Link to post
Share on other sites
One way would be to put all the ball animation in the same texture and just change the quad's tu/tv coords each frame to line up with the appropriate animation.

Say you had a texture with 1x4 (1 row,4columns) grid of ball animations. The tu/tv coords of the first frame of the quad's animation would look something like:

0.0,0.0-----------------0.25,0.0
|.....................................|
|.....................................|
|.....................................|
|.....................................|
|.....................................|
0.0,1.0-----------------0.25,1.0

This would keep you from having to make multiple costly SetTexture() calls for each frame of animation. Of course, modifying the tu/tv coords each frame and rebuilding the vertex buffer might be just as expensive.

BTW, I don't think you are supposed to have rectangular shaped texture so it might be better to tile vertically (4x4) as well.

bpopp (bpopp.net)

[edited by - bpopp on June 4, 2003 1:26:28 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by FuzzyBunny
5000 sprites = 5000 calls to DrawPrimitive, that''s what slows it down. You have to batch all the sprites into vertex buffers, and render them using as little DrawPrimitives as you can.

To do that, you must create a dynamic vertex buffer and fill it in with all your quads information, then render using a texture, when drawing a different sprite, change the texture and refil the vertex buffer with new sprite squads. Or you can put all your sprites into one buffer, and then use DrawIndexedPrimitive for each texture.
Hm...I think this is very hard to implement in my case because the sprites are everywhere on the screen and they move around. But it will work with things like map or terrain. Thanks.

Share this post


Link to post
Share on other sites
quote:
Original post by JoeyBlow2
Most video cards are not polygon limited. They are fill rate limited (the number of pixels being put to the screen each frame). If those quad''s are big (and drawing alot of pixels), it can be slow.

If a game out there has more polygons, its probably because the polygons they are drawing are very tiny on the screen.
Hm..if it''s the number of pixels...all fullscreen games should have the same speed?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
use one texture, and use texture coordinates to extract tiles from it

Share this post


Link to post
Share on other sites
quote:
Original post by bpopp
One way would be to put all the ball animation in the same texture and just change the quad's tu/tv coords each frame to line up with the appropriate animation.

This would keep you from having to make multiple costly SetTexture() calls for each frame of animation. Of course, modifying the tu/tv coords each frame and rebuilding the vertex buffer might be just as expensive.

quote:
Anonymous Poster
use one texture, and use texture coordinates to extract tiles from it

OK, this is something new for me and it's completely different from what my engine currently does.

bpopp, you said to change tu,tv on each frame, but you also said that it might be just as expensive because I change and rebuild the vertex buffer each object each frame.
And AP said to use it.

My question is (before I make up my mind), how fast this technique is compared to SetTexture() each object each frame?

[edited by - alnite on June 4, 2003 3:09:54 PM]

Share this post


Link to post
Share on other sites
I went through exactly the same process that you''re now going through. I was getting ~20fps with all those set texture and drawprim calls (5,000 quads... strange that we used the same number, but there you have it). Switching it to a single texture and dynamically building the vertex data every frame got me to around 180 fps. I wasn''t using a VB by the way, just a vertex array. A dynamic VB might be even faster, but... well, maybe not. It''s easy to switch between the two to test.

180 fps was before adding in physics, collision detection and so on.

By contrast, my terrain is rendering 160,000 quads at 78 fps. This is static data stored in VB''s and rendered with a single texture.

Share this post


Link to post
Share on other sites