OpenGL: C and D same code - different results

[Mike Parker]

Wolfgang Draxinger wrote:
> Wolfgang Draxinger wrote:
> 
>> The OpenGL bindings for D, that I've seen so far circumvent the
>> normally used linkage to the DLL, which is normally happening
>> by specifying the DLL in the Executable header. Instead the D
>> bindings use LoadLibrary and GetProcAddress. Maybe this makes
>> the D version to actually get the index mode.
> 
> Got the explanation for that one, too: Modern drivers intercept
> the linkage on executable load to insert some of their own juice
> into the code. Mainly to make usage of features like
> antialiasing and PBuffers more efficient. Naturally getting the
> functions pointers via LoadLibrary and GetProcAddress will
> circumvent this and give you only the vanially opengl32.dll
> which will happyly serve you a software emulated index colour
> mode.


While it's true that when statically linking to the import library on 
Windows will do some jiggity foo to get the current driver 
implementation loaded, going through LoadLibrary does not affect this. 
Every game out there based on the Quake 2 & 3 engines loads dynamically. 
All of the games using the GarageGame's Torque Game Engine do it. So do 
the Java games out there using LWJGL (like Tribal Trouble, Bang! Howdy, 
and the games from PuppyGames.net). Likely several other games I'm not 
aware of do the same. You can test this with DerelictGL. I've used it 
several times in testing and always get a hardware-accelerated 32-bit 
color mode.

Antialiasing is set up during context creation via wgl extensions on 
Windows. pbuffers are through extensions also.

> 
> Extension loading should be done by wglGetProcAddress or
> glxGetProcAddress _after_ a valid OpenGL context has been
> aquired anyway. Sooner or later I will fork/extend GLEW to
> GLEW'D (aka a GLEW that creates D code instead of C).

Yes, this is an issue on Windows. If the context is not created, you 
cannot properly load extensions. When you change contexts, there is no 
guarantee that previously loaded extensions will be valid. That's why 
extension loading is separated from DLL loading in DerelictGL. It also 
has a mechanism to reload extensions when you want to switch contexts.

So I thing the OP's problem lies elsewhere. Besides, AFAIK, DerelictGL 
is the only binding that does go through LoadLibrary. The other OpenGL 
bindings I've seen all link statically to the import library.