Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 08 Dec 2011
Offline Last Active Private

Topics I've Started

Status of GL extension libraries

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



13 December 2011 - 02:34 AM

I have seen much 3D engines wich uses both DirectX and OpenGL, they required a custom matrix class in order to have custom transformations for both API. But now the question is:" Is really worth with OpenGL using glRotate, glTranslate, glScale when I can simply set the GL matrix from a mine matrix class?"

I think that glRotate , glTranslate etc. are provided for simpleness in use, so would be always better using directly matrices? If I want to do a custom scene manager with an animator for each node, I have to recompute all the matrices after every frame. So I have to take the matrix of a parent node and multiply by It the child transformation, than I have the aboslute transformation of that child that now can be rendered (if the parent did the same with its parent too of course). I tried to imagine a system wich uses Only OpenGL functionalities for doing that. But I found that there a limit in the matrix stack so that the maximum scene hierachy depth is 32. (Or more on some machines, but if want compatilibity I need to use lower limit). By the way I think that using OpenGL functionalities for that is both fast(not really needed) and most flexible(apart the limit of depth of 32). What are your thoughts about that? Does anyone seen someone using this system instead of the wide used child-parent model wich is not limited to a depth of 32? Or are glRotate,glTranslate etc. functions too slow because they need communications with videocard? (this depends on video drivers I suppose).

I'm asknig this because I have profiled my animated scene and I found that 27% of the CPU time is matrices computing. So maybe OpenGL provide some usefull functionality to reduce load of that task.