OpenGL: C and D same code - different results

[Mike Parker]

Wolfgang Draxinger wrote:

> 
> I think the reason, that id's engine also use LoadLibrary is a
> similair: They all contain some VM that should get access to
> OpenGL => LoadLibrary. In Java there is no other option.

I'm not sure why id did this for Q3. Perhaps just because they had 
always done it so? In Q2, true, there was the mini-driver for 3dfx cards 
to consider. That's why they implemented it that way then. But in Q3, 
AFAIK, looking at the source, the QVM doesn't care where the gl funcs 
come from. All GL calls are contained in the rendering modules and not 
exposed elsewhere. The benefit of this is that the function pointers can 
be replaced with debug wrappers.

As for Java, it's not the only option. Only the JNI DLL need be loaded 
dynamically. It can statically link to opengl32.lib itself.


> 
> Well, you will have no problems getting a hardware accelerated
> mode, since all OpenGL implementations can do this. But if you
> request a mode, that the driver can't deal with you'll get
> software emulation. Indexed colour mode is such a mode. Now some
> drivers intercept this and give the application a "mode not
> supported" error instead.

That's why it's up to the programmer to verify the pixel format when it 
is returned to ensure it is hardware accelerated. On Windows, when 
software emulation is being used this can be determined by testing the 
pixel format flags. It can also be seen in the return of 
glGetString(GL_VENDOR).

> 
> Yes, this is true of course, but some drivers use code injection
> as a workaround to intercept program calls that might cause
> buggy behaviour when sharing the contexts. I remember of a nasty
> stencil buffer bug on R300 cards, that was workarounded with
> that method. Unfortunately the engines you mentioned
> circumenvent this, rendering Viewports larger than 1600x1200 on
> a R300 unusable in the first version of the "fixed" drivers.
> Later versions where injecting some code into the engine's
> executable itself to fix it.

This is new information for me. Considering that dynamic loading of 
OpenGL is such a common practice, that's rather bad form on the vendor's 
part. I'll definitely have to look into this.

At any rate, we still haven't solved the OP's problem :)