PDA

View Full Version : dynamically load opengl



tomhsu
12-30-2002, 05:00 PM
Hi,

In one of my pet projects, I am trying to dynamically load OpenGL (from my Geforce2, nvoglnt.dll)instead of linking it to opengl32.lib. The process of LoadLibrary
works fine but I seem to have trouble getting the function pointers from GetProcAddress. I am sure my program works correctly because when I subsitude
nvoglnt.dll to opengl32.dll or opengl.dll, it worked. I also made sure that this is not an ascii/unicode problem by trying both.

so I examine the error return by windows when
GetProcAddress failed on me, and the erro code told me that the specified function can not be found. I am starting to suspect that OpenGL function names have been changed by some Macro when NVidia made their ICD.

can anyone give me some advise ? thanks !

Mazy
12-31-2002, 06:14 AM
I dont know how the ICD does it, but you shouldnt load the vendor specific dll anyway, just load the functions from opengl32.dll and let the ICD mechanism do its work.

SirKnight
12-31-2002, 06:51 AM
Why would you want to load nvoglnt.dll yourself? There is no reason to do so. The best and most logical way is just to link in the opengl32.lib file in your project like normal.

-SirKnight

bashbaug
12-31-2002, 08:29 AM
Sounds like an interesting programming project.

You'll need to learn more about the ICD mechanism to figure out exactly how the OpenGL DLL interacts with the vendor's ICD DLL. As you've discovered, a vendor's DLL doesn't have to export all of the OpenGL functions...

-- Ben

Coriolis
12-31-2002, 12:12 PM
SirKnight:

Statically linking to opengl32.dll through opengl32.lib in your project is not the best and most logical way for all situations. This is usually adequate, but dynamically linking has a couple of big advantages:
1) You don't have to load opengl for a dedicated server
2) You can easily swap the function pointers around to do selective logging of OpenGL calls, including what particular information is important to you. External loggers can't really do this.

For these two reasons alone, I never statically link to opengl32.lib.

dorbie
01-01-2003, 01:31 AM
If memory serves the gl Quake implementation did this, and it was open sourced recently. It dynamically loaded OpenGL and bound functions explicitly to it's own wrappers. This allowed it to switch libraries at runtime, which was very handy in the days of minigl drivers for 3Dfx pass through cards for example. You may want to check the open source quake software available online.

Eric
01-02-2003, 08:38 PM
Coriolis,

What SirKnight says is that there is no use in linking dynamically to "nvoglnt.dll". He didn't argue the usefulness of linking dynamically to "opengl32.dll".

I have written some piece of code (never finished I think) that links dynamically to "opengl32.dll". I actually used it to select which GL implementation to use (i.e. the Windows one or the SGI one "opengl.dll"). It could also be used with Mesa.

I have never found any good reason for linking directly to "nvoglnt.dll" and if I remember correctly, driver writers (Matt?) advise against doing so.

Regards.

Eric

SirKnight
01-02-2003, 09:06 PM
Yes Eric is correct, that's what I meant.

But, the way things are now I really don't see the big reason to do this now. The miniGL stuff like dorbie mentioned is gone. No one supports that, or at least shouldn't. I suppose that if you need your program to be able to switch opengl implementations from windows to sgi to whatever it would make sence I guess. Again I don't know why you would need this. Why do that when there are perfectly good nvidia and ati cards out there. http://www.opengl.org/discussion_boards/ubb/wink.gif

Also I don't see what's wrong with linking to the lib. If you need some vendor's features just use their extensions. SGI didn't make OpenGL's extension mechanism for nothing. As for a dedicated server...if that doesn't need OpenGL what's the problem? The dedicated server code should be its own program, not embedded into the client code which needs OpenGL. If your dedicated server code is IN the same project as the client code, just make a new project, copy and paste and do a few things to make it run. The Selective logging thing...well I really don't know exactly what that means. I have never needed to log my OpenGL calls so I guess it's not important to me.

-SirKnight

Coriolis
01-02-2003, 10:21 PM
Eric-
Neither SirKnight nor I said that directly linking to nvoglnt.dll is a good idea. I was replying only to the part of his post where he said "The best and most logical way is just to link in the opengl32.lib file in your project", because I disagree about it being the best / most logical way in some circumstances.

SirKnight-
I didn't say there was anything wrong with directly linking to the lib. It usually makes sense to do so. There are also other, much more compelling reasons for making the dedicated server in a game a separate executable. However, it is also frequently nice to have all your code in one place. If you come to the conclusion for a project that it makes more sense for the dedicated server to just be a normal instance of the program minus the client and renderer, then it is a very minor nicety that you don't have to load opengl. This point is admittedly weak, and saving a few megs of memory for a dedicated server would not be compelling enough to force me to go through the effort of manually linking to opengl.

The second point is the one that sells me on using manually linking. Since it appears I didn't explain it very well, let me try again. What I meant is that you can easily make it so that your renderer logs all OpenGL calls, or just the ones you care about. You can do it so that the renderer does this for a single frame, part of a frame, or for the life of the program. Since you control the log, you can insert additional information into the log, and you may also be able to replace pointer addresses with meaningful text strings. Then, when your program has a visual error while running on somebody else's machine who doesn't have or isn't running a debugger, you can activate the logging mechanism to get a bunch of useful information about what the renderer was doing. This has proved quite useful to me several times in my current project.

This type of logging is admittedly completely useless if you don't have multiple people working on the project, or if everybody has the same hardware, or if you only use extensions that are implemented by all hardware you plan to support. If these conditions don't hold, there will come a time when you have the option of examining the faulty logfile or replacing the hardware in your machine so you can maybe reproduce the bug.

I understand there are third party loggers, but there is no way they could be as versatile as a logger built into your renderer, and you'd have to install them on everybody's machine just in case you ever needed a log from them.

I find this a compelling argument for using manual linking in my projects. Your projects are probably different, so you may come to a different conclusion about the most useful way of linking to OpenGL for you. I expect that for most of the projects worked on by people at this board that statically linking usually makes the most sense. But that is not quite the same as always making the most sense for everybody http://www.opengl.org/discussion_boards/ubb/wink.gif