Just for kicks, I''m trying to make a common API for openGL and d3d. Yet, for some reason, the mere presence of and d3d code in my program causes openGL to fail to initialize. The basic setup i have going is an array of structs full of function pointers, i.e, so I can do things like this: vidAPI[OPENGL]->Load(); vidAPI[DIRECTX]->RenderScene(); Now, I got OpenGL to init just fine, with no directx code in the app at all. I put in the function to load d3d, and now gl can''t get a device context. The strange thing about this is, the d3d code is never even being executed. No compile or link errors, and it''s not crashing, but wglCreateContext() is returning 0. If I comment out this line: vid_d3dInfo.m_pD3D = Direct3DCreate8(D3D_SDK_VERSION); (in a seperate file, in a function that is never called, i verified this by setting a breakpoint on it) openGL will initialize just fine. I''m totally stumped. I''ve never seen code cause problems without executing before. Hope someone has a suggestion for me.

Maybe making two seperate renderer DLL projects would be good for you. Aside from avoiding the conflict between OpenGL and Direct3D, you can make your engine a lot more flexible. GDNet has an article on doing this somewhere.

quote:Original post by Magmai Kai Holmlor
When you include the DirectX header & lib you statically link to the DirectX dlls, which execute a bunch of initialization code when they are loaded.

To do the job correctly (for several reasons) you need to dynamically load the DirectX dll''s.

Also, if you statically link the Dx dll''s like that, and the end user has OpenGL, but not Dx installed, your program won''t load.

Google for dynamically loading DirectX (I remember reading an article about this sometime ago).

A simpler solution to loading the DirectX dll is putting your Direct3d and Ogl code in a separated dll and loading those guys dynamically. So the Direct3d dll is statically linked to the Direct3d dll and you get no clashing.

Thanks for the info, that makes sense, I''ll give it a go.

So, I stuck d3d and opengl in their own dll files, it works out nicely. I''ve run into an interesting new issue, however. If I try to unload my vid_gl.dll with FreeLibrary() I get an access violation. My vid_d3d.dll unloads quite happily on hte other hand. The interesting thing is, if I skip this call I can actually switch back and forth between d3d and gl without exiting the program, just calling the apropriate unload function for the graphics API and then reloading the new one. I imagine this must be doing something bad though, as it''s generating a new LoadLibrary() call with each switch whithout a corresponding FreeLibrary() call. Could it be something to do with one of gl''s dependant .dll files, or is more likely my code? The only thing really going on in the gl unloading code is releasing the rendering context... should I trash the device context as well and request a new one?

I know the obvious thing to do would be to just force a restart when the video API changes, but since I have it halfway working like this, I feel compelled to try and work the kinks out... I guess my main question is, am I trying to do something impossible?

I''m attempting the switch from a function call in my wndProc when the user presses an f-key. I stepped through the code for the unloading of gl and loading of the new API without any problems, all the way to wehre it exits the wndProc. When I get the access violation, my callstack doesn''t lead anywhere within my program... this is why i''m thinking it''s one of the dependant .dll files causing the problem...

weird...

I use a ''CRenderer'' class in my app to do absolulty all the renderering, the base class is OpenGL, I''ve only recently made a D3D version (and a GL version that does stencil shadows ) by extending the base class and replacing about 15 functions that actually do the api specific stuff, yet I''ve had absolutly no problems what so ever...


and just to try something completly nuts (I was trying to force an error like this, but no luck)

this is a pic of the program creating a D3D window (behind) then a OGL window... as you can see, absolutly no problems, even though both windows are running from the same program (the D3D one isn''t being told to render - hence it''s blank)

image

werid...

Hmm...

Well, I've posted my code here if anyone feels like looking at it: code

Any criticism is welcome

[edited by - j450n on September 5, 2002 8:11:25 AM]