Hi all,
it's my first post here and i plan to be more participative from now on.
Ill start with a problem i have in one application i did in visual C+GLUT+OpenGL.
As the title states, i have a dramatic drop in frames per second when using a single BMP texture with transparency and i think maybe the problem is that im not using the texture mapping correctly.

Without the displaying of transparent texture i get 50 frames per second which for me is okay. You can notice that the grass has a texture and also the sharks have dotted texture as skin.

In the following picture i draw the water walls i want without transparency i get 30 frames per second (20 fps drop) i dont understand why but anyway 30 fps seems to me a good framerate.

Now in this third image i add transparency for the water walls you can see the drop to 9 fps!!! And this i can't understand as i know dealing with transparency is one of the hardest things for GPUs but common, im using only one texture in 4 quads!!!!!

Okay i can say that i forgot to disable the GL_DEPTH_TEST and enable it at the end
[source lang="java"]glEnable(GL_BLEND)glDisable(GL_DEPTH_TEST);(draw stuff)glEnable(GL_DEPTH_TEST);glDisable(GL_BLEND);[/source]

I have ordered the drawing of the walls, first the 2 walls from the back and at last the 2 walls from the front, and apparently it works.....

... if it wasnt by the fact that i can rotate around Y axis and this is what happens:

now my back walls when i rotate around vertical Y axis the grass appears because it is rendered AFTER the back walls.

1. - What can i do to solve this problem? I can't find the correct draw order.
2. - If i dont disable GL_DEPTH_TESTING i get the correct behaviour but i get 9 fps!!!!
3. - I dont have anymore 9 fps but 25fps, why is this if i had at the beginning without the walls 55 fps? Why such difference in performance?

What sort of graphics card are you using, and what sort of resolution and anti-aliasing setup is there?

The only explanation I can think of is that you're woefully fill rate bound, but I can't see how this scene could possibly cause that situation on a desktop graphics card (maybe an iPad1, but not anything else).

In addition to the above, you shouldn't measure performance in FPS - measure in milliseconds or microseconds. FPS measurements can be deceptive; an increase from 55 FPS to 60 FPS (a gain of 1.5 ms a frame) is not the same increase as from 60 FPS to 65 FPS (a gain of 1.2 ms a frame).

Your fps will always be garbage in intermediate mode, try using a draw list or vbo.

No no no no no.

Immediate mode is slower than the other methods for sure, but it's not that much slower. You don't get such dramatic framerate drops from it, particularly with such a simple scene (as polycounts really ramp up it's expected, but with basic scenes it's performance is roughly equivalent to the others). Remember - Quake used immediate mode and didn't suffer overly much from it.

Please don't recommend VBOs (or display lists) as a "solution" every time you see immediate mode code - the real cause of the problem may very well be elsewhere (as, indeed, it was in this case).

I'm not advising that it's OK to use immediate mode here, by the way; I am recommending that you should properly diagnose the problem before recommending a solution, rather than jump to conclusions.

Now how the heck i do that?

You should have an option to select the GPU to use in your NVIDIA control panel. It's also worthwhile downloading updated drivers for your machine as the absence of a proper OpenGL driver for the integrated card suggests that you're on an OEM driver; visit http://www.nvidia.com/Download/index.aspx?lang=en-us to get a proper updated driver.

Edited by mhagain, 11 December 2012 - 08:12 AM.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

Your fps will always be garbage in intermediate mode, try using a draw list or vbo.

No no no no no.

Immediate mode is slower than the other methods for sure, but it's not that much slower. You don't get such dramatic framerate drops from it, particularly with such a simple scene (as polycounts really ramp up it's expected, but with basic scenes it's performance is roughly equivalent to the others). Remember - Quake used immediate mode and didn't suffer overly much from it.

Please don't recommend VBOs (or display lists) as a "solution" every time you see immediate mode code - the real cause of the problem may very well be elsewhere (as, indeed, it was in this case).

I'm not advising that it's OK to use immediate mode here, by the way; I am recommending that you should properly diagnose the problem before recommending a solution, rather than jump to conclusions.

Graphics card makers only optimize their hardware for vbo's these days so its not unreasonable to assume legacy functions can cause all sorts of performance problems.

Now, im running the app in a laptop Dell XPS17 with integrated graphics card and an Nvidia GT555m card, maybe the problem is im not choosing the right graphics card for running the app.<br /><br />Now how the heck i do that?

It's also worthwhile downloading updated drivers for your machine

^ This.

I encountered the same problem when I moved to Windows 8. Apparently Windows 8 thinks its half-baked display driver is better than the drivers provided by my graphic card's manufacturer...

Hi, i have the nvidia control panel where i can select the .exe file related to whichever game i want to play and select which of the two video cards runs the game.

For game and other applications like adobe creative suite it works and it's the nvidia graphics card taking charge of.

But ive tried setting my application *.exe file in the list, and still wont run in the nvidia gt555m!! my Nvidia notifier says there are no programs running with the nvidia gpu plus the console spits out again GDI GENERIC plus no changes in fps of the app so it's definitely not working for me this way.

I've searched the internet but all i have found is people not knowing how to put the *.exe from a game in the list of the nvidia control panel, nothing about any programmer trying to run his own exe file in the nvidia gpu.......

Graphics card makers only optimize their hardware for vbo's these days so its not unreasonable to assume legacy functions can cause all sorts of performance problems.

Quake still runs well on a modern GPU (which is likely to be emulating immediate mode in the driver by filling a dynamic VBO behind the scenes) - certainly much faster than the single-digit framerates that the OP is reporting, and with much more complex geometry, translucency, etc. Yes, you're right that it's not unreasonable to make that assumption, but when actual hard data invalidates the assumption (for this class of simple scene) then you do need to reconsider.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

So, i guess it has to do either with the way glut manages window either with any initialization parameter im not setting properly..........

Definitely possible. One unfortunate thing that many GLUT examples I've seen do is create a single-buffered context, and it may be the case that your NVIDIA GPU/driver is unable to give you a hardware accelerated one. If that sounds like something you may have in your code then switching it to double-buffered (using GLUT_DOUBLE during startup and adding a call to glutSwapBuffers at the end of each frame) may be all that you need. Also worth checking the bit depth you request for your colour and depth buffers (not sure if you can control this via GLUT though).

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

OK, one problem here is that you're using SDL_Delay to control framerate. That's internally implemented as a Sleep call and Sleep is not a good way of controlling framerate (it only specifies a minimum time to sleep for; actual time may be longer, and this will be true even if using a high resolution timer).

That's not going to fix your specific problem with not getting a hardware accelerated GL context, but it is some cleaning up you need to do.

For your GL context problem, I'll have a look over your code later on today and see if I can spot anything (assuming someone else doesn't come up with the solution before then).

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

Of course there is a driver problem there because with a scene light that you should run into the 300fps ballpark easily.
Having said that, blending operations will always have a big impact on the scene because simply, they do more work, they have to read the current pixel color, apply the blending function and then write back the colour.