Suggestion regarding #pragma comment libs

[barebones]

Hello,
currently the Irrlicht sources have embedded #pragma lib comments. This (I believe) makes the Irrlicht.dll link with static libs (which typically would contain a LoadLibrary call, plus calls to some DLL).

The end result is that the final target machine needs to be prepared for *all* of DX8, DX9 and OpenGL, even if the intention is to use only one of them, or the ones available at the target. Thus I guess developers just deliver the DX8 and DX9 DLLs to their own application's directory.

In a perfect world (if one may dream), a more flexible approach would be to manually make LoadLibrary calls only for the driver types actually used on createDevice. This, I imagine, would mean to recompile yourself the libs (which fetch routine pointers with GetProcAddress and wrap the dynamic calls with static ones). I seem to remember there are IDE tools that produce source code for those stub libraries, so maybe is not such a crazy idea.

My 0.02 cents.

[JP]

0.02 dollars

I've not got much else to say, just had to correct you there hehe

I'm not exactly sure what you mean but you can use irrlicht without needing any DX support at all as this is the way in which the windows libraries are provided and the engine has to be recompiled with DX for the DX drivers to work.

[barebones]

What I mean is that it would be nice if it is the player who decides to use DX8, DX9 or OpenGL, depending on what works on her machine. Currently you have to, either deliver a game that only works on one platform, or deliver a game with installation requirements for all platforms at once with no flexibility.

[Virion]

player who decides to use DX8, DX9 or OpenGL

You CAN. Just put those drivers into an option for the players to choose for. Then create the device based on the option they've chosen.

IrrlichtDevice *device = createDevice( HERE , dimension2d<s32>(512, 384), 16, false, false, false, 0);

EDT_DIRECT3D8, EDT_DIRECT3D9, or EDT_OPENGL --> CHOOSE ONE?

[FuzzYspo0N]

yea its not like EVERY SINGLE example with the sdk does this?

[Zeuss]

What I think barebones is saying is that because Irrlicht statically links to DX8, DX9 and OpenGL even if you don't call createDevice it will still look for those DLL's when the Irrlicht.dll is loaded.

In his perfect world, the dlls (for dx9, dx8 and opengl) will only get loaded when createDevice is called.

Yes you can give the user the choice like in every example, but that is not what barebones is saying. He is saying even with that choice the dll's for DX8, DX9 and OpenGL still have to be their for Irrlicht to even run.

[MasterGod]

Interesting.. And quite important.
So what can we do about it?

[Halifax]

Irrlicht doesn't statically link to DX9...there is a clear LoadLibrary() call to retrieve DX9 device creation in the Irrlicht device. This is the gray area of .lib (and .a) files. The .lib file just provides the compiler with knowledge of what functions the DLL contains, you aren't statically linking to the lib. If you didn't have the .lib with the DLL, then you would have to load a heck of a lot, and it would just be a waste of your time. So it just makes it easier, you aren't statically linking.

[barebones]

Oh, it was my understanding (I might be wrong) that the lib that accompanies any dll had the following form:
a) Initialization code (called just once), looking like:

Code: Select all

LoadLibrary ("blah.dll");
p_routine1 = GetProcAddress (...);
p_routine2 = GetProcAddress (...);
p_routine3 = GetProcAddress (...);

b) A set or routine wrappers, one per routine in the dll, looking like:

Code: Select all

routine1 (...) {
    asm { jmp p_routine1 }
}
routine2 (...) {
    asm { jmp p_routine2 }
}
routine3 (...) {
    asm { jmp p_routine3 }
}

You link statically to this 'proxy' lib (not to DX itself), and when you call your DX functions, you are actually calling one of these small stubs. Of course, this means the dll was initially loaded into your addressing space, whether you use it or not.

Also, I believe a linker switch (at least for MS LINK, a base tool called by the Visual Studio C++ IDE) had an option /DELAYLOAD, which (if you were to compile the DX dll yourself), would alter the contents of the lib's proxy code, calling LoadLibrary only if you really use one of the dll's functions.