Jump to content
  • Advertisement
Sign in to follow this  
Witchcraven

OpenGL My game running slower than I expected

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

My game, in it's current unfinished state, is running slower than I thought. Most time it is running at about 270 frames per second. I then spawned 360 sprites. It dropped to about 30-40 fps, until the sprites flew offscreen. It then went back to about 270. So I know that my code that moves sprites is not the bottleneck, because my code moves them even when they are offscreeen. My programmer sense tells me it is slow because my drawsprite function does: glBegin() //draw textured quad glEnd() It does that for every sprite. It just seems inefficent to do that, 10 function calls per sprite. What method does OpenGL provide to draw more effiecently? Some type of vertex array? Something else? I sure would think OpenGL would have a more efficent drawing method, as most games have more polygons in a finger. From my previous posts on the opengl forum, you know I dont understand much of the API yet. I am mostly just interested in finishing this game, and it does not need much knowledge of OpenGL. I will probably learn it more in depth after I write my software renderer. I just hate learning APIs. Would rather study the math and science of computing.

Share this post


Link to post
Share on other sites
Advertisement
I would say that the bottleneck here is not so much the polycount, because the number of vertices you send to the graphic card for T&L is always the same.

The game slows down only when the quads are drawn in the screen, so I say your game is fillrate-limited. Unfortunately, I can't say much more without looking at the rendering code, and you don't mention you system specs.

Share this post


Link to post
Share on other sites
I wouldnt think it is fillrate. I have a gf2mx. Each sprite is 64x128. Hell, I can run the latests games, on low settings. Each sprite is 24 bits.

So 128x64x360 = 2,949,120 pixels. Does that exceed my fillrate?

My system is an 800mhz G4 with gf2 mx. It performs about the same as my 1ghz AMD with gf2mx, usually a little better. It has proven itself in it's game playing ability.

Well, I did I few calculations of my own. Not knowing 3d hardware, it could be off. According to http://www.pantherproducts.co.uk/Product%20Reviews/Geforce%202%20MX.shtml my card has a fill rate of 350 million pixels per second. Divide that by 2,949,120 I get 118.6 fps max. Perhaps my problem is I did not put the renderer in a seperate thread (yet). Maybe I will remove all my physics code and see if anything is faster.

Share this post


Link to post
Share on other sites
As I said, you always push the same number of vertices, make the same number of function calls, handle the physics of the same amount of objects. Only when the sprites are actually drawn in the screen, the framerate drops from 270 to 30 fps. Doesn't this sound like a framerate-limited app?

Share this post


Link to post
Share on other sites
At 800 Mhz, maybe you have a CPU bottleneck ? Are you sure it's in your rendering code ?

There is some CPU overhead associated to each API call. Doing a glBegin / glEnd for every single sprite is pretty bad. Maybe you could try to do:


glBegin(GL_QUADS);
for (int i = 0; i < myNumberOfSprites; i++)
drawMySprite(i);
glEnd();


Even a GF2 MX can transform 360 sprites very quickly - so i don't think you'll see any gain by using another rendering method (vertex arrays or VBOs).

I'd probably suspect your textures. Are they different for each sprite ?

Are you using a 24 bits internal format during their creation ? With mipmapping ? And i guess your GF2 only has 32 Mb of memory. If so, you might hit your textures memory limit. To check that, reduce all your textures resolution by 2 and see if it improves the framerate.

Finally, i'd also be carefull with texture switches. Are you binding 360 textures ? If so, consider sorting your sprites by texture, and if you have a lot of small textures, grouping them in a larger one.

Y.

Share this post


Link to post
Share on other sites
They are all the same sprite, as in, only 1 loaded image. It would not be hard to change the function to call only glBegin / glEnd once per frame. I was thinking of doing too, but I wanted to make sure there was not some better method first. Actually I do bind once per sprite, regardless. I think I will implement a sort. But I still bind once per sprite anyway, even if nothing is drawn, so I am not sure that is it. Although I cant imagine it helps any. That gave me lots of ideas for optimizations actually. Thanks.

Also, it doesnt run in fullscreen. Does that have an impact?

Share this post


Link to post
Share on other sites
>>because my code moves them even when they are offscreeen. My programmer sense tells me it is slow because my drawsprite function does:
glBegin()
//draw textured quad
glEnd()<<

altough this is not ideal ( itll be better sticking the lot into an vertexarray).

heres the issue, zoom the camera out until the sprites are very small on the screen eg the maximum area they cover onscreen is 1cm2.

now if the framerate is something like this
closeup (A)
normal 270, with sprites 30-40 fps
zoomed out (B)
normal 300, with sprites 270 fps

then u know that changing to VA's whatever, aint gonna help matters much cause in both A+B there are exactly the same number of vertices drawn etc. the thing is the pixels in A take up a lot more screen area than in B.
then u are fill limited thus look for solutions for that

>>So 128x64x360 = 2,949,120 pixels. Does that exceed my fillrate?<<
all cards are fillrate limited even a gf6800,radeonX800 its the reason why games run slower at a higher resolution (also the 128x64 size of the texture i assume is not really that relavent)

also youre doing this i hope

glBindTexture(..)
glBegin()
//draw textured quad
glEnd()

+ not this

glBegin()
glBindTexture(..)
//draw textured quad
glEnd()

Share this post


Link to post
Share on other sites
You are most likely fill-rate limited. But to be sure, you're going to have to test it. You might do it the way zedzeek proposed, but from what I understand this is a 2D game, and in that case you're likely using an orthographic projection. In which case zedzeek's suggestion doesn't work.

So here's actually a simpler suggestion. What resolution are you running the game at? First, you'd want to run it in, say 1024x768. Note the fps with all the sprites onscreen. Now, turn down the resolution to 640x480, and again note the fps.

If you're getting more frames per second with a lower resolution, then you're fill-rate bound.

Share this post


Link to post
Share on other sites
Quote:
Original post by James Trotter
You are most likely fill-rate limited. But to be sure, you're going to have to test it. You might do it the way zedzeek proposed, but from what I understand this is a 2D game, and in that case you're likely using an orthographic projection. In which case zedzeek's suggestion doesn't work.

So here's actually a simpler suggestion. What resolution are you running the game at? First, you'd want to run it in, say 1024x768. Note the fps with all the sprites onscreen. Now, turn down the resolution to 640x480, and again note the fps.

If you're getting more frames per second with a lower resolution, then you're fill-rate bound.


To do this quite easily just run the program in windowed mode and resize the window.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!