Everybody who used to make OpenGL applications, whether it be a simple triangle-of-death demo or a comprehensive rendering engine at some point needs to use extensions or later OpenGL versions. Usually many people start this by creating their own initializer library that loads the required entry points from the OpenGL library by hand. What is sure is that at some point everybody realizes that this process is just a waste of time and starts to look for an extension loading library out there. This is the obvious solution as it makes no sense to reinvent the wheel all the time. However, after using a particular one from the repertoire of these libraries one will face the problem that they are not that nice as they seemed before. In this article I will talk about some of these libraries and some of my thoughts about them.

OpenGL is evolving in a more and more fast manner nowadays and it is crucial to have an extension library that serves your needs and is up-to-date enough so you can easily adopt the latest features of the API. The sad truth is that this is not the case, at least there are some pitfalls that can cause you a lot of headaches when relying on these libraries.

This week, I planned to create a new version of my Nature demo first presented in my article Instance culling using geometry shaders that adopts the latest features of OpenGL 3.3, especially concentrating on how GL_ARB_instanced_arrays can improve the throughput of the technique. I know that I would be able to do this without actual OpenGL 3.3 support from the extension library by using the extension itself rather than the core functions, but how it would like if I publish a demo stating it’s OpenGL 3.3 but I use internally OpenGL 3.2 with extensions? That would be just too airy.

As you may know, I used GLEW in my previous demo as the extension library of choice, but I had some difficulties at that time as well. This time I got pissed off much easier as the bad memories put their mark on my preconception. I will talk about the reasons behind this later. First I would like to clarify the subject behind this article.

As I had several bad experiences with various libraries, especially this week, I thought it would be nice to write a summary of the possibilities have regarding to the topic and what are the advantages and disadvantages of each, at least based on my experiences. The libraries I will talk about are: GLee, GLEW and GLLoader. I don’t want to blame the people who developed these libraries so excuse me if I will be sometimes too harsh as I should be already satisfied with the fact that at least I have the opportunity to use such open source tools instead of reinventing the wheel myself, but if you understand the background of my feelings you may easily accept why I’m unsatisfied…

A few years ago I was developing all my hobby projects in Delphi/Free Pascal due to the great facilities and the nicer coding style that the language provides. I changed my mind in the recent past and switched to C/C++ because of the greater developer community behind the languages and to eliminate the need to develop supporting libraries for myself that already exist for other languages. So my assumption was that if I do this shift I will have far less problems with gathering the modules that will do the secondary stuff needed by my projects. Unfortunately, I soon became very disappointed due to the quality properties of those third-party tools that I thought can be the holy grail for my hobby projects. Of course, I had many good experiences, there is also one that I shared with you. But enough from the doublespeak, let’s see what we have…

GLee (GL Easy Extension library)

I don’t have too much experience with this library as the last time I used it was years ago. Because of this, it is hard to say too much about it but I think one simple facts are enough to justify why this library should not be the primary choice for enthusiasts: it is pretty outdated as it supports only OpenGL 3.0 that has been released quite a long time ago. It even seems to me that it is no longer developed. It is written as hard-coded source that is not even an easy to maintain library, most probably that is the reason behind the disappearance of it.

Beside that, there are also some good things about this one. Namely it comes with a source code that can be easily integrated and compiled without the need of any third party software and I seriously consider this as an advantage, later you will understand why. Also, it comes with BSD license that allows enough freedom for almost any project.

Anyway, even though this library is simple and good for many applications, the fact that it’s outdated and not really maintained is a warning sign that every developer starting to use it must consider.

GLEW (OpenGL Extension Wrangler library)

As I mentioned earlier, this is the library I used for my latest demos so I have up-to-date information about it. The one thing I like in it the most is that there is an excellent design idea behind it that, in theory, would make it the most superior library for the purpose. I intensionally used the expression “in theory”, I will explain it soon. The library comes with BSD or MIT license that is also a nice thing.

GLEW has a very nice build system behind it that can automatically download extension specifications from the OpenGL Extension Registry and generate the library using that information. Unfortunately, this build system is the one that can make you much headache if you would like to use it under Windows as it relies on many POSIX tools.

According to the homepage, GLEW shall be compiled very easy even under Windows with cygwin. I have only two problems with this:

  1. I use Windows and I use MinGW for compilation and even with the tool-set of MSYS the building of the library renders almost impossible.
  2. As a last resort, I also tried cygwin but had similar results with it as well.

Actually this wouldn’t be a problem on its own if the project maintainers would release Windows binary versions at least in case of every update of the OpenGL core specification or, at least, they would generate the source files in such cases as for compiling the sources themselves there is already a nice Makefile and a Visual Studio project file as well. Unfortunately, this is not the case. I don’t remember when they’ve released the binaries for OpenGL 3.2 but I’m sure it was far after the specification release. Anyway, the best way to solve the problem would be to create a build system that works also on Windows as it makes the library quite inconvenient for Windows developers.

GLLoader (part of Klay Game Engine)

I heard about this one just in the recent past, after the release of OpenGL 3.3 and 4.0. This was the first extension library stating that it’s OpenGL 4.0 capable. Well, there is not too much to complain about this tool, only just a few things:

  • By default, it comes with a dynamic library project file and I don’t really like to supply a DLL with my demos just for extension loading.
  • There are some mistakes in the code (at least I found one related to glMapBufferRange function).

Also, unfortunately, it comes with GPL licensing that is too restrictive for many use cases.

Conclusion

There are actually several possibilities if one has to choose an OpenGL extension library, but unfortunately each has its drawbacks. GLEW would be obviously the most superior solution if there wouldn’t be problems regarding to its build system. I would even consider correcting the problems during compilation (what usually occur due to the code generation as it does not handle all special cases, like it happened earlier with WGL_ARB_create_context that had multiple versions of it).GLee seems to be a definite no, but GLLoader is maybe a factor to consider.

We will see how each project will progress and whether they will care about the minor but annoying problems with their products (I already created some bug/support report regarding to the met issues mentioned). Anyway, currently it seems that this area still has unfilled gaps so one can easily drop in with its own library and capture the attention of developers who are seeking for third-party supplementary tools. My hope is that the developers of GLEW will make a step and resolve the issues thus creating a real plug & play library that everybody can rely upon.