How do major engines hide all their dlls?
I'm sure they use them, but I never see any. I know the source engine is supposed to be pretty modular (read: uses dlls) but I cant find em!
Is there a way to hide/compact my dlls into some kind of thing where I can use them as needed but don't need a crapload of dlls cluttering yup the game folder?
Thanks guys.
Much Derp About Dlls
You could use static code libraries instead of dynamic code libraries ([font="'Courier New"]lib[/font] instead of [font="'Courier New"]dll[/font]) -- this kind of library gets compiled (linked) directly into the [font="'Courier New"]exe[/font] file.
Author
I was thinking that, but then I will have some useless code in the exe (which is fine?) since the dx9 renderer is seperate from the dx8 renderer is sperate from the opengl renderer and only one needs to be loaded at once for example.
EDIT:
It's definately possible.
http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx
http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx
But it's more a matter of best practice at this point.
It would also be nice if I didn't have to change any code and could still call LoadLibrary (dllName) even if it's not really in the dir. (this might be asking too much)
EDIT:
It's definately possible.
http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx
http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx
But it's more a matter of best practice at this point.
It would also be nice if I didn't have to change any code and could still call LoadLibrary (dllName) even if it's not really in the dir. (this might be asking too much)
Why do you assume everyone uses DLLs for modularity?
Maybe more to the point: why do you assume DLLs are synonymous with modularity?
Maybe more to the point: why do you assume DLLs are synonymous with modularity?
You'll find almost all .dll files stored in one subfolder or another. Usually folders like "System" and "Core" contain these things.There is no reason they need to be in the same folder after all. Static linking is also there, if it's warranted.
Author
Why do you assume everyone uses DLLs for modularity?
Maybe more to the point: why do you assume DLLs are synonymous with modularity?
I think I remember a keynote where valve said they are using dlls for all their components now.
So that's where I got that from.
It may not be synonymous completely, but it's pretty nice being able to plug in a system without having a larger exe than needed storing many systems when few will be used.
Author
You'll find almost all .dll files stored in one subfolder or another. Usually folders like "System" and "Core" contain these things.There is no reason they need to be in the same folder after all. Static linking is also there, if it's warranted.
Yeah, I guess I'll just put them into some dir out of the way, probably massively easier than anything else I could do.
There are two basic timeframes at which modularity comes into play: code time, and run time. At code time, modularity is all about how you organize the program itself; whether it gets smashed into a single .EXE at the end is more or less irrelevant. Run time modularity is where dynamic linking (and DLLs on Windows) comes into play, and that's a different beast.
I think you'll find that much software accomplishes code-time modularity without needing any of the complexity or overhead of run-time modularity. This is certainly true of most games (and other software) I've worked on.
Probably what you're witnessing is that most people need code-time modularity but not run-time, and therefore don't bother with DLLs at all. Those who do often place them in subdirectories as has been mentioned, or if the DLLs are shared by multiple programs, might place them somewhere else entirely, such as AppData or a special path under Program Files. Older programs (which, it must be noted, are misbehaving by doing this) might even use System32.
I think you'll find that much software accomplishes code-time modularity without needing any of the complexity or overhead of run-time modularity. This is certainly true of most games (and other software) I've worked on.
Probably what you're witnessing is that most people need code-time modularity but not run-time, and therefore don't bother with DLLs at all. Those who do often place them in subdirectories as has been mentioned, or if the DLLs are shared by multiple programs, might place them somewhere else entirely, such as AppData or a special path under Program Files. Older programs (which, it must be noted, are misbehaving by doing this) might even use System32.
Author
Yeah, turns out that source engine just puts its dlls into a folder derp. (I downloaded hl2 from my steam account and checked)
I thought that having a large exe was generally bad because you have more 'cache misses' or something when you get instructions.
Am I wrong here?
That smaller exes are generally faster?
Does instruction caching work exactly like data caching? (I imagine it would but...)
EDIT:
You don't strictly NEED 'run time modularity' for anything afaik. But people still use it for whatever reason.
I'm doing it simply because, so, maybe that's it.
I thought that having a large exe was generally bad because you have more 'cache misses' or something when you get instructions.
Am I wrong here?
That smaller exes are generally faster?
Does instruction caching work exactly like data caching? (I imagine it would but...)
EDIT:
You don't strictly NEED 'run time modularity' for anything afaik. But people still use it for whatever reason.
I'm doing it simply because, so, maybe that's it.
Many games use dlls for modularity, and they are usually stored in subfolders.
Search for "Bin" folder or "Bin32" or "Bin64"
Search for "Bin" folder or "Bin32" or "Bin64"
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
