Advertisement Jump to content


This topic is now archived and is closed to further replies.

Eber Kain

To Enable or To Disable

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

Whats your opinion on enableing/disable OpenGL stuff. Like blending, the only time in useing it is with flares and bitmapped font, should i have it disabled all the time and only enable it when i use it? Or have it enabled all the time, and only disable it when i draw something else? Should I allways try to shoot for the least ammount of state changes?

Share this post

Link to post
Share on other sites
I think it depends on how much you use ie: the blending..
I''m no expert in anything here, but this sounds the most reasonable =) Well, if you''re going to drive 10 miles you dont fill enough gas for 5 miles, and then stop on the gas station there and fill enough to drive the next 5 miles.. and then again fill =)

Kenneth Wilhelmsen
Try my little 3D Engine project, and mail me the FPS. WEngine
He who joyfully marches to music in rank and file has already earned my contempt. He has
been given a large brain by mistake, since for him the spinal cord would fully suffice. This
disgrace to civilization should be done away with at once. Heroism at command, senseless
brutality, deplorable love-of-country stance, how violently I hate all this, how despicable and ignoble war is; I would rather be torn to shreds than be a part of so base an action! It is my conviction that killing under the cloak of war is nothing but an act of murder

Share this post

Link to post
Share on other sites
From what I've read all state changes create a performance hit. The thing is you can't possibly leave blending on all the time or else everything would be blended right? So you have to enable it only when you want something blended.

But a reduction in the number of state changes is always desired to optimize your code. I do not however know how much of a performace advantage you'll get.

One of the overlooked problems of performance involves REDUNDANT state changes. This can really slow you down bad and accomplish nothing. Meaning if you have to change a state for an effect that is fine, but doing it more than once gains you nothing and is a big performance hit.

Take a look at this thread in the forums to see what I mean:
redundant state changes

Edited by - element2001 on November 20, 2001 3:49:02 AM

Share this post

Link to post
Share on other sites
Hmm... I think you speak to one point I am asking me often, too.
If I''m understanding you right, you are thinking about the default state, and if your function is called that draws e.g. a piece of glass, if it should assume that blending is enabled or disabled.
I think a good point to start is the default state of OpenGL, so you allways assume that this is set. A function that uses Blending is called like this (because Blending is disabled by default):

int drawGlass()
// draw some stuff
glDisable(GL_BLEND); // restore the default state

But you allways have to keep in mind that this produces a little overhead.
Especially if you have a loop where a lot of pieces of glass are drawn, this would be not good. So you should do sth. like this there

int drawGlass()
{ // draw some stuff }

int main(void)
//rest of prog

But if you e.g. draw everything blended you should change the default state, and perhaps make a comment at the top of your document, which states differ from the default.
Another way would be to check the state before drawing, and changing it when neccesary. But because I don''t know wheter it is faster to simply change the state, or check it and perhaps change it, I can''t give you any advise here.
Note that you will really face this problem if you''re dealing with classes. If you have a class called CGlass, which has a draw function, every call of this must enable blending (for every instance), because the class shouldn''t know anything about it outer world, and shouldn''t depend on it.
One way to work around this would be to offer the static methods glPrepareDraw and glAfterDraw to CGlass, which does all the initialization and, sets the state back after drawing.

class CGlass
static void glPrepareDraw() {glEnable(GL_BLEND);}
static void glAfterDraw() {glDisable(GL_BLEND);}
void draw() {//...};

int main(void)
CGlass pieces[1000];
for(int=0; i<1000;++i)

If you assume the default OpenGL state as your default one in all your progs, you can simply carry your function/ classes from one prog to the other without touching the code.
So it would be easy to reuse, and you can simply exchange code with everyone else who follows these specification.

Greetings Ben

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!