Wondered if it is be clever to write a OpenGL class to support object oriented opengl programming? I know it would be possible, but there are several problems to be considered: - OpenGL can be easily improved by extensions. How would one do that with classes? - Would you just update the c++ source code of your class to support further extensions or derive new interfaces from your old OpenGL class? (This would be much like DirectX was/is, if I remember correctly) However, I can also see some advantages in that: - If OGL was loaded dynamically (calling GetProcAddress on win32 platforms), we could use static function pointers to store the addresses. Going that way, the functions could be easily called form an inline class function. - Specific parts of OGL could be wrapped up in other classes to make it even simpler. eg. a texture class or a viewport class. I''m sure some of you have already implemented (or tried to) a similar solution. So there should be enogh to discuss and I''m really looking forward to your views on that topic.

Yes, it has been done before. I think that wwww.opengl.org has some links.

I was not asking if there is already such a thing like a C++ OGL wrapper (maybe the title is a bit confusing?). I''d like to discuss the advantages and disadvantages....

I have made an OpenGL framework that includes texture loading, input, and sound support. You can download it at http://welcome.to/zacksmith/

Tell me what you think of it.

Zack

Nice work there, but you did not really writte a C++ - version of opengl, you just wrote a class to provide all the functionality you needed in your program. But I doubt that you just want to display rotating cubes all the time So the class should be a little more general and you should probably split your current class in an API only class (lets call it an API-class) and a renderer class. That way, you could just reuse the application interfae class in your programs and derive new rendering classes (to fit your needs) from the base rendering class.
I’m trying to describe such an API-class just below.

What I was actually thinking of was to adapt OpenGL to C++ to provide helper functions and classes to encapsulate the more complex aspects of OGL like for example textures, viewports/rendering contexts (thats what you obviously did) whereas the simple (rendering and state) functions like for example glVertex3f could be called as well and no extra layer of abstraction would be added for those (e.g. DrawColoredTriangleStrip(UVertex* pVertices, int nVertices); )

Some C++ code here:

Very incomplete C++ implementation of the OpenGL-API

class UOpenGLDevice{public:   ... // constructors, destructors and other stuff   //examples for helper functions   UViewport CreateViewport();   void DestroyViewport();   UTexture LoadTexture(UString& Filename);   void KillTexture(   ...   //example for ogl-functions    static inline Vertex3f(GLfloat x, GLfloat y, GLfloat z)   {#ifdef OGL_LINK_DYNAMIC      //if linking dynamically to opengl32.dll      fnVertex(x, y, z);#else      //if statically linking to opengl32.lib      glVertex(x, y, z);#endif   }private:#ifdef OGL_LINK_DYNAMIC   //if we dynamically link opengl32.dll, we have to store   //the function pointers somewhere   static (*fnVertex3f)(GLfloat x, GLfloat y, GLfloat, z);   ... // many other opengl functions#endif}; 

Calling gl-functions

UOpenGLDevice   GL;. //some other code here. //some more code here. //even more code herevoid RenderSomething(){  GL.Begin(GL_POINTS);    GL.Color3ub(0, 0, 0);    GL.Vertex3f(0, 0, 0);  GL.End();} 

Because all the OpenGL functions which are not encapsulated in helper functions or classes are static, there is less overhead than there is with nonstatic member fns because of the hidden this pointer that would be passed unless a function is static. If linking dynamically to opengl (loading the dll by hand with LoadLibrary and getting the addresses of the functions with GetProcAddress on win32 platforms), all we had to do is load the library once the first instance of an UOpenGLDevice is constructed and unload it if the last instance of UOpenGLDevice is destroyed. This could be easily achieved by adding a reference counter to the class that would keep track of how many instances there currently are. Such a (static) ref-counter would be incremented if a new instance of UOpenGLDevice was created but decreased if it was destroyed.

I hope this made a bit more clearer what I was thinking about.

Still looking forward to more opinions and/or suggestions.

ild look into a scenegraph it is a wrapper and much more besides eg commands for shadows reflections etc

http://members.xoom.com/myBollux