Loading OpenGL without GLEW

Apoorva Joshi  —  1 year, 6 months ago

This article is a result of my experiences and experiments with using OpenGL for Papaya. My first few weeks learning OpenGL were challenging, because it was very different than most of the APIs I had interacted with up to that point. I’m taking Julia Evans’ advice, and hence writing this blog post because it would certainly have helped me a year ago. Intermediate or experienced programmers may want to skip this explanation entirely.

The complete OpenGL loader code described in this post is located here. Note that the code may change in the future, so the link points to the file as it existed at the time when this post was written. This code was written to cover Papaya’s usage of OpenGL. You may need to add further functions/constants manually depending on your program’s usage.

What follows, is hopefully beginner-friendly explanation.


Full post on my blog
#8147 Mārtiņš Možeiko  —  1 year, 6 months ago [Edited 58 minutes later]
When creating such minimal GL loader I recommend to avoid #including <windows.h> there. Just define what you need manually (like WINAPI for 32-bit and LoadLibrary/GetProcAddress, but that is not needed for 64-bit platform). There are very few things GL needs from windows header.

Also join together PAPAYA_GL_LIST_WIN32 and PAPAYA_GL_LIST. First ask proc address with wglGetProcAddress as you are already doing, if that returns NULL try GetProcAddress using opengl32 module for GL1.1 functions. This way you won't need to look up all the time which function it is 1.1 or later when adding new funcs. This is how I do the GL loader.

That said for quick experimentation I recommend to take a look at glad: http://glad.dav1d.de/ It generates header/loader only for version/extensions/profile you want.
#8148 Alex Baines  —  1 year, 6 months ago
This looks very nice. One thing to look out for on Linux though, is that glXGetProcAddress can return non-null even if a function is not available[0]. You must check the context's version number and/or extension string to determine if a function is available.

[0]: https://dri.freedesktop.org/wiki/glXGetProcAddressNeverReturnsNULL/
#8258 Apoorva Joshi  —  1 year, 6 months ago
Thanks for the feedback. :)

@mmozeiko: Not including windows.h is a valid point. A lot of bloat there, to be included in each and every header. I will look at moving this to the implementation file. It is hard to do this very cleanly in the case of Windows, because the API insists on #defining various things like WINAPI and APIENTRY. Takes a bit of #ifdef'ing and #undef'ing to get it to compile without warnings. You do have a valid point, though, and I will look at moving towards removing windows.h from the header section. I've already moved Linux's dlfcn.h into the implementation section.

@isofaras: I'm just using dlsym to load the gl function addresses directly from libGL.so (on both, AMD and NVIDIA). The Linux library does seem to have all of these functions directly exposed. If I do run into a function that isn't implemented like this, I will use glXGetProcAddress, and will keep your info in mind. :)
Log in to comment