Comments on: Sad facts about OpenGL extension libraries

By: SS

SS — Fri, 16 Mar 2012 00:01:50 +0000

P.S. SFML is made of awesome. I also recommend SFGUI, which is an additional library that uses SFML and OpenGL (if I’m not mistaken) to give you the tools to write forms applications (sorta like .Net… except portable and less bloaty).

By: SS

SS — Fri, 16 Mar 2012 00:00:19 +0000

I had the same problem, but eventually discovered (maybe this is different after all this time?) that if I included the GLEW paths in my project search directories, defined “GLEW_STATIC” in the #DEFINE project build options tab (I did mention I’m running Code::Blocks?), and linked the following (with the latest MinGW):
-l glew32s
-l glu32
Then the binaries work after all, despite everyone saying that MinGW has trouble with them precisely because they’re for VC++. (I did have a lot of trouble finding the right options to make this work, but somehow I did and it does. Maybe it’s sub-optimal, though; see note below.)

However, I will have to try the latest GLEE and compare 1) ease of installation/use and 2) speed of end result. I have an example that someone compiled with GLEE and I compiled with GLEW and their binary is faster, but they might’ve set higher optimisation flags than I or something.

By: Brandon J. Van Every

Brandon J. Van Every — Sun, 11 Dec 2011 01:21:28 +0000

Alfonse Reinheart maintains XML files of the OpenGL types and function interfaces. It’s easier than working with .spec files in most instances, and he’s corrected some errors in the .spec files as well. https://bitbucket.org/alfonse/gl-xml-specs/downloads This doesn’t solve the problem of “infinite variety” but it does help if you don’t like the available options for some reason and want to roll your own solution.

By: Gregory

Gregory — Sat, 10 Dec 2011 17:57:16 +0000

Did the situation improve?

So far I found: glee, glew, gl3w, glex2, biggle… Too many options doesn’t help

By: Brandon J. Van Every

Brandon J. Van Every — Thu, 13 Oct 2011 06:06:01 +0000

Some of the .spec files refer to something called “libspec”. I imagine this is, or was, a C library for parsing the .spec files. I found some code for that in the old SGI Sample Implementation, but I haven’t found any modern supported equivalent. Even if the .spec format is not “modern,” it seems rational to have some standard C code available to parse and work with that format. Where is that code? Does Khronos have it somewhere and just doesn’t release it? I am still digging.

By: Josh Simmons

Josh Simmons — Sun, 21 Aug 2011 02:30:07 +0000

The real problem here is the core and extensions are supplied in rubbish .spec and .txt files that are painful at best to parse and use. If Khronos got around to modernising their pipeline (oh god please not XML, but even that would be better than the current situation) then these libraries would be much easier to write, especially for languages that are not C or C++.

By: susheel

susheel — Sun, 19 Jun 2011 13:45:35 +0000

I have been using GLee without any problems whatsoever for 5 years in our product/engine. The website often doesn’t reflect the latest supported extensions, but the library usually is pretty fast at picking up newer extensions. It is NOT hard-coded and is generated automatically from the OpenGL registry http://www.opengl.org/registry/ It currently supports 4.1 and has been supporting 4.0 for sometime now. You just need to pick the latest source from the sourceforge page http://sourceforge.net/projects/glee/

GLee is by far the easiest to use of all the extension libraries and has a liberal BSD license, which allows static linking for all types of projects.

By: GTD

GTD — Mon, 18 Apr 2011 13:26:38 +0000

Even tho this seems a bit old post, I’d like to point out that GLee now supports OpenGL 4.0. It’s not written on their website but GLee on their SVN repo does support OpenGL 4.0. I started to use it when having some really weird segfault occuring when calling opengl 3.0+ features, with GLEW (eventho I could fetch the fn pointers thru wglGetProcAddress()… it’s still a mystery to me).

Also GLee is totally transparent, no initialization needed. #include and #pragma comment(lib, “glee.lib”), et voila!

By: eyebex

eyebex — Wed, 05 May 2010 17:49:49 +0000

As an update to my previous comment, GLEX [1] (note that the URL has changed) has become a semi-rewritten companion simply called GLEX 2 [2]. While GLEX 1 parses the human-readable *.txt extension specification text files, GLEX 2 parses the *.spec specification files. As a result, GLEX 2 can generate code to initialize core functions in addition to code to initialize extension functions.

[1] http://gale.berlios.de/glex1/
[2] http://gale.berlios.de/glex2/

By: MaNiAc

MaNiAc — Wed, 05 May 2010 12:43:08 +0000

Don’t say such things! I was planning to change to ATi, but this… meh… ruined my day! Are they back to their “crap driver” era again or what?

(*tries to forget the forceware that fried some GF cards lately* Nah, it didn’t happen. Really… oh wait. )