Manually loading OpenGL functions on Windows

Started by
7 comments, last by 21st Century Moose 7 years, 11 months ago

I know manually loading GL functions is usually a bad idea but I am making a 64kB demo (exe cannot go beyond this size limit) so using GLEW does not seem to be an option. It is enough to get this working on Windows.

In VS 2015 I link with opengl32.lib and then I use a helper function like this:


void *GetAnyGLFuncAddress(const char *name)
{
	void *p = (void *)wglGetProcAddress(name);
	if (p == 0 || (p == (void*)0x1) || (p == (void*)0x2) || (p == (void*)0x3) || (p == (void*)-1))
	{
		HMODULE module = LoadLibraryA("opengl32.dll");
		p = (void *)GetProcAddress(module, name);
	}
	return p;
}

An example usage:


// GL functions header, definitions copied from https://www.opengl.org/registry/api/GL/glext.h
#define GLAPIENTRY __stdcall
typedef void (GLAPIENTRY *PFGLCLEAR)(GLuint mask);
typedef GLuint(GLAPIENTRY * PFNGLCREATEPROGRAMPROC) (void);

// program
PFGLCLEAR glClear = (PFGLCLEAR) GetAnyGLFuncAddress("glClear");
PFNGLCREATEPROGRAMPROC glCreateProgram = (PFNGLCREATEPROGRAMPROC)GetAnyGLFuncAddress("glCreateProgram");

This approach worked for glClear and glClearColor but getting any other function pointers after that failed (glCreateProgram, glCreateShader...). Why doesn't it work, and why does it work for those first two? Thanks.

Advertisement

Okay so i found the answer. The OpenGL context must already be created before calling wglGetProcAddress. See this http://stackoverflow.com/questions/21769427/wglgetprocaddress-returns-null for more info.

Incidentally, what this also means is that your fallback of LoadLibrary and GetProcAddress won't work for functions higher than GL 1.1. What was previously happening is that when wglGetProcAddress failed and it routed through your fallback path, it failed to load those functions from Microsoft's opengl32.dll because Microsoft's opengl32.dll does not contain them.

This is all part of the OpenGL ICD driver model and you shouldn't even have a fallback path. Just use wglGetProcAddress in the way it's documented to be used instead: https://msdn.microsoft.com/en-us/library/windows/desktop/dd374386%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

I am not saying that you are not right but for glClear, wglGetProcAddress returns NULL and GetProcAddress gets the right pointer. But that seems to be an exception (probably one of the older functions)?

I have never dealt with working with loading GL functions by hand but that does not surprise me. The documentation of wglGetProcAddress says

The wglGetProcAddress function returns the address of an OpenGL extension function [...]

. glClear is to my knowledge as core as you can get in any version of OpenGL so should never be retrievable via wglGetProcAddress.

I am not saying that you are not right but for glClear, wglGetProcAddress returns NULL and GetProcAddress gets the right pointer. But that seems to be an exception (probably one of the older functions)?

If it's in Microsoft's <gl/gl.h> then it's also in their opengl32.dll and their opengl32.lib; it's a GL 1.0 or 1.1 function and it cannot be obtained via wglGetProcAddress.

To be honest you're making things more complicated for yourself than they need be. The process of linking to and using OpenGL on Windows is simple so long as you follow the rules and are aware of what functions are available with each GL version.

You #include <gl/gl.h>

You statically link to opengl32.lib, via either project settings or #pragma comment (lib, "opengl32.lib")

At this stage all of OpenGL 1.0 and 1.1 is available to you without needing to do anything else. No need for GetProcAddress, no need for wglGetProcAddress.

To access higher functionality (OpenGL 1.2 or higher) you either load them manually yourself, using wglGetProcAddress or use an extension loading library, such as GLEW. This is the part where you make your secision to not use GLEW owing to wanting to keep the executable size down.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

I also use the fallback method to get pointers for the old functions.. I think that's what common extension libraries do as well, though I haven't actually checked..

If including a recent glcorearb.h header without the prototypes-define it won't define the old prototypes either, but will define the function pointer types for the 1.0 functions etc. as well. And with the prototypes-define it will add prototypes for all functions including newer ones.

On Linux all function pointers can be obtained with glXGetProcAddress so there no fallback is required.

If still linking to opengl32.lib one could of course do another fallback, something like mynamespace::glClear = ::glClear instead of GetProcAddress...

To be honest you're making things more complicated for yourself than they need be. The process of linking to and using OpenGL on Windows is simple so long as you follow the rules and are aware of what functions are available with each GL version.

You #include <gl/gl.h>
You statically link to opengl32.lib, via either project settings or #pragma comment (lib, "opengl32.lib")

At this stage all of OpenGL 1.0 and 1.1 is available to you without needing to do anything else. No need for GetProcAddress, no need for wglGetProcAddress.


For typical windows apps, you're correct. For minimal 64k apps though, manually loading OpenGL is not a bad idea. You can allocate a table to store the pointers at runtime, which actually cuts down the number of global variables in your exe (which would have been used to store each function pointer to a glcall you are using). You can also concatonate strings to build up the function names to extract. It may seem like overkill, but it does actually cut down on memory usage. It's a very common approach in the demo scene....

To be honest you're making things more complicated for yourself than they need be. The process of linking to and using OpenGL on Windows is simple so long as you follow the rules and are aware of what functions are available with each GL version.

You #include <gl/gl.h>
You statically link to opengl32.lib, via either project settings or #pragma comment (lib, "opengl32.lib")

At this stage all of OpenGL 1.0 and 1.1 is available to you without needing to do anything else. No need for GetProcAddress, no need for wglGetProcAddress.


For typical windows apps, you're correct. For minimal 64k apps though, manually loading OpenGL is not a bad idea. You can allocate a table to store the pointers at runtime, which actually cuts down the number of global variables in your exe (which would have been used to store each function pointer to a glcall you are using). You can also concatonate strings to build up the function names to extract. It may seem like overkill, but it does actually cut down on memory usage. It's a very common approach in the demo scene....

True, but I'd suggest get it working the right way first, then look to reduce executable size. At least that way you stand a chance of knowing where your problems are coming from.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

This topic is closed to new replies.

Advertisement