Incorrect use of RETRO_ENVIRONMENT_GET_SAVE_DIRECTORY

[Alcaro]

1. libretro.h says "The path here can be NULL. It should only be non-NULL if the frontend user has set a specific save path.". The core refuses to save if the path is NULL.
2. libretro.h also says that GET_SAVE_DIRECTORY can be used "if the libretro core cannot use the regular memory interface (retro_get_memory_data())". The memory interface looks like it'll work just fine; using that instead will solve the above issue, as well as simplifying the core a little. (I could make a pull request for this too, but I'm not sure if I want to fix three bugs without having them merged in between...)

[heuripedes]

1. I picked that solution because I thought it would be inappropriate for a self-contained core to save srm files to the ROM folder (the default save path) whenever the user left the save path setting empty.
2. RetroArch does not call the memory functions to generate a .srm file by itself unless some content gets loaded (e.g., Dinothawr's srm file only gets generated because the core has to load the game assets from a file). 2048 needs no external file to work.

Any suggestions?

[Alcaro]

Can't deny that those are valid arguments. ROM folder is indeed wrong if nothing else is used from there.

My viewpoint is that if the core loads no ROM, the core should be considered to have loaded itself as a ROM, making GET_LIBRETRO_PATH the correct sram path. But I'd rather bounce that idea off Squarepusher before applying it outside my own frontend.

Not saving SRAM on game-less cores sounds like a RetroArch bug; I've raised it there (https://github.com/libretro/RetroArch/issues/836). The proper course of action for us depends on what RetroArch does, so let's ignore this issue until it's resolved on that side.

[orbea]

Can someone please fix or otherwise help work around this issue? It makes it hard to provide libretro-2048 for distros without breaking saves. :( [2048] unable to save game data: Permission denied.

[orbea]

Now it has decided to use the save directory intended for GLupeN64 instead... I guess its confused by Sort Saves In Folders

[guoyunhe]

Any news about this?