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.

[Groovounet]

I had a look at the ClanLib wrapper and I don't think it would be anything close to the way to go for a C++ OpenGL wrapper.

[aqnuep]

I've started to work on the OpenGL C++ wrapper what I was talking about. I would be still interested in having some board where we can discuss the pros and contras for various design approaches.

Actually I want to deal only with GL3+ core features so it is much simpler than I thought (at least from the size point of view as design is still not so simple).

I wanted to go with the naming conventions of how they made the cl.hpp for OpenCL, however having drawing routines named like:

context.drawElements(...)

seemed inconvenient for me so I've rather gone with the so called C++ Coding Standard ended up with a more natural method naming convention:

context.DrawElements(...)

Besides that I wanted to emphasize the nature of state modification commands so I replaced calls like:

context.BlendFunc(...)
context.ColorMask(...)

with ones that have the Set* prefix thus clearly showing their purposes:

context.SetBlendFunc(...)
context.SetColorMask(...)

As binding objects for rendering is also state change, I rather replaced the Bind* prefices also with Set* prefices:

context.SetVertexArray(...)
context.SetTexture(...)

I also try to avoid the need as often as possible to use target specifiers so such new methods were introduced:

context.SetReadFramebuffer(...)
context.SetWriteFramebuffer(...)
context.SetUniformBuffer(...)

I'm progressing with the library pretty well but very often meet critical design questions where the word of more programmers would be benefitial so I would encourage you to join me in the discussions in some way.

Also, besides GL++ I will most probably introduce other headers like WGL++ and GLX++ for context creation and stuff just for convenience.

Groovounet: I'm thinking about interacting in the header with GLM as in many cases the generalized vector and matrix variables of GLM would be convenient to use (e.g. uniform value setting). So I would definitely expect your participation in the discussions about design issues.

[aqnuep]

Yeah, and one more thing: I introduced some lightweight reference counting mechanism as currently OpenGL lacks of reference counted objects.

Obviously ctor, dtor, copy ctor and = operator has been implemented accordingly.

[Groovounet]

I always have an issue with custom conventions. I don't believe in truth, I believe in agreements which are challenging enough.

Custom conventions are certainly nice for those who use them but for the others... I'm not sure.

If this project belong to OpenGL, I think is should follows as much as possible the Khronos Group conventions because they have been agreed among talented OpenGL programmers and I find quite pretentious to assume we could do better. This said, the OpenGL specification is full stupid choices but compare to the great stuff it must be not so bad.

Personally, if I was writing an object oriented C++ wrapper I would follow as much as possible the OpenCL C++ wrapper.

I think it's hard to agree on C, it's much more harder to agree on C++.

Regarding GLM, the pain comes from the C API which has a different function for every uniform (eg) types... On the wrapper side it's not many choices but writing each single function but I think it would be great to design this part in a way that the library user would be able to use template all the way in its code which is pretty straight forward to provide.