Gaining access to OpenGL extensions...

Started by
8 comments, last by V-man 17 years, 8 months ago
Hi there, i have the following problem and would be glad if someone got a clue about this. I wrote a seperate dll for my project in C/C++, which implements rendering functionality with OpenGL. As one part of it the program tries to query for available extensions and stores the function pointers. At least it should... The call for loading the OpenGL32.dll dynamically works, i also get the extensions string, but the calls for receiving pointers to the related functions always return NULL. (My dll needs to link the OpenGL32.dll manually, because i use a layer function for querying symbols inside dlls (which needs the library handle, just like GetProcAddress).) I'm also a bit confused, due to the fact that i can dynamically link the OpenGL32.dll, but i can't find it on my system...

PFNGLMULTITEXCOORD1FARBPROC glMultiTexCoord1fARB;
const char* Extensions = (const char*)glGetString( GL_EXTENSIONS );
void* OpenGL32 = loadLibrary( "OpenGL32" );
assert(OpenGL32);
if( strstr( "GL_ARB_multitexture", Extensions ) )
{
  // This one for example returns 0, for each function i try to query.
  glMultiTexCoord1fARB = findSymbol( OpenGL32, "glMultiTexCoord1fARB" );
  //...
}
Thanks for any help!
Advertisement
Have you been able to get the extensions previously and just now are not able to? It seems entirely possible that you have an older system or outdated OpenGL, which would mean you in fact *don't* have the extensions you're looking for.

Other then that I'm not sure...the code you posted looks perfectly normal for the task at hand.

EDIT: Nevermind, you clearly wouldn't even get to that point in the code if you didn't have the extensions (the strstr() would fail). What does your findSymbol code look like?
Well, i have the newest ATI Catalyst drivers. 3D demos of other engines i run on my computer use the same extensions and the extensions string i receive from OpenGL is pretty long. The only thing i forgot here in this snippet is the explicit cast to PFNGL*-pointer, but this doesn't look like the problem :)

But thanks anyway for the fast reply!

The findSymbol function is just a layer. Corresponding to the operating system it will use LoadLibrary or dlopen (for Windows/Linux). It doesn't mess around with the overloaded pointers, it just does some additional asserts and uses the arguments 1:1 for the implemented function.

void* findSymbol( void* Handle, const char* Name ){assert(Handle);assert(Name);#ifdef WINDOWSreturn LoadLibrary( Handle, Name );#else// ...#endif}
uhm if i recall right the OpenGL32.dll only contains the default MS 1.1 implementation. by loading the dll dynamically that's all you can get, although after you create a render context i'm pretty sure you can still call wglGetProcAdress and get the extensions from whatever ATI/NVIDIA dlls the calls are routed too.
Y
I already thought about the problem relies on the OpenGL32.dll.
Ok...
I think i'll need to replace the findSymbol with wglGetProcAddress or even SDL_GL_GetProcAddress, although i need to link my dll with yet-another-dll like user32.lib or sdl.lib.

But thanks anyway guys, think that's it!
I had to do something similar a while back. I used LoadLibrary to load opengl32.dll. To get core (1.1) functions I used GetProcAddress, however the entry points for extentension functions are defined in the icd, so you have to use wglGetProcAddress to get them. This function is in opengl32.dll however, so you do not need to link to a lib to get it. You can just use GetProcAddress to retrieve wglGetProcAddress.

One problem you may run into is the pixel format functions. Although versions of these exist in opengl32.dll, they do not work if called directly. You need to call them through another library (gdi32). This was not an issue for me as I was writting a replacement opengl32.dll and the app could set up the context through the other lib. I only needed to hook functions called after the context was created.

Let me know if you still have problems, some of this stuff was a little tricky.
Ugh, why not just use GLee?


(~^_^)~ wiggle wiggle ~(^_^~)
If I remember correctly, you have to actually create a rendering context for OpenGL before you can get the extension function pointers, so that could be a reason.
Quote:Original post by Mushu
Ugh, why not just use GLee?


(~^_^)~ wiggle wiggle ~(^_^~)


Yes, that would be my perfered approach. In this case I had to link to the dll directly so I could specify the path. I was using a modified opengl32.dll that I placed in the app's directory. The app would then link to my dll instead of the real dll and I linked to the real dll directly.

Usually I would recomend using a 3rd party extension loader and letting someone else worry about it though.
Yes, you have to have a GL context before calling any wgl or gl function.
Why waste time getting all the function pointers when it's been done in Glee and Glew and other open source projects.
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

This topic is closed to new replies.

Advertisement