Status of GL extension libraries

Started by
1 comment, last by DemonDar 9 years, 8 months ago

Don't blame me for criticizing existing libraries, they are good, but they could be even better.

Here are my main complaints:

GLEW:

- Simply huge. 1 Mb only for the header: If I'm writing code against version 3.3, there's nothing that prevent me to accidentally call some deprecated function (if I'm lucky because when requesting core 3.3 those functions will simply crash). Or if I'm unlucky some supported extension for core 4.0 that will not work on 3.3 machines

- Code generation is not documented, Is theorically possible to generate code for just version 3.3, I tried and failed, the documentation simply says "those are the extensions to be included for generate the full headers and source files." u.u any attemp to change those will result in uncorrect files :/ (error in the code generator, or files that does not compile correctly)

glLoadGen:

-At the beginning I was very happy with that library: it generates headers and source files for the version of OpenGL you desire and it does that with your preferred style (inlined cpp functions or glew like, namespace "gl" or not etc.). However it seems that glLoadGen is no longer maintained: there are dozens of reported issues (and also good features requests!), pull and merge requests without answer from its maintainer (there are also unofficial forks with some fixed bugs for some 3d engines, nothing I really need because those are fixs for GL 2.1)

-glLoadGen does not use "dllImport/dllexport", so I can't compile it as DLL on Windows, but that's not a real issue. (its creator claim it to be a feature indeed)

- GLEW still allows to check if something is supported and skip its usage even on non 3.3 machines (for example Geometry shaders!)

However both libraries lack one thing that I think would be usefull: GLTypes. Assume you create a texture class, that class will have a TextureObject member so a GLEnum, so you need to include whole GLEW/GLG just for a unsigned int! (O_O). Would be nice somone creates a GLTypes header for that reason..

My dream right now:

- GLEW code for just OpenGL 3.3 reduced at bare minimum (does anyone know how to generate the few hundreds kylobytes files for that? I thinke would be nice to document how to create GLEW for most common OpenGL core versions.)

- Separated headers for GL Objects Types and common parameters (Actually looking at GLEW I see it also includes "windows.h" for certain types, the ideal GLTypes header should just have typedefed types, wihtout really including anything. (if a types really depend on system headers, than just strip that from GLTypes header and keep it in "glew.h".

A simple example:

glewTypes.h


#ifndef GLEW_GL_TYPES_HEADER // guards
#define GLEW_GL_TYPES_HEADER
#if PLATFORM
    typedef   GLenum  unsigned int;
   //bla bla

#else if PLATFORM2
//...
#endif

#endif // guard

new glew.h


#ifndef GLEW_GL_TYPES_HEADER //pre-guard
 #include <glewTypes.h>
#endif

//...
#include <windows.h> //if we are on windows

//...
Advertisement
The OpenGL APIs are defined in XML specification files these days to allow people to automate the generation of header files. You can find the details here. As well as the XML specs, there's enough documentation and example code that developing something to produce your own core profile version specific header files should be relatively easy.

O_O incredible thanks! I still find links to old .spec files. Anyway digging into XML and python will be a little overkill but probably worth :)

This topic is closed to new replies.

Advertisement