OpenGL C++ wrapper

[aqnuep]

Hi,

As far as I know, there is no real C++ wrapper for OpenGL. If there is one, please disprove me.

Most people might think that there is no too much sense for creating a C++ wrapper for OpenGL. That is maybe true, however, with that many object types currently available in OpenGL and having DSA implemented in most drivers maybe it makes sense as it would make the management of the objects more local thus providing better design and easier implementation.

Before you would argue with me, I'm not having difficulties with using the C API as I'm pretty familiar with OpenGL and with almost all the extensions currently supported by vendors, however after seeing that Khronos has created a C++ wrapper for OpenCL I was thinking about that maybe such a header-only OpenGL C++ wrapper would come handy as well. Creating a header only wrapper with inline methods would not even sacrifice any runtime performance.

So my question is whether there is any such a wrapper for OpenGL 3+ core. If not, maybe I will sacrifice some of my time to create one if there is interest for it.

Please feel free to share your thoughts.

[Groovounet]

Hi,

I think that the problem we a C++ OpenGL wrapper is that it's going to be much more complicated to build one where 2 programmers will agree on the design.

The difference between OpenCL and OpenGL is that OpenCL is have a high consistency but OpenGL doesn't and it becomes more and more obvious as the ARB release new specifications...

I like the idea but I'm not sure how it could succeed.

[aqnuep]

Hi,

My plan initially is to create a C++ wrapper for the object handling part of OpenGL so the generic, yet not object oriented elements of the API would be left for the future.

Also, I would be interested to create some virtual "board" where the developers can argue and agree in a common form to make this C++ wrapper a quasi official wrapper instead of having hundreds of different implementations.

[kRogue]

I can see the temptation for a very simple bare-bones C++ wrapper, one can have things like this:

class GLTextureHandle
{
public:
  GLuint m_name;
 
  void
  TextureParameter(GLenum pname, const GLint *v)
  {
    glTextureParameterivEXT(m_name, pname, v);
  }
 
  void
  TextureParameter(GLenum pname, const GLfloat *v)
  {
    glTextureParameterfvEXT(m_name, pname, v);
  }
 
  template<unsigned int N, typename T>
  void
  TextureParameter(GLenum pname, const array<T,N> &amp;v)
  {
    TextureParameter(pname, &amp;v[0]);
  }
 
  void
  getTextureParamter(GLenum pname, GLint *v)
  {
    glGetTextureParameterivEXT(m_name, pname, v);
  }
 
  void
  getTextureParamter(GLenum pname, GLfloat *v)
  {
    glGetTextureParameterivEXT(m_name, pname, v);
  }
 
  template<unsigned int N, typename T>
  array<T,N>
  getTextureParamter(enum pname)
  {
    array<T,N> return_value;
    getTextureParamter(pname, &amp;return_value[0]);
    return return_value;
  }
 
  //etc...
 
}
 
//or potentially do NOT make any member functions to 
//GLTextureHandler and create functions mirroring 
//GL names but such functions taking the type 
//GLTextureHandle as the first argument. Which 
//is better is the subject of flamewars.

Another nice trick to have would be what many C++ folks do anyways in GL:

template<typename T>
struct opengl_trait
{
  typedef T basic_type;
};
 
 
//typetraits for basic types
template<>
struct opengl_trait<GLbyte>
{
  enum { type=GL_BYTE };
  enum { count=1 }; 
  enum { stride=sizeof(signed char) };
  typedef GLbyte basic_type;
};
 
//and so on for basic types...
 
 
template<typename T, unsigned int N>
struct opengl_trait< array<T,N> >
{
  enum { type=opengl_trait<T>::type };
  enum { count=N*opengl_trait<T>::count }; 
  enum { stride=sizeof(array<T,N>) };
 
  typedef typename opengl_trait<T>::basic_type basic_type;
};

which then fits nicely for making tags to feed into a nicer version of glVertexAttribPointer... if your arrays are not interleaved, then the stride you need sizeof(mystruct). Similar template tagging would potentially be nice for glTexImage and it's friends...

But DSA is not core... I would hazard a guess that DSA will sort of sneak into the spec (as we have DSA for uniforms on programs and for manipulating samplers)... what remains is textures, buffer objects, framebuffer objects and renderbuffers... though I think the use cases of renderbuffers for GL on desktop are non-existant now..

I'd wait for for DSA to sneak into the spec first before embarking on making those header file(s). My 2 cents on the whole thing would be to make types that are just handles to GL objects and not representing the objects themselves (i.e. dtor does not call glDelWhatevers), this way one avoids the ctor/dtor/copy ctor "fun".

One needs to make sure the API is that it does not "lose" information and nothing goes wrong in using GL calls directly, this is why I'd emphasize the handler thing.

[rombust]

You may want to have a look at ClanLib ( http://clanlib.org )

The clanDisplay, that the clanGL display target uses, was written like an OpenGL C++ wrapper. (See Sources/GL)

As already stated, it is very tricky to get right, and will not satisfy all programmers. There are always "speed" / "flexibility" / "ease of use" issues that contradict each other.

Since ClanLib has a free (BSD style) license, you can extract the code for your project if you wish.

[Groovounet]

I don't think it would have any "speed" issue at it would be an inline only library.