SFML community forums
Help => General => Topic started by: Tenry on November 02, 2010, 08:16:33 pm
-
How should I share games using SFML 'correctly" (on windows)? If I would simply share the Executable with resources many people might not be able to run it as DLLs like "sfml-graphics.dll" is not found. Should I include all the necessary DLLs (also of other libs) with my games? I also noticed that a "libgcc" DLL is also needed on others' computers.
How should I do it?
-
On Windows with mingw, use ldd to check all non-default dlls you link against and provide them with your game.
-
Things you need:
- The .exe (of course)
- All of the necessary DLLs.
- The data (images, sound, etc.)
That's it, no libs required.
Btw, necessary DLLs means libsndfile-1.dll, openal32.dll, and the DLLs associated with the libs you used. If you used sfml-graphics.lib, then include the sfml-graphics.dll, and so on...
-
On Windows with mingw, use ldd to check all non-default dlls you link against and provide them with your game.
I have installed mingw, but I don't find "ldd". Can't find it neither by typing it in the console nor by searching it in mingw's bin folder.
How to I get it for Windows?
And, how should I share applications on Linux?
That's it, no libs required.
With "of other libs" I mean DLLs of other libraries.
EDIT:
I can't find 'ldd' via google and I don't know where to get it on the gcc homepage. I have searched and searched, but I only get a lego designer :(
EDIT2:
Btw, when should I provide (or link against) sfml-...-d-Libs, those with the -d?
-
On Windows, try getting ldd here: http://sourceforge.net/projects/mingwrep/files/altbinutils-pe-bin/1.0/altbinutils-pe-1.0.zip/download
or using Dependency Walker, though I'm not sure if DW is happy with mingw compiled binaries.
On Linux, just tell your users what packages to install and try to provide as few dependencies yourself as possible. If you have to provide custom-compiled dependencies, just provide sfml2-*.so and use
LD_LIBRARY_PATH=path_to_provided-libs ./your_game_binary
if you have to do that.
-
Btw, when should I provide (or link against) sfml-...-d-Libs, those with the -d?
When you're running in debug mode you use -d. When you switch to release you have to link to the normal ones (without any suffix).
-
Btw, when should I provide (or link against) sfml-...-d-Libs, those with the -d?
When you're running in debug mode you use -d. When you switch to release you have to link to the normal ones (without any suffix).
Right, I remember, the -d was for debug. I had a though or "dynamic" or something xD ^^
On Windows, try getting ldd here: http://sourceforge.net/projects/mingwrep/files/altbinutils-pe-bin/1.0/altbinutils-pe-1.0.zip/download
Okay, it works :)
use ldd to check all non-default dlls
Just everything, what is not in "C:\Windows\..." is "non-default"?
-
Right, I remember, the -d was for debug. I had a though or "dynamic" or something xD ^^
That's the normal libraries. -s stands for the static libraries.
And non-default libraries, I think he means any that is not C++ STL.
-
-s stands for the static libraries.
Oh, cool, thanks for that little information, too! :) I think I knew it already once, but I forgot xD
And non-default libraries, I think he means any that is not C++ STL.
Is "KERNEL32.dll" non-default? It is not C++ STL, but a default windows dll.
And if for example libraries of GTK+ is needed, isn't it the best way to say GTK+ runtime must be installed (which will copy GTK+ dlls into the system folder) instead of providing the same libraries with every of my applications? I mean, that could also count for other libs than GTK+ ^^
-
You should provide for a way to install the needed libraries and especially on Windows. For windows, first and most that you will have problem with that the libraries that they might get will be the latest ones and your application might depend on an older version while on Linux this is pretty much fixed for you trough symbolic linking (as long as you link the application directly to the specific version and not the symbolic link when shipping/releasing)
Also it's more convenient if you provide a easy way for the user to install the libraries.
And Kernel32.dll count as default as all applications on Windows link to it.
-
Also it's more convenient if you provide a easy way for the user to install the libraries.
As for that, I would like to write an installer that checks for installed libraries and installs missing libs. But I'm not very sure how to check it.
What if I simply put (gtk+) dlls in the system directory with the installer, and the user later installs gtk+ himself, and that installer thinks gtk+ is not installed yet as for example some registry is not set? Is there any convenient way in general how I could provide that kind of installation, or should I always link to (and execute with the installer) the required libs, even if they are already installed?
-
Easiest thing would to be have the DLL files together with the executable of the application and then your done.
-
Easiest thing would to be have the DLL files together with the executable of the application and then your done.
It's the easiest, but at least, when sharing several games and applications, some DLLs will be there more times as needed and it would need quite much memory. In addition, I could think of a small application needing around 5 MB itself, but all "non-default" DLLs (also including GTK+ for example) may bloat it to 10, 20 or even more MBs.
-
Why use DLLs anyway? Simply link to the static libraries, and done.
EDIT:
And I don't think you have to care about some 5-10 Megs of DLL Files these days....where people usually have 500000 Megs of Diskspace ;)
-
Why use DLLs anyway? Simply link to the static libraries, and done.
I'm not speaking about the SFML libs only. I am thinking of any libraries, for example an alternative for audio playback or something.
And I don't think you have to care about some 5-10 Megs of DLL Files these days....where people usually have 500000 Megs of Diskspace ;)
I'm thinking of several games, mean, if a game would need 5-10 MB of DLLs (which are 'non-default'), it would be a waste of memory if I would have ten or more of those games.
-
But your missing the point... Compiled code doesn't take up much space. What does take up much space are graphics, scripts, and everything else which is not compiled code. Focus on that first.
If you look at the AAA games they all release their games providing their own DLL files in their own folders.
Make this your mantra: "Make it work, then make it right, then make it fast"
What I'm trying to tell you. First focus on finishing the project before worrying anything about optimization. Then do it right, make the project integrate nicely with the environment, like an installer. Then make it fast, which is both optimizing size wise and performance wise.
Though optimizing size on PC's is just wasted work. Especially on Windows as Windows isn't capable of managing several different versions of a DLL file at the same time like Linux can. If you want to keep your mental sanity on Windows then I REALLY REALLY recommend that you just keep the DLL files in the same folder as the executable. Or else you'll probably just destroy the system stability.
-
Also note that if you static link completely you will lose exceptions in C++.
-
Also note that if you static link completely you will lose exceptions in C++.
Oh, really? What compiler are you talking about?
-
Talking about gcc. See here: http://www.trilithium.com/johan/2005/06/static-libstdc/ and here: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
I don't think it is possible to link the very c++ stdlib statically on any other compiler.
-
Also note that if you static link completely you will lose exceptions in C++.
Well you should avoid using exceptions any way in C++.
-
If you want to keep your mental sanity on Windows then I REALLY REALLY recommend that you just keep the DLL files in the same folder as the executable. Or else you'll probably just destroy the system stability.
Okay, I will heed your advice. :)
-
Talking about gcc. See here: http://www.trilithium.com/johan/2005/06/static-libstdc/
Ahem, this says it certainly is possible to use C++ exceptions with static linking, as long as there's only one copy of libgcc. So, if you link everything statically, you will be safe.
I don't think it is possible to link the very c++ stdlib statically on any other compiler.
It is possible to do that on Microsoft's compiler too, for instance.
-
Though optimizing size on PC's is just wasted work. Especially on Windows as Windows isn't capable of managing several different versions of a DLL file at the same time like Linux can. If you want to keep your mental sanity on Windows then I REALLY REALLY recommend that you just keep the DLL files in the same folder as the executable. Or else you'll probably just destroy the system stability.
With .NET there's a new scheme for system-wide libs which is supposed to solve the problems, and if I remember correctly Microsoft's C and C++ runtimes are distributed in this way. (It's stored in a weird directory name, like Winsxs or something).
I have no experience with that, but supposedly Windows is able to manage multiple versions of system-wide libraries now.
Well you should avoid using exceptions any way in C++.
Huh, why?
-
Well you should avoid using exceptions any way in C++.
Huh, why?
If you want the application to crash because something went wrong then assertions is much faster to implement and easier to use. Also you can get them ignored when compiled to release code much easier so they aren't even added to the source for compilation.
If you want to use exceptions actively in your code at runtime then you.... Well I don't even want to know what you was thinking. throwing an exception is like giving up control of the code flow in your application. The exceptions jumps up the stacks until it finds a try, catch statement. What if you for instance allocated anything on the heap memory in one of those functions? Also if we use the exception functionality often it might reduce performance, not sure, never tested just what I've heard.
Haven't you wondered why SFML doesn't implement any exceptions?
I myself actually use exceptions :P But do as I say and not as I do is a very common phrase ^^
-
If you want the application to crash because something went wrong then assertions is much faster to implement and easier to use. Also you can get them ignored when compiled to release code much easier so they aren't even added to the source for compilation.
Well exceptions are not about making the app crash when an error occurs, it's about handling errors or throwing them back to the caller.
What if you for instance allocated anything on the heap memory in one of those functions?
It gets deallocated if you use RAII. I'm not saying it's easy, I personally avoid C++ as I find it overly complicated for most uses. But you can say the same with, say, templates, “it's complicated so I don't want to use them, I'm used to void pointers”, or polymorphism, or operator overloading, ...
Also if we use the exception functionality often it might reduce performance, not sure, never tested just what I've heard.
It's supposed to be possible to avoid exceptions overhead when your code path doesn't raise any exception, but I couldn't find much information when I researched it. Now a quick search shows this: http://stackoverflow.com/questions/43253/measuring-exception-handling-overhead-in-c
Anyway, performance reduction must be measured and you should make a choice based on your specific needs. Many programs spend most of their time waiting for I/O, computing long algorithms or whatever. It often just doesn't make sense to choose a technology just because it might make your application a few microseconds faster.
Strictly speaking polymorphism is slow as well, but it doesn't mean you shouldn't use it. The lack of templates in C also causes some code to be slower than in C++, it doesn't mean all C programs are slower and C should be avoided.
Haven't you wondered why SFML doesn't implement any exceptions?
Laurent answered that. He said that exceptions make writing bindings more difficult, and maybe something else I forgot (I can't find the post). Anyway, even if Laurent hates exceptions, it doesn't mean they shouldn't be used.
-
I don't hate exceptions, I don't use them because:
- I don't need them for this project (I prefer to design SFML directly without exceptional cases)
- It would make bindings so much harder to write
Exceptions are very good if you use proper C++. It makes it possible to handle an error at the point where it can be handled, without polluting your calls and function prototypes with error codes and tons of checks.
Regarding exceptions vs. no-exceptions performances, one thing that people often forget is to compare similar situations. A code without exceptions, but which does the same thing will probably be slower because of the returned error codes the tons of checks (that are executed even when nothing goes wrong). With the addition of bloated code.
But anyway, you can find millions of discussions about exceptions in C++ with Google, we'd better not start a new one here ;)
-
Also if we use the exception functionality often it might reduce performance, not sure, never tested just what I've heard.
Exceptions are designed for exceptional cases. That means you're not dealing with them all the time. When it comes to these errors, the execution speed rarely has priority. Additionally, the point mentioned by Laurent applies.
Strictly speaking polymorphism is slow as well, but it doesn't mean you shouldn't use it.
You can't generalize that. When one instead writes an if-else-cascade, a switch statement or uses function pointers, it's likely to be even slower than a virtual function call.
The problem is, a lot of people hear things like "exceptions are slow", "virtual functions are slow" and so on, but they only hear one side of the truth and never question it. It's a pity people begin to avoid language features because of such misbeliefs.