OpenGL inside DLL issues

Has anyone had any trouble or know anything in particular that I need to keep in mind when I keep most of my OpenGL calls inside of a DLL? In particular we have this set up that we are having a lot of trouble with:

OpenGL graphics layer (DLLized)
Game(DLLized) (calls OpenGL)
Launcher (calls each Game DLL which in turn loads the Graphics layer appropriate)

more specifically we’re getting issues related to textures being completely white and wglMakeCurrent failing with error code 2004 and/or 6. On occasion it works fine and runs straight through without error.

If anyone has any recommendations or things to keep in mind, that’d be great. I’m not looking for specific answers b/c I believe it is something small we’ll find later, but mainly just things to keep in mind when working with OpenGL inside of a DLL.

Currently we’re exporting our symbols from the DLL using the extern “C” {__declspec(dllexport)} method. Thanks for any hints or advice you can give me.

I assume you are loading your graphics layer DLL dynamically.

What driver & card are you having problems with?
Are you doing things in DllMain of your graphics layer DLL you shouldn’t be doing? (for starters, you shouldn’t be calling LoadLibrary inside DllMain).
Do you have the same problem with Microsoft’s OpenGL 1.1 software renderer?
Are you creating threads before loading your layer DLL? (DLLs do not receive thread init calls for threads created before the DLL was loaded).
Are you calling DisableThreadLibraryCalls for your layer DLL?
Are you loading other third party DLLs (non-Microsoft) before loading your layer DLL? If so, try to load the layer DLL early. It’s unlikely, but the ICD may be running out of TLS entries.

Not that I"m looking for any sort of specific solution b/c I don’t expect anyone to be able to solve the problem that is in our 100K+ lines of code, but the TLS thing has led me on a thread battle that may be fruitful. Apparently we’ve been compiling the graphics layer dlls using Multithreaded DLL’s. Our main problem we’ve been having is the crash with wglMakeCurrent and I figure this may happen if the context accidently jumps to a thread it doesn’t exist on and tries to make it current. Does this even make since? Are the DLLs really on another thread altogether? How do the OpenGL calls even work if the app is making specific opengl calls in one thread and it’s swapping buffers on another… Can it be that the DLL is threaded without us putting in the code?

If you make your calls inside the DLL or not is really the same, you just have to be shure that all your rendering code (that is, code which makes OpenGL calls) is called in the same thread, so only call the DLL entries in your rendering thread. If you get error, this is most probably due some hidden bug or driver issue.

Originally posted by atreyu:
Apparently we’ve been compiling the graphics layer dlls using Multithreaded DLL’s.

I would dare to say that’s the right thing to do when you have multiple threads.

Our main problem we’ve been having is the crash with wglMakeCurrent and I figure this may happen if the context accidently jumps to a thread it doesn’t exist on and tries to make it current.

OpenGL contexts don’t “exist” on threads. They are current or they are not.
If a context is current in a thread and you try to make it current in a different one, opengl32.dll will fail to even call the ICD and return an error to you.
If you create threads before loading the opengl32.dll and the ICD is not programmed to deal with that eventuality, you will also get corruption.

If you are able to answer the questions I asked you above, you may be able to narrow it down.

Does this even make since? Are the DLLs really on another thread altogether? How do the OpenGL calls even work if the app is making specific opengl calls in one thread and it’s swapping buffers on another… Can it be that the DLL is threaded without us putting in the code?

There’s no such thing as “threaded” DLLs. There are “thread-safe” and “non-thread-safe” DLLs.

If you use a non-thread-safe DLL in a multithreaded program, what you will get is data corruption.

If you use a thread-safe DLL in a single-threaded program, the only thing you may notice is that it’s slower, due to the precautions it takes to guarantee the tread-safety. Other than that it should work fine.

Also, if you use the CRT, verify that you are initializing it properly .

By the way,

C:\>net helpmsg 2004
The requested transformation operation is not supported.
C:\>net helpmsg 6
The handle is invalid.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.