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 :)

Mike Parker wrote:

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

The solution is simple: Don't use indexed mode. The non D-version
falls into RGB(A) mode (glColor3f working indicates this). And
index mode nowadays is only supported through SW emulation.

Just don't use it.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867

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

Sorry for absence - I have watched thread, but wasn't able to do any actual research till now...

The cause of described behavior turned to be different pixel format selected by ChoosePixelFormat() - it is different for C and D versions.

And it is entirely my fault -  in D version I removed initialization of iPixelType to PFD_TYPE_COLORINDEX. As it is deprecated, and as far as I remember, docs says it is ignored anyway.

What happens later all explained in this thread by you guys - thanks a lot.

Regards.