Jump to content

View more

Image of the Day

Boxes as reward for our ranking mode. ヾ(☆▽☆)
#indiedev #gamedev #gameart #screenshotsaturday https://t.co/ALF1InmM7K
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Status of GL extension libraries

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 DemonDar   Members   


Posted 02 August 2014 - 07:37 AM

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


Here are my main complaints:




- 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)





-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:



#ifndef GLEW_GL_TYPES_HEADER // guards
    typedef   GLenum  unsigned int;
   //bla bla

#else if PLATFORM2

#endif // guard

new glew.h

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

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


Edited by DemonDar, 02 August 2014 - 07:47 AM.

#2 dave j   Members   


Posted 03 August 2014 - 05:28 AM

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.

#3 DemonDar   Members   


Posted 03 August 2014 - 08:16 AM

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 :)

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.