Separate writable from read-only data paths

[Lgt2x]

Currently, the Base_directory path is used for both writable data, such as saves and demo files. By default, this base directory is the directory from which the game is launched. It can be overwritten using the -setdir argument.

This is a problem, because the static game data directory may not be writable be the user (explained in depth in #471 (comment)) . Right now, the usage file provided with the game binaries recommends copying all required game data to the same directory as the executable, to make sure nothing is written in the original game directory, and to hope for the game to find required game data (which is not always the case, see #532 ).

A possible solution could be to use SDL_GetPrefPath for writable game data, and user-defined locations to find read-only data (see tentative implementation in #471.

[Jayman2000]

A possible solution could be to use SDL_GetPrefPath for writable game data, and user-defined locations to find read-only data (see tentative implementation in #471.

Eh, I wouldn’t really say that #471 is a tentative implementation of that idea. The goal of #471 is to allows users to store game assets in multiple different directories. If you run the code in #471, it still defaults to looking for game data in a single directory (the current working directory). The idea was to do all of the hard behind the scenes work in #471 and then create other PRs that improve the user experience.

[Lgt2x]

A possible solution could be to use SDL_GetPrefPath for writable game data, and user-defined locations to find read-only data (see tentative implementation in #471.

Eh, I wouldn’t really say that #471 is a tentative implementation of that idea. The goal of #471 is to allows users to store game assets in multiple different directories. If you run the code in #471, it still defaults to looking for game data in a single directory (the current working directory). The idea was to do all of the hard behind the scenes work in #471 and then create other PRs that improve the user experience.

Sure, it's a first step in that direction