Hi everyone,
I start this topic to have your point of view about one subject who is DLL and STATIC linking.
The subject is about an engine compilation who could have multiple renderer ( OGL,D3D11,... ).
Do you think it's a good design to have differents .lib by renderer or have DLL module who set the renderer ?
The STATIC option output multiple exe by renderer says : Game-OGL.exe / Game-D3D11.exe ....
What is your point of view about this one ?
Thanks
I personally use the static method, because, you probably don't need to have a Game-OGL and a Game-D3D11 in the one installation -- When you install the game on Win7, you install Game-D3D11, and when you install the game on MacOS, you install Game-OGL, so I just call them both Game (Windows and Mac version)...
Making separate executables for DX11/9 seems to be the standard practice for most games I've seen.
STALKER series have one main exe and a .dll for each renderer: DX8 (in ShoC), DX9, DX10 and DX11. I think Crysis series does that too.
Assassin's Creed has different exes for the different renders. Far Cry 3 too.
So, both approaches have been taken by big studios.
Games usually ship in DX9 and DX11 executables.
Don't you get to skip some boilerplate code aswell for dll-loading when using .lib? Not critical but nice nonetheless.
A DLL is slightly more flexible because it can be loaded dynamically (e.g. try OpenGL or DX9 on Windows as a fallback, according to user options), replaced (e.g. with a logging/debug proxy that calls the real renderer during development), etc.
Like LorenzoGatti said, one of the good things about DLLs is that they can be replaced.
Imagine you have your game, and you make changes to the render only, either to add new features, or fix bugs, etc. If you statically link the renderer to your project, you'd have to replace the executable, but if you used DLLs, then you could replace only the renderer DLL, maintaining your original executable intact.
This also helps to keep the executable size smaller.
They both have pros and cons, pretty much the whole point of dll's is that they are -dynamic- as in you can swap them out without replacing the executable if code changes in a helper library. Depending on code design that can be a big help or a big annoyance, depends on your needs.
I will say dll hell is a bit of a problem with some companies, it is -not- good design to make a thousand dll's for everything and link them all and pretend that is easily modifiable code. That's just bloat and leaves a mess. Using them responsibily is good though, just like using your own code in seperate libs responsibly is.
