Performance Problems

I’m having some performance problems in my OpenGL app. I am using an orthographic projection for a 2d game that I am working on. My problem is that my frame rate seems really low, and I cant determine why.

When I disabled the depth test, it increased my performance significantly, but disabling alpha blending did nothing to help my performance. Also, when I stopped binding my texture for every image (using glBindTexture() ), my frame rate doubled.

Is glBindTexture() inherently slow? Is there a way around this besides drawing all images using the same texture at once?

Bind texture is slow, yes. Especially if you are using mip-mapping.

I hope you aren’t binding a texture each frame - if so then you app performance will be slower than an extremely slow thing thats just about to fall asleep

Post us some code so we can take a peek ))

BindTexture() shouldn’t be all that slow - but then it does depend on how many times you are calling it each frame I suppose.

Of course, you havent really provided much to work with. What system are you testing on? how low is ‘really low’?

Also, some code would be nice so we could perhaps help you identify the bottleneck.

-Mezz

I was thinking more in terms of uploading the texture during the initial bind (glTexImage2d) etc. which is slow of course. This is a common mistake that some newbs make - instead of just binding with the Id from a glGenTextures etc.

Otherwise, depending on the number of binds you are doing with the id, it will or will not be optimal.

I was binding the texture each time it was draw.

glBindTexture(GL_TEXTURE_2D, tex); // Select Our Texture

glBegin(GL_QUADS);

  glTexCoord2f(1.0f, 0.0f); glVertex3f( xp[0], yp[0],  0.0f);	// Bottom Left Of The Texture and Quad
  glTexCoord2f(0.0f, 0.0f); glVertex3f( xp[1], yp[1],  0.0f);	// Bottom Right Of The Texture and Quad
  glTexCoord2f(0.0f, 1.0f); glVertex3f( xp[2], yp[2],  0.0f);	// Top Right Of The Texture and Quad
  glTexCoord2f(1.0f, 1.0f); glVertex3f( xp[3], yp[3],  0.0f);	// Top Left Of The Texture and Quad

glEnd();

The texture is binded for every sprite. Is this not correct?

This was mostly from NeHe’s tutorials. What function should I be using to change the texture used?

No, your ok. That is correct. Now the other questions are:

How many sprites are you drawing?
How large are they (on average - large sprites might hurt fill-rate on a lower spec card)?

I’m guessing you have a fill-rate problem - which gfx card are you using?

I’m the graphics programmer for a larger project, and I am guessing that the sprites will be about 100x100 or so.

I am in a windowed mode, 640x480, drawing 100 sprites of 100x100 I can achieve about 30 fps. My developement machine has a Riva TNT2 card. It seems as if binding is taking 40% or so of the time that it takes to draw the texture, since when I remove the statement that binds the graphic, my framerate jumps to 60 fps! I havent tested my framerates in fullscreen.

Well your fps seems to be ok without binding - just switch off vertical retrace and you will probably hit around 80fps or something (but thats a side issue).

You have what I suppose could be described as a special case here in that each sprite will generally have a different texture, so there is probably a lot of thrashing going on between system and video memory.

A solution to this could be to group textures together into single maps and reference them with different texture coords. So, for example, bind in maps 256x256 with 4 sprites on instead of 4 128x128 maps. You will still be touching the same number of texel but you’ll be executing the bind statement only 1/4 of the time. Of course with larger maps, you increase the chance of hitting a limit and starting the system\vid mem thrashing I mentioned up top.

Experiment I guess.

TNT2 fill rate wasn’t the best (well it was in its time) - I guess you are going to have to work around this somehow.

(btw - ) the above idea should be more efficient, especially if you group the rendering of sprites using the same map. You can do some kind of insertion sort on a list given to each texture map - extra cpu work but less texture memory thrashing.

Hope this helps.

[This message has been edited by Robbo (edited 09-30-2002).]

Thanks, I’ll try that!