[iOS] RetroArch do not respect SaveRAM Autosave Interval

[nighto]

Description

On iOS, even if you set SaveRAM Autosave Interval, it does not write the internal save game to iPhone's memory if you don't Close Content manually.

Created a short screen capture video to demonstrate the issue: https://youtu.be/49jiAgAqCOI

Expected behavior

The user would expect that it would flush the saved game to internal memory respecting the SaveRAM Autosave Interval setting.

Actual behavior

Save game data is lost

Steps to reproduce the bug

1. Set SaveRAM Autosave Interval to some value, for instance 10 seconds.
2. Open a game, save it, wait for the number of seconds you have specified in setting, close RetroArch via iOS application menu (i.e. not by Closing Content or exiting gracefully)
3. Open RetroArch and the game again, saved game data is gone

Bisect Results

I believe it has always been like that

Version/Commit

You can find this information under Information/System Information

• RetroArch: 1.16.0

Environment information

• OS: iOS 17.3.1
• Compiler: (using RA supplied .ipa)

[hizzlekizzle]

This is typically handled on a per-core basis. That is, cores that don't implement the libretro save interface aren't able to take advantage of that interval. Are you sure you're using cores that work with it? Note: on devices that don't support threading, this feature doesn't work, since it requires running on a thread.

[nighto]

@hizzlekizzle thanks for your feedback. I am not sure whether the core I am using implement or not. Do you know where I could find that information? Or whether the device support threads or not? I see the same thing happening on iOS and on PSVita.

In both devices I was testing GBA emulation with gpSP core, and on https://docs.libretro.com/library/gpsp/ I see a checkmark on "Saves" but I am not sure if that means it uses libretro save interface or not.

Though by your comment I understand that it might be helpful to test other cores.

[hizzlekizzle]

I know gpSP historically didn't support it because it used its own save system, but I'm under the impression that was fixed a few months ago and so it should probably work now. I'm not abreast of threading status on PSVita but iOS should definitely have it AFAIK.

I would suggest trying snes9x as a baseline core that should definitely support it.

[nighto]

Thanks, I will close the issue for now to test and, if that's the case, eventually reopen it (and anyhow left a comment with my findings so future people can know about it.

[nighto]

My findings, with RetroArch 1.16.0 emulating GBA games with different cores, testing the internal save, waiting the seconds as set on SaveRAM Autosave Interval and closing RetroArch non-gracefully via iOS application menu:

• Beetle GBA: save data is lost to the last time you did Close Content manually
• gpSP: save data is lost to the last time you did Close Content manually
• mGBA: save data is correctly written to device memory
• VBA Next: save data is correctly written to device memory
• VBA-M: save data is correctly written to device memory

So I had the issue described because I was playing a game with gpSP core. Why? Don't know, chosen randomly.

From the end user perspective, who is not necessarily familiar with specific cores support, I think it would be great if we could somehow indicate this on the user interface. There are a lot of reports of users losing save game data and it could really be as simple as this - setting a sensible default for SaveRAM Auto Save Interval (I'd say 10 seconds would be OK for most devices) and indicating clearly on the RetroArch interface which cores support this option and which cores doesn't.

@hizzlekizzle do you think that it would be useful to open an issue for the second part? Thanks again for your attention into this issue.

[nighto]

Comparing the Features table from https://docs.libretro.com/library/gpsp/ with https://docs.libretro.com/library/mgba/ , I see that mGBA supports "Core Options" while gpSP does not. Is this "Core Options" the implementation of libretro save interface? @hizzlekizzle

[nighto]

Created a PR on libretro docs to mention this explicitly in documentation, so it is not buried here in comments.