OpenGL: C and D same code - different results

[Wolfgang Draxinger]

Mike Parker wrote:

> 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.

I think, the main reason for this is, that a few years ago there
were different versions of opengl32.dll (the SGI version, the
Win9x version and the WinNT - though Win9x and WinNT DLLs are
almost identical, only difference is a value in the version
resource entry). Not linking with LoadLibrary could have caused
some trouble since some compilers were creating the link based
on the ordinal number which were not identical to the library
installed on the developer's system.

> 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.

My engine does this, too. But for another reason: Instead of PE
or ELF binaries the modeuls are contained in a custom, platform
independent format. Despite OS specific code those modules can
be loaded and run on any OS, as long it is running on the
architecture, the code was compiled for. So the core game code
must be compiled only once for every architecture. And since
there has only two architectures remained on which games are
played (x86 and x86_64) this means I have to compile only twice
for most of the code.

Of course such a custom module format the normal executable
binary loader is ignorant of, so there is a a small wrapper,
bootstrapping it. All system libraries then must of course be
loaded through dlopen/LoadLibrary.

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.

> You can test this with DerelictGL. I've 
> used it several times in testing and always get a
> hardware-accelerated 32-bit color mode.

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.

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

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.

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