Jump to content
  • Advertisement
Sign in to follow this  
pseudomarvin

OpenGL Manually loading OpenGL functions on Windows

This topic is 855 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement

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

Share this post


Link to post
Share on other sites

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)?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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....

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!