If I’m developing on windows do i have to use the opengl32 and glu32 .dll’s or can i use nVidias or SGI’s? If nVidias or SGI’s dll’s are updated to opengl 1.2 than can i use 1.2 features in windows, provided i got the hardware(which i do, geforce2)???
Originally posted by eckiller:
If I’m developing on windows do i have to use the opengl32 and glu32 .dll’s or can i use nVidias or SGI’s? If nVidias or SGI’s dll’s are updated to opengl 1.2 than can i use 1.2 features in windows, provided i got the hardware(which i do, geforce2)???
Uhh, huh?
nVidia has an opengl implementation? Thats news to me.
All I know is that you’re either linking to Microsoft’s OpenGL dll’s or SGI’s OpenGL dll’s (provided you’ve installed them).
Now, I would suggest that if you’re developing applications that are to be distributed, you use the Microsoft dll’s, because, well, everybody is going to have them. If you go with SGI’s, you’ll have to distribute and install the SGI OpenGL dll’s with your application.
Now, from what I gather you’re saying, this is what happens…
When you compile your app, you link in the MS opengl32.dll and glu32.dll (lib’s). From there, the OpenGL dll will load and bind at runtime with the hardware drivers, which will also allow you to retrieve hardware specific functions. These extensions are for the most part all of the 1.2 features. This saves you the trouble of distributing a different OpenGL implementation with your software.
But to answer your question, no, you don’t HAVE to link with MS opengl.
Siwko
Well, every board, that has an driver for OpenGL, also has these drivers. The programmer can now decide to use the automatic linkage of opengl32.dll or can do it by hand. This is the only method I know, to differ between multiple accelerators.
Originally posted by Michael Steinberg:
Well, every board, that has an driver for OpenGL, also has these drivers. The programmer can now decide to use the automatic linkage of opengl32.dll or can do it by hand. This is the only method I know, to differ between multiple accelerators.
No… no board should technically come with an OpenGL32.dll file. They will come with DLL files, yes, and THEY are the OpenGL ICD’s and such. In fact, for example, the 3dfx opengl ICD is 3dfxogl.dll or something like, and the 3dlabs opengl ICD is 3DOGLDRV.DLL, but they never come with OpenGL32.DLL (or at least shouldn’t).
What happens is as such: the MS OpenGL32.dll file loads at startup, and depending on the flags you specify for your pixelformat, seeks out a hardware driver. If it finds your board supports hardware, it then links to and maps the appropriate functions to the HARDWARE driver. This is done for you so that you need not worry about compatibility issues. Anything your hardware does not support will still be able to be done in software.
So if I understand you right, is seems as if you do not quite understand that binding process exactly.
Hey Siwko. That is exactly what I meant! Why should the hardware driver have a Opengl32.dll and then link to for example nvogl.dll??? Mmmmmhhhhh. I didn’t mean that any hardware would have its own opengl32.dll.
Siwko seems to be a little confused about the meaning of implementation. Microsoft and SGI offer software implementations of OpenGL. The video card vendors in turn supply hardware accelerated implementations of OpenGL. The GL_VENDOR string indicates who is responsible for the given implementation. So yes, NVIDIA has an OpenGL implementation as does ATI, as does Matrox, as does 3dfx, as did S3. I’m sure I’ve left out other OpenGL vendors as well.
[This message has been edited by DFrey (edited 11-02-2000).]
Microsoft ships opengl32.dll. We have no power over this DLL, and in fact, if we were to install on top of it, we’d probably be refused WHQL certification. The old “minidrivers” that actually had a filename of opengl32.dll were a bad idea from the start. When an app uses OpenGL, it should link statically to opengl32.lib, which is an import library for opengl32.dll; when the app starts, it loads opengl32.dll and links to the entry points.
opengl32.dll includes Microsoft’s SW OpenGL. If no driver is installed, you get that.
The ICD mechanism allows us to implement the entire OpenGL API. We started with the SGI code, which provides a SW implementation, but of course we take our own liberties in deciding where to go with the code from there. We ship our own DLL, nvopengl.dll or nvoglnt.dll, which opengl32.dll loads up.
Our driver includes a full SW implementation of OGL in addition to the accelerated stuff.
SGI shipped their own SW implementation on Windows a while back, under the filename of opengl.dll. This was faster at certain things than the MS SW renderer, but today it is totally obsolete. Don’t use the SGI SW implementation for Windows any more unless you have a really good reason to…
opengl32.dll does not support OpenGL 1.2. Therefore, OpenGL 1.2 drivers on Windows use the extension mechanism to expose the new entry points. You can call wglGetProcAddress, just like you do with any other extension.
- Matt
Oh, well, mccraighead.
Uhmmmm, I wonder if it has benefits linking directly to the device’s driver. You could choose the accelerator then, if one has multiple installed, no? Any other things? thnx
Nope, you should never do that… opengl32.dll hooks into some GDI things, and if you bypass it, there may be problems.
- Matt
Well, you might understand if I tell you that it’s damn cool that I shouldn’t do it…
But, what does Carmack? After all of the time, I still don’t know if he’s a genious or average… But, I think he’s got something like an opengl wrapper in quake2
Quake 2 does not use an OpenGL wrapper, it just loads the OpenGL ICD or 3dfx MCD dynamically. It is not staticly linked to OpenGL, that’s all.
[This message has been edited by DFrey (edited 11-03-2000).]
Oh, yeah, might be that I don’t know the correct meaning of the word “opengl wrapper”. If it dynamically links to them, it has to load the library and to get all the function pointers, no? Or how to do that?
In Windows you can dynamically load the library (be it an ICD or MCD) with LoadLibrary. Then using GetProcAddress you can get the addresses of the functions. And finally use wglGetProcAddress to get the extension addresses. How it is done in other OS’s I do not know the details of.
Yeah, that’s what I meant. It’s a bunch of work… But, mccraighead meant one shouldn’t do that. Never heard q2 has had problems with that though…
What Quake 3 does is it loads opengl32.dll dynamically. That’s OK. The reason it does this is because Carmack had to support minidrivers, and to support those, he had to be able to load up, for example, 3dfxgl.dll dynamically.
You should not load nvopengl.dll or nvoglnt.dll dynamically from your own app, under any conditions whatsoever. No app I know of does this.
- Matt
I’m going to understand what you meant. Still have problems with english, so please be warned…
Uhmmm, as far as I know, 3dfx has also an ICD for their actual generation cards. So I think it might be possible to forget mini clients sooooon. Hope so.
Oh, by the way. To the 3d textures. Wouldn’t it be possible that you built cards with TeraBytes of memory, so one can load a full map voxel-like, and move “through” the texture? Oh yeah.
There is no appreciable difference between
statically referencing a shared library, and
manually loading it at run-time, except you
don’t fail to load if the library is not
installed in the manual-load case. This may
be reason enough to load the OpenGL library
yourself instead of statically linking. Also,
if you’re also supporting D3D (or, ugh,
Glide) you’ll save some memory by not loading
a library you won’t use.
The opengl32.dll implements the OpenGL API.
It may, optionally (but hopefully) in turn
manually load some ICD and hand off certain
functionality to that ICD for accelleration.
However, the API of the ICD may not be the
same as the full OpenGL API, and the OpenGL
DLL may do some things behind the scenes that
is the same for all implementations, and thus
the ICD does NOT do these things. Thus,
loading the ICD directly is a bad idea.
Oh, and as far as “other OS-es” goes, under
Linux, you open a shared library with
dlopen() and find symbols with dlsym(). Under
BeOS, you open a shared library with
load_add_on() and find symbols either with
get_image_symbol() or get_nth_image_symbol().
Again, doing so on an ICD (or the equivalent)
under each OS is a bad idea, because the API
to the ICD is probably NOT exactly the OpenGL
API. That’s what the OpenGL library on each
platform is for.
Sooo, if I was to compile under the regular MS OpenGL32.dll, w/ no hw support, but then bring just the exe to a 'puter w/ hw support, would the program link w/ the hardware?
If your program implicitly or explicitly links with OpenGL32.dll, then yes, it would use hardware acceleration if available. That’s the good thing about the ICD mechanism. On the otherhand if the computer used an MCD, then no, your program would not use hardware acceleration unless your program explicitly loaded the MCD. That’s the bad thing about MCD’s.
I don’t believe that’s true of MCDs. Minidrivers and MCDs (mini-client drivers) are very different.
Minidrivers (aka MiniGL drivers, aka QuakeGL drivers) implement only subsets of OpenGL, in particular, the subset used by Quake 1 or Quake 2. Fortunately, minidrivers are basically dead.
MCDs are an alternative OpenGL driver model available under Windows NT. MCDs were promising at first because it was less work to implement a MCD than an ICD, but no one uses them any more for two reasons. First, MCDs don’t work on Win9x, and second, they have performance costs associated with them as opposed to allowing us driver folks to just implement the API directly.
- Matt