[Feature Request] SDL - add option to save in preference dir instead of game dir

[Pixelnarium]

When using SameBoy SDL it tries to create a save file in the game directory. If creating this file fails (i.e. the folder is read only) SameBoy just does not save.

An option or fallback to use SDL_GetPrefPath would be nice. The libretro core already has some things that are needed for that (i.e. the extract_basename function)

[orbea]

I also agree that being able to configure the save directory at run time and / or in a config file would be nice.

[KMetalmind]

This could be used for a portable mode (saving the config file on the same directory as Sameboy).

[LIJI32]

I kind of forget of this issue, but there's a rationale for SameBoy being very naïve when it comes to save state locations, mimicking classic Windows emulators. There's a fundamental problem with saving saves in a separate directory, and it's associating a ROM with its save file. It can be done in several ways, each with its disadvantages:

1. Basename based. The most naïve and easy to understand one, but forbids the user from having two saves for the same game without renaming one copy. The users will also "lose" their save if they rename the ROM.
2. Fullpath based. Similar to 1, but allows two saves for one game. However, to "lose" your save it's enough to move the file, change mount points, etc.
3. ROM title based. Users never lose their saves, but saves are shared across all copies, including different revisions and potentially ROM hacks.
4. ROM hash based. The average user will never lose their saves, but saves are shared across all identical copies. Bad for power users, developers, and so on, as any modification to the ROM effectively "loses" the same
5. Volume ID + inode based. Moving, renaming or modifying the file preserves the save; but actions that affect the inode (copying, moving across volumes) do not. No longer trivial to manually associate a ROM and a save.
6. Library management. This is what emulators like OpenEmu for macOS do. ROMs must always be copied to a emulator-managed library before running. Terrible for developers, as continuously changing ROMs will be copied over and over again, with a clear save every time.

Now, even if I only adopt this as a fallback method, it raises several questions that should be answered:

1. Assuming a ROM is played from a read-only directory and triggers this behavior, saving its battery in the preferences directory. If an identical or similar (depending on the association method used) ROM is played from a read-write directory, should it load the other file's save file? What if it has its own save file?
2. Same as 1, but instead of opening another ROM, the directory becomes R/W and the original ROM is played again. Does it load the save? Where does it save the new save on exit?
3. Alternatively, a ROM in a R/W directory that becomes a R/O directory. Should it load the associated save, knowing it can't overwrite it, then save the new save in the preferences directory?
4. A situation that can happen after 2 or 3 is having a ROM that has two saves; one in its own directory and one in the preferences directory. Which one should it load? Does it depend on which save files are writeable?

As you can see, there's no trivial solution that satisfies all needs and users, often creating limitations, seemingly lost data, and behavior that may not be obvious to the user. Unless somebody has a better suggestion, my idea is to warn users when opening a ROM from a R/O directory (assuming that ROM has data to save), and offer to copy that ROM to a user-selected directory (by a file select dialog) before continuing the execution.

As for portable mode, it was recently added to master; if prefs.bin exists relative to SameBoy's executable, it will read and write that file.

[Bakaba]

Well, just let us choose the directory at least