big textures (>= 512x512) are very slow...

whe i use big textures (>= 512x512) on my G400 16MB my application slow down…

why?

Maybe you are using a lot of your texture memory and cannot fit the large texture into your card. The result would be that the texture memory would have to be sent every frame and not stay resident on the card.

Or you could be loading all the textures every frame because you didn’t use texture names correctly.

Also note that large textures simply take longer to upload to the card. Also, if you use a lot of such textures in an interactive app, then chances are the card will thrash as textures are constantly swapped out to make room for new ones.

If you play Quake 3, then the map q3dm9 is a good example of this. Turn up the texture detail to the max, and even a Geforce will bow down.

ec

My application is a simple example: a rotating cube the texture reside ALL in memory! (i have a Matrox G400 AGP with 16MB of vram) => 512x512x4 (RGBA) = 1MB!!!

I upload texture only one time so isn’t a speed upload problem.

Do you have the latest drivers? The G400 has still not so very good OpenGL drivers (i have a G400 too) and previous driver revisions is probably worse.

Does the G400 support large textures? I don’t remember… Also, is it possible that your app is being forced into software mode by something else?

Hi

Well I also have a G400 and even with a 64*64 bitmap I have a really slow app. It’s all because I’m in software mode (even with the last drivers). I guess G400 is just not good at all concerning OpenGL

Hello fellas!

Well, i’m not 100% sure about this but i read about it a couple of times. I think the problem is int the accelerator itself (g400), and that it don’t support hardware acceleration with textures bigger then 512x512 pixels. Could be wrong tho… Try it on a TnT / TnT 2 card and check if there is any difference. Also, try splitting it up (four pieces?) and render.

Good luck!

Gepper

The G400 support 2048x2048 textures so the problem does not lie in hardware. G400 hardware is superior to the TNT2 both in speed, features and image quality. But it’s OpenGL drivers sucks and some features isn’t even implemented in the drivers i got to know directly from Matrox. I have a G400 too and i know it’s slow in OpenGL, but i get at least 30 fps in 800x600x32 in a full terrain scene with a lot of blending and texturing.

If you are using the win32 api and not glut you should check what you pass to the ChoosePixelFormat() function. You should not use something like PFD_GENERIC_FORMAT, or you may get a software renderer.

[This message has been edited by Humus (edited 05-14-2000).]

Erm… if you have a 512x512 texture, in RGBA, wouldn’t that be 512x512x32? each bit of RGBA is 8. When you use a true colour resolution, you use 32-bit, this is 8-bits red, 8 green, 8 blue and 8 alpha, totally 32. If you use 16-bit then there can be various different combinations, the most common being 5-6-5 totally 16-bits. So should that be 512x512x32 = 8MB

Hey, MagicDude … we’re talking about bytes here, not bits! A 512x512x32 texture is 512x512x4 = 1048576 bytes = 1 MB (8 Mbit).

don’t just GUESS that it’s resident, run isResident on the texture to make sure your driver KNOWS it is…

The problem is resolved using mipmapping… i saw speed improvement with use of it.
The other problem is that i don’t used a timerized version of routine
(cpu independent), so with a big texture, the cube movement slow (now no more…).

Question:

  1. OPENGL32.DLL is included with my videocard, but GLU32.DLL and GLUT32.DLL ???
    I can make a program without including it in my .zip???

  2. What’is the best lowend OpenGL videocard?

cya.

Answer to question 2

In my experiance, the cheapest low end card that has rock solid drivers and supports openGL fully (my experiance is with high end animation packages) is the ATI rage fury. a 16meg one for 50 quid can’t be beaten. I haven’t seen what the new 128 pro chips can do yet though.

After that you move up to a TNT 2, although I’ve had quite a lot of problems getting MAYA to run using one. They’re are very good for games, but pretty useless when you get to high end apps.

Then you hit the geforce which are pretty damn good, but I’ve seen problems with them replacing textures at odd moments.

Savage 4’s (err, where’s the openGL?), Voodoo 3’s(no openGL in NT, limited support in 98), Matrox G400’s (nice apart from openGL) are best avoided.

glu32.dll should always be in the system dir of any windows installation. But the glut32.dll you should ship with your app.