Simple OpenGL 3.2/3.3/4.0 core profile loading

(or life without glew)

Recently I wrote a small (130 lines) Python script that parses GL3/gl3.h header and generates the code needed to load the OpenGL 3 core profile.

I’ve been using glew for the same purpose for some time now but the size of glew always bothered me. It loads every OpenGL extension known to mankind, while I only needed the core OpenGL 3 functionality.

You can find the script at http://github.com/skaslev/gl3w . If you execute it, it will download GL3/gl3.h and generate gl3w.h and gl3w.c which can be statically linked with your OpenGL application. You should include GL3/gl3w.h call gl3wInit() after your window creation and it will load all the functions defined in the OpenGL 3 core profile.

The project is still quite young. There is still no documentation and no error checking. I’ve only tested it on windows, although I believe it should also work on linux. Any feedback and patches are welcome.

Is there any interest in a such package?

Thank you, I get rid of GLEW. ^___^

I have tested on Ubuntu 9.10 and QT 4.7 on a very basic program with VAO.

I think is very interesting on linux system cause a lot of people use the library that came with the distribution that is usually quite old.

+1 from me. Sounds very interesting.

If you could provide some basic documentation, i would try it out.

It loads every OpenGL extension known to mankind, while I only needed the core OpenGL 3 functionality.

You need more than core GL. Without extensions, you wouldn’t have DXT compressed textures (EXT_texture_compression_s3tc) or anisotropic filtering (EXT_texture_filter_anisotropic).

In any way, why are you surprised that the OpenGL Extension Wrangler loads extensions?

Thank you all for the comments.

@Alfonse Reinheart
I personally try to stick with core OpenGL functions. I believe that with the recent trend of frequent OpenGL spec releases there will be less and less need for extensions.
I don’t try to criticize glew in any way. Glew is great for what it does. I just needed something smaller and simpler.

@Fugitive
I will write some documentation very soon. Until then here’s a quick summary. There are only two functions in the api – gl3wInit which should be called after you create your OpenGL context, and gl3wIsSupported which can query whether specific version of OpenGL is provided.

Here’s a an example of using gl3w with glut:


#include <GL3/gl3w.h>
#include <GL/glut.h>
#include "log.h"

// ...

int main(int argc, char **argv)
{
	glutInit(&argc, argv);
	glutInitDisplayMode(GLUT_RGBA | GLUT_DEPTH | GLUT_DOUBLE);
	glutInitWindowSize(width, height);
	glutCreateWindow("cookie");

	glutReshapeFunc(reshape);
	glutDisplayFunc(display);
	glutKeyboardFunc(keyboard);
	glutSpecialFunc(special);
	glutMouseFunc(mouse);
	glutMotionFunc(motion);

	if (gl3wInit())
		fatal("failed to initialize OpenGL");
	info("OpenGL %s, GLSL %s", glGetString(GL_VERSION),
	     glGetString(GL_SHADING_LANGUAGE_VERSION));
	info("%s by %s", glGetString(GL_RENDERER), glGetString(GL_VENDOR));
	if (!gl3wIsSupported(3, 2))
		fatal("OpenGL 3.2 not supported");
	//...
}

Nice! Now here is the million-dollar question: Is the Borland/Embarcadero compiler supported?!

@Fugitive
I’ve only tested it with MSVC on windows and gcc on linux. The generated code is ANSI C so I’ll be very surprised you face any problems across different compilers.

There was a recent rant by Daniel Rákos about OpenGL extension libraries. From my point of view, gl3w doesn’t share the deficiencies of similar libraries he criticized:

  • gl3w_gen.py depends only on python 2.6, which works flawlessly across win32 and posix systems[] gl3w is basically maintenance-free, meaning it does need to get changed when a new version of OpenGL comes along. When Khronos update the OpenGL spec and the gl3.h header online, you only need to rerun the script to get access to the new functions.[] both the script and the generated source are in the public domain. You can do whatever you want with them and don’t worry about licensing what-so-ever.[*] the gl3w_gen.py script is really really simple and straightforward so you can change it to suite your specific needs without any hassle if you feel so

@Rosario Leonardi
Nice to hear this. Don’t hesitate to contact me if you stumble upon any problem with it.

When Khronos update the OpenGL spec and the gl3.h header online, you only need to rerun the script to get access to the new functions.

I would be very concerned about an extension loading library that runs off of gl3.h, rather than off the .spec files directly. Especially considering how buggy gl3.h is.

the gl3w_gen.py script is really really simple and straightforward so you can change it to suite your specific needs without any hassle if you feel so

If you know Python of course. Isn’t Python one of those languages that labors under the delusion that whitespace should actually be part of the grammar?

I would be very concerned about an extension loading library that runs off of gl3.h, rather than off the .spec files directly. Especially considering how buggy gl3.h is.

Interesting. I’ve never heard of any issues with gl3.h before. Can you share more info?

I guess I’m just counting on Khronos to do a good job with describing the OpenGL functions in the gl3.h header. If there are any issues with gl3.h, a possible solutions would be not to download gl3.h from Khronos directly, but from a different location with a fixed version of it.

Just wanted to let you know that I uploaded some documentation to the gl3w homepage at http://github.com/skaslev/gl3w .

Have fun.

If there are any issues with gl3.h, a possible solutions would be not to download gl3.h from Khronos directly, but from a different location with a fixed version of it.

Am I the only one that find this very disturbing?

BTW: I’m not use to python at all and I’m wondering if there is a compiled version of gl3w.h and gl3w.c somewhere?