#### Archived

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

# OOP, C++, and OpenGL State

## Recommended Posts

Just got to playing, and figured other people might want to take advantage of this. It's not a big deal, but something that I've been thinking about. I do a lot of:
myObject::draw()
{
glPushMatrix();

// Draw stuff, do transforms, etc.

glPopAttrib();
glPopMatrix();
}

And got to thinking that I should let C++ help me out with this. Really, it's a couple of simple classes that via C's scoping mechanism will do that for me. It basically reduces that code by 1/2 (big deal eh?), and since it's inlined, should have no run-time speed hit (if compilers do things correctly). However, I forsaw it mostly as a method to prevent forgetting to pop what you push.
myObject::draw()
{
CGLMatrixContext matContext;

// Draw stuff, do transforms, etc.
}

Hope it makes a few people's lives easier...nothing big, but I like it better.

/*
*	GLSaveContext.h
*	wxModelView
*
*	Created by Casey O'Donnell on Sun Mar 16 2003.
*
*/

// GLSaveContext.h: interface for the GLSaveContext classes.

//

//////////////////////////////////////////////////////////////////////

#ifndef _GLSAVECONTEXT_H__
#define _GLSAVECONTEXT_H__

#include "stdinclude.h"

class CGLMatrixContext
{
public:
CGLMatrixContext();
~CGLMatrixContext();
};

inline CGLMatrixContext::CGLMatrixContext()
{
glPushMatrix();
}

inline CGLMatrixContext::~CGLMatrixContext()
{
glPopMatrix();
}

class CGLAttributeContext
{
public:
~CGLAttributeContext();
};

{
}

inline CGLAttributeContext::~CGLAttributeContext()
{
glPopAttrib();
}

class CGLTextureContext : public CGLAttributeContext
{
public:
CGLTextureContext();
};

inline CGLTextureContext::CGLTextureContext() : CGLAttributeContext(GL_TEXTURE_BIT)
{
}

class CGLCurrentContext : public CGLAttributeContext
{
public:
CGLCurrentContext();
};

inline CGLCurrentContext::CGLCurrentContext() : CGLAttributeContext(GL_CURRENT_BIT)
{
}

class CGLLightingContext : public CGLAttributeContext
{
public:
CGLLightingContext();
};

inline CGLLightingContext::CGLLightingContext() : CGLAttributeContext(GL_LIGHTING_BIT)
{
}

class CGLEnableContext : public CGLAttributeContext
{
public:
CGLEnableContext();
};

inline CGLEnableContext::CGLEnableContext() : CGLAttributeContext(GL_ENABLE_BIT)
{
}

#endif // _GLSAVECONTEXT_H__


- sighuh? [edited by - redragon on March 16, 2003 7:50:08 PM] [edited by - redragon on March 16, 2003 10:25:26 PM]

##### Share on other sites
The ideea is good ... But I think (from my knowledge) that the class is still created during runtime and allthough the functions are inline, there will be some time lost during the creation of the class ... This may be very wrong The ideea is GOOD

Check out Stargate

##### Share on other sites
yes. it is a nice idea.

generally, the more independant of openGL you can make your code, the better (my opinion anyway). Consider what you have done now if some day you wanted to convert to direct3D. This sort of thing can be taken further.

| - Project-X - my mega project.. getting warmer - | - adDeath - an ad blocker I made - | - email me - |

##### Share on other sites
This kind of a thing (automatization) was discussed in the General Programming forum a half year ago or so and the general conclusion reached there was something like this: you can use it for your own projects, but don''t go pulling stuff like this in commercial products where there''s the chance that the source code will have to be edited by other people that initially know nothing about it. I agree with this opinion - even though it may be very clear and useful to you, it can cloak (as in "make invisible") parts of the code in a way that make reading your code a real pain/impossible. Something to think about.

I personally prefer splitting up my rendering (and other) code into sections:

  void DrawMeStuff(){Display->Reset();Camera->Update();Frustum->Cull();World->Draw();Actors->Draw();//blah blah}

If you combine this with descriptive names, it''s is a lot easier to understand IMO.

Crispy

##### Share on other sites
Anyone ever have a look at the source to Q3 Radiant? It appears that very few raw Open GL functions are left, most of them are renamed to QGLfuncName (quake GL). Not exactly sure why they did it, so I wouldn''t mind to be enlightend.

##### Share on other sites
quote:
Original post by Crispy
This kind of a thing (automatization) was discussed in the General Programming forum a half year ago or so and the general conclusion reached there was something like this: you can use it for your own projects, but don't go pulling stuff like this in commercial products where there's the chance that the source code will have to be edited by other people that initially know nothing about it. I agree with this opinion - even though it may be very clear and useful to you, it can cloak (as in "make invisible") parts of the code in a way that make reading your code a real pain/impossible. Something to think about.

My only thought would be it's quite common in Win32 code to do this...as well as a couple other commercial apps like AutoCAD. Was where the thought sprang from. I see your point though...I suppose it's a stylistic difference, on if you're writting your own engine, or an engine that uses OpenGL.
- sighuh?

[edited by - redragon on March 17, 2003 10:32:50 PM]

• ### Forum Statistics

• Total Topics
628333
• Total Posts
2982139

• 9
• 24
• 9
• 9
• 13