gl 1.4 on windows

OpenGL OpenGL: Basic Coding
1

Is it safe to use opengl 1.2 or 1.3 or 1.4 base functionality and assume that anyone on windows will have drivers available to them to support them? If i write a program do I have to use 1.1 as the base? And can someone explain why there are 1.4 headers for windows, but I would still have to use extensions to access 1.4 functions, why are the headers even provided if this is the case? Just for the function prototypes? I am so lost, why can’t I just use nvidia’s 1.4 headers and use multitexturing without setting up the function pointers first?

And why is there an opengl32.lib and opengl32.dll, why is the lib there?

[This message has been edited by sonsy (edited 11-09-2002).]

2

Is it safe to use opengl 1.2 or 1.3 or 1.4 base functionality and assume that anyone on windows will have drivers available to them to support them?

That depends on who will use your application. You should never assume anything, but if you’re making a game/demo, it would be pretty safe to assume the user will have at least 1.2. But as I said, never assume anything. Check the version string.

And can someone explain why there are 1.4 headers for windows, but I would still have to use extensions to access 1.4 functions, why are the headers even provided if this is the case? Just for the function prototypes?

The heareds are provided to allow you to use OpenGL 1.4. Without the header, you will probably have no idea what the function prototypes look like, what values the enumerators have etc. What would you prefer, a header with everything predefined, or would you rather look around in the extension/1.2+ specification to hunt prototypes and enum values yourself?

I am so lost, why can’t I just use nvidia’s 1.4 headers and use multitexturing without setting up the function pointers first?

All functions in OpenGL has to be loaded at runtime, cause they are all dynamically linked. Either you do it yourself, as in the case with extensions, or you let an import library do it. An import library is a connection between your application and a DLL. The import library will automatically load every function pointer you need so you don’t have to do it yourself. However, this requires that the import library actually knows about the function being imported. Since Microsoft haven’t provided any version above 1.1, the import library doesn’t know about any function in OpenGL 1.1 (or any extension), you must load them yourself.

And why is there an opengl32.lib and opengl32.dll, why is the lib there?

opengl32.lib is the import library I mentioned above. If you don’t link to this one when you compile, you have to load ALL functions yourself, not only the extension and 1.2+ functions.

3

Thanks for the great explanation.
But since opengl32.lib is the limport library why doesn’t nvidia or somebody provide an up to date import library thats aware of newer opengl versions.

And the functions are defined in opengl32.dll right, so that must be distributed as a part of the nvidia gforce drivers right?

[This message has been edited by sonsy (edited 11-10-2002).]

4

But since opengl32.lib is the limport library why doesn’t nvidia or somebody provide an up to date import library thats aware of newer opengl versions.

It’s Microsoft responsibility to provide the interface for OpenGL on Windows, since it’s their operating system. I’m not sure about this, but I believe there are some legal barriers stopping other from making another interface for Windows. But don’t take my word for it.

And the functions are defined in opengl32.dll right, so that must be distributed as a part of the nvidia gforce drivers right?

No. opengl32.dll is the OpenGL interface for Windows. opengl32.dll not only includes an implementation of OpenGL, but it also has the ability to load external drivers. When you install a hardware driver, it registers itself as a possible “substitute” for the standard implementation. opengl32.dll will, if possible, automatically redirect all OpenGL-calls to the driver instead of handling them itself. This is why you don’t have to do anything special to get hardware accelerated rendering. opengl32.dll does that automatically. It can be easily demonstrated by setting up a standard OpenGL program and pick a pixel format suitable for your hardware. You will then, hopefully, have a nice hardware accelerate dapplication. Then, by just changing a few numbers in the pixel format, choosing a pixel format the hardware can’t use, you will suddenly get software rendering by the standard renderer provided by Microsoft. You don’t even have to recompile the program between. The hardware/software decision is taken at runtime.

5

Thanks for the reply, this explains much.

6

You can try to generate your import library out of the opengl32.dll. You’ll need implib or something similar to do that. It’s possible, that your import library is older than your DLL. In that case, the DLL has the extensions exported (importable), but the import library has no references to them. If you use Borland, you just use implib to generate an import library. For Microsoft I don’t know.

7

No, mm_freak, opengl32.dll is version 1.1. It is provided by MS (just check it’s properties from Windows Explorer). It can’t give you pointers to functions from later GL versions (except by calling wglGetProcAddress). The accellerated GL functions provided by your hardware vendor reside in a different DLL (e.g., nVidia’s nvopengl.dll). You don’t link to this directly. It is not likely that anyone is using an import library for OpenGL 1.0, and if they were, it would be easier to get an updated version from the compiler’s website.

Edit: I’ve basically just restated what Bob said. If you re-read his posts, you’ll understand why the import library isn’t the problem.

[This message has been edited by Aaron (edited 11-10-2002).]

8

That’s possible, but still updating the import libraries is a good way to ensure compatibility between import library and linker and I’ve for example had an older import library (Borland), after updating it, it had all the stuff missed before.