I think I have seen people do that, come to think of it. Would you recommend following suit and including it in there somewhere? Also, what function does it serve in this case?
If you are actually shipping a game, you might as well include it in your release package.
What function it serves is not 100% clear to me, that's why I will look into avoiding the dependency. My best guess is that the dependency is caused by some Visual C++ default setting. Instead of statically linking certain functionality, it is linked dynamically. The result is a smaller dll file which, however, depends on those Visual C++ runtimes.
For Linux, would you recommend also including those other libraries? My main concern here is, I don't want there to be an error that cannot be fixed, say if the application cannot start, it cannot report an error, either, but they don't know why - OR, Linux users are used to it and just add it at download and/or in a readme.
"Those other libraries" are most likely already present on most (updated) Linux clients. I only encountered problems with libGLEW (of which there are many different versions around) and libjpeg (because distributions like Fedora only know libjpeg-turbo) (note that in the current test release, they are not included because of a little mistake I made).
In case the other dependencies are not available, users will have to download them. It's not possible for you to include them I fear, most distributions only allow proper installation of things via their package manager. Your best guess is to include a list of dependencies which users need to make sure they have. The next JSFML test release will include those dependencies in the readme file.
Users do still get an error message, though. It would look similar to yours, and that is reportable. Besides, errors can also be caught on a Java level. If you wish to do that, the first thing you should do before using any JSFML objects in your application is this:
try {
SFMLNative.loadNativeLibraries();
} catch(JSFMLError err) {
//report the error into a log file, display a message dialog, whatever
}
That method is automatically executed anytime a "native" object is created. If you do it manually, you have the ability to catch any errors that occur.
Read about that, yes. Although... I had thought double clicking jars (on windows, not sure about mac), does not do it - opens it as text. Setting default program, perhaps. Anyway, is there any good cross platform way to detect the java installation ( jre) directory? I would go java -jar somejar.jar, but that only works with java on the path.
Double-clicking on JARs is a windows feature IIRC. On Macs, I have no idea, but most Linux systems will detect the JAR file as a zip and open it with an archive editor by default.
From waht I know, wherever Java is installed, "java" is on the classpath, so doing "java -jar game.jar" should be safe anywhere.
