Slow performance due to large background image (texture).

[VuurSnikkel]

Hi there ppl...


I'm using a texture-mapped quad as a background for an orthographic (gluOrtho2D) 2D-game. It is fixed at non-fullscreen 640x480 and I also set the quad to that. I have also disabled 3D-stuff that isn't needed like depth-testing and even image-filtering (it is set to GL_NEAREST now). The game has to run decently on a 4MB ATI 3D Rage (it should be possible, since this card can also run Quake 3 at a reasonable speed). For some reason, however, my method is very slow (it runs fine on my GeForce3 by the way). I was thinking about using glDrawPixels to draw the background image, but it might also have something to do with the fact that the card only has 4MB of memory and/or that I should use a maximum texture-size of 256x256. I also read something about using teh buffer region extension to load the background into videomemory, but I don't know if the Rage supports this or if it even makes sense to try something like this on a 4MB card. So, if someone has an idea about how to tackle this problem; I would really appreciate it.


GRTZ and thanx in advance,

(Sn)Ik.

[Korval]

Note that GL will, usually, run slower in a window than at fullscreen. This could be the source of your problem.

Also, do you know if your setup code is getting an accelerated context? Are you possibly doing something that turns off hardware acceleration?

BTW, you say that it is not running "decently". What do you mean by that, precisely? How slow is it?

[rgpc]

If your texture is just being used as a backdrop then you can...

(a) only clear the depth buffer, then draw your quad (this removes the need to clear the buffer, then overwrite the cleared area).

(b) draw the backdrop last after all of your geometry. This reduces the amount of fill rate you are using - but doesn't work if you have transparent geometry.

Further to the above you seem to be suggesting that you are uploading a 640x480 texture. I would guess that this is bumping your driver back to a software implementation (If this happens on a gf3 then the text "ForceSW" occurs in the GL_RENDERER string - but I don't know how you tell with an ATI card).

Try splitting your texture into 4x256x256 - or enlarging it so you have a black area around the texture and make it a power of 2 texture...

[Obli]

Dumb question: are you sure you are not redefining texture each frame? Are you using texture objects?

[VuurSnikkel]

Hi there...


Thanks for the replies. As far as hardware-activation is concerned: It is hardware-accelerated in case of both the ATI and the GF3. With not decently I mean that I can get 150FPS on my GF3 but 5 to 10FPS tops on the ATI. I already thought about the power of two trick and/or splitting up the background texture and I'm going to try that now. Thanks for the clearing-tip, by the way. What about glDrawPixels(), or is this a no-go?


GRTZ,

(Sn)Ik.

[VuurSnikkel]

Hi Obli...


About the last question: I load the texture into a gluint at start and after that I made a display list for drawing the textured quad. The only thing I do inside the display list as far as the texture is concerned is using glBindTexture2D(), so as far as I can tell I'm not redefining anything.


GRTZ,

(Sn)Ik.

[jwatte]

On a 4 MB card, a 640x480 screen in 32 bit will take up 1.2 MB or so. This is assuming you don't create your context with a back buffer.

If you're not in full screen, your desktop/frame buffer will take up more memory. Thus, you may exceed the avaialble memory with your working set of texture memory, and thus it'll have to page textures for each frame.

It may be the case that in windowed mode, there isn't enough texture memory. I don't know about the texture limits on the Rage, but you might want to try slicing your image into 256x256 sized chunks and draw it that way and see how it goes, too.

[roffe]

Be sure to use texture compression if it's available.

[VuurSnikkel]

Well, I'm using doublebuffering to prevent tearing, but I'll deactivate that as well and see how it goes.

[jwatte]

Rage does not support texture compression.

In general, texture compression started appearing as a solution to the problem of too small local memory buffers, about the same time as local memory started hitting 32 MB, and you stopped needing it as badly ;-)