Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect use of RETRO_ENVIRONMENT_GET_SAVE_DIRECTORY #4

Open
Alcaro opened this issue Jul 23, 2014 · 5 comments
Open

Incorrect use of RETRO_ENVIRONMENT_GET_SAVE_DIRECTORY #4

Alcaro opened this issue Jul 23, 2014 · 5 comments

Comments

@Alcaro
Copy link
Contributor

Alcaro commented Jul 23, 2014

  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
Copy link
Contributor

  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
Copy link
Contributor Author

Alcaro commented Jul 24, 2014

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 (libretro/RetroArch#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
Copy link
Contributor

orbea commented Jan 18, 2017

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
Copy link
Contributor

orbea commented Jan 19, 2017

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

@guoyunhe
Copy link

guoyunhe commented Nov 2, 2019

Any news about this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants