On debian/ubuntu, you should replace `sudo make install` by `sudo checkinstall` so that the package is tracked by the packet manager and you don't end up with random files spread around your filesystem 
Thank you for that! I'm wondering now if this can be used to speed up the TravisCI tests. A lot of the time is spent on the SDL2 compiling. Though the .deb packages would need to be hosted somewhere and downloaded by the test VM to install from. Not sure how appropriate it is to put them in the repo itself.
... enough, at least, to google them.
That's all that really matters
But yeah, that's the big glaring thing in the Filesystem code that's been bugging me for awhile.
I've been finding myself hesitant to make changes to your code. I think this will be a breaking change, in terms of source code interface compatibility. It's got me wondering about intent, and what your design goals are. It seems like PhysFS handles the default common case well. Could just delegate stuff to PhysFS without much change in semantics or complicated wrapping. Not sure if you're trying to build any restrictions or abstractions on top of it.
I think the
PHYSFS_setSaneConfig does exactly what you want. It sets a read path where the executable is installed, allowing you to load game assets, and a read/write path in an appropriate subdirectory of the user's home directory, for things like saved games, or user specific config.
The one difference I think I see, is you seem to be adding subpaths to where the executable is installed, whereas the default is the parent folder containing the executable. I think perhaps the default config makes a lot of sense, and path to assets can be adjusted to include the subfolder.
Oh, and the
setSaneConfig method can also search the read folder for archives with a given extension, and automatically add them. That can save you from manually specifying archives to load, and also eliminate error messages from adding archives you haven't created yet.
If a game doesn't want the default config, maybe the initialization of PHYSFS and the config of folders should be split into separate methods. Or maybe the default can run, but can be cleared or undone later. Or maybe you just want to disallow that, and say the default config should be good enough for any game likely to be created using NAS2D. Which might actually be very true. I'm thinking just stick with what
setSaneConfig provides and not worry about it.
I was thinking the
Filesystem::init could be something like this:
void Filesystem::init(const std::string& argv_0, const std::string& organizationName, const std::string& appName, const std::string& archiveExt)
{
if (FILESYSTEM_INITIALIZED) { throw filesystem_already_initialized(); }
std::cout << "Initializing Filesystem... ";
if (PHYSFS_init(argv_0.c_str()) == 0)
{
throw filesystem_backend_init_failure(PHYSFS_getLastError());
}
if (PHYSFS_setSaneConfig(organizationName, appName, archiveExt, false, false) == 0)
{
std::cout << std::endl << PHYSFS_getLastError() << std::endl;
}
FILESYSTEM_INITIALIZED = true;
std::cout << "done." << std::endl;
}
Was also thinking some of those messages might be more appropriate for
cerr rather than
cout. Not that it much matters for a graphical application.
