A question about save file updating

RetroArch General
#1

So, I was playing SOTN, and RetroArch, for some reason, crashed. When I started it again, I noticed I was stuck WAAAAAY before my last save. In fact, one and a half hours of progress were gone. And I HAD saved in this interval, so, what happened to that?

As it turns out, RetroArch/LibRetro will only save whatever changes happen to the SRAM if you properly close the core, or if you turn on an option to do it once every 10 seconds (or more, 10 seconds is the minimal setting I can put it).

Apparently, the reason for that is that some games use the SRAM as part of their own RAM, and they keep overwriting it all the time, which could lead to potential wear of the storage media, and that’s why it has that behaviour.

That’s a fine explanation, but I have three problems with that option:

[ul] [li]If I save, and the emulator crashes, say, 5 seconds after it (before it has the chance to write the newest save), I’ll lose my latest progress.[/li][li]If the emulator crashes WHILE updating the save file, does it corrupts the data?[/li][li]If I’m playing a PS1 game, like SOTN, where I’ll only update the save very sporadically, how does setting the emulator to update it every ten seconds saves me writing cycles?[/li][/ul]

So, rather than try to take that functionality out, (after all, it has its uses), I’d like to ask this: Why can’t “SRAM be updated whenever the game says so” be an option?

It doesn’t even need to be a separate option, it could be under the “SRAM AutoSave Interval” instead of the first option being “10 seconds”, it’s something like “On Game Demand”.

Because, honestly, this is a HUGE reliability issue for me. RetroArch is a awesome software, but If I can’t save my progress properly, I can’t really put my trust in it.

With RetroArch having options like “Configs per Core” and “Configs per Game”, I fail to see why it enforces such a behaviour for every single game/system, when not all of them needs it.

Related to this post of 2014: https://libretro.com/forums/showthread.php?t=1380

P.S.: Yeah, I know I could simply use a SaveState, but let’s face it: They aren’t as reliable. 99% of the time you’ll have no issues with them, but States are still brute-forcing a new RAM into the emulation, I prefer the usual method.

#2

I haven’t played the Mednafen PSX core enough to experience anything like that, but I can understand your frustration. But at the same time… why wouldn’t you use save states? I don’t think I’d ever feel comfortable enough with emulation to regard them as reliable as I would a console, but even the consoles occasionally present problems that cause you to lose progress.

Why not just save a state every time you save in game? You can set a hotkey to select, and save state to ‘A’, so that all you have to so is press select+A, and your state is saved. It’s super convenient, and quite honestly… the hotkeys are what really sold me on RetroArch. My ideal gaming solution involves me on the couch with my controller, and I’m nowhere near a keyboard or a mouse. i don’t even want to think about the fact that I’m playing on a PC, except when I go to save a state.

#3

Yeah, but that’s not the case. Name one other emulator that’s able to lose saved progress, besides RetroArch.

I don’t like save states, because they’re something inherent to the emulator (or, in this case, the core), so, suppose I swap emulators… I’m still able to convert the actual save game to the format the new emulator reads. Can’t do that with save states.

Now, suppose the very same emulator changes how its save states work, and you’ve only saved your progress through save states… You lose all your progress!

Okay, there are solutions for both scenarios i’ve stated above, (you could (re)download the previous version again, save in-game, then load in / convert to the new emulator) but that’s not the point.

I’ve had some experiences where loading a save state would sometimes cause corrupted graphics or sound, due to the way they work (they replace the whole system RAM). Sure, with other emulators, a long time ago… But still…

My point is, why a main feature of an emulator does not give us an option to make it work as intended? Sure, some games use the SRAM as Regular RAM, but why is that not an option? Why force it on every game?

Why do I need to resort to workarounds such as saving a state as I save the game? Shouldn’t RetroArch guarantee me it’d store my data?

What sold me on RetroArch was the practicality of having lots of emulators on a single software, but if the price I have to pay for it is reliability…

#4

Are you using the Mednafen HW core? The software one is rock solid for me; I don’t remember it ever crashing mid game. Same with all the other software cores I use. The latest Glupen build has been quite stable from my testing and my old build of PPSSPP still works well.

I would avoid the HW core for now if you don’t like instability.

I have the SRAM auto save enabled and set to 60 just in case of power loss.

#6

I’ve never actually used the ‘SRam Autosave Interval,’ how does that work exactly?

Edit: Ok, I read up on it.

So no offense to the OP, but this kind of seems like a non issue now. You can set the SRAM to 600 seconds (so that it doesn’t happen excessively) as a preventive measure, and the likelihood of losing anything is dramatically decreased. Unless you saved in game right after an SRAM backup occurred (unlikely), and the game crashed in that 10 minute window (also unlikely) between the next SRAM backup, I don’t think you’re going to have too many problems.

But, to be honest, I don’t completely understand how the current implementation could be improved. Do other emulators handle it differently/better?

#7

I spoke with zeromus about this and he currently does an interval (automatic) in desmume and manual flush in bizhawk, though he’s considering switching to all-manual for everything, which he expects to be unpopular. So, RetroArch’s current behavior is actually not outside the norm and no one has a magic solution.

Having an option to flush on change would make sense for memcard-based systems but it’s too dangerous, IMO, since someone could enable it accidentally (or because of ignorance or a misunderstanding) for the wrong core and not know anything is wrong until it’s destroyed their SSD. As for wear and tear caused by extraneous 10-second interval flushes, that’s 0.0017 times the potential writes of write-on-change, and it can be stretched out further, of course, so significantly less of an issue.

Adding a hotkey is another option but it’s a lot of work for little gain.

#8

So you’re saying setting SRAM auto save to 10 seconds is relatively safe?

#9

Yeah, 10-second interval is relatively safe.

#10

Nope, using the regular SW one. I’ve tried using it, and noticed it caused some issues that where fixed when I disabled “Hardware Acceleration”, so… Why even use the HW core?

And because you don’t crash, suddenly nobody is able to?

By the way, found out what was crashing it: I was using a nightly version, don’t ask me which one though. It was one that had a real nicer XMB than current stable’s one, but crashed after like half-an-hour.

Switching back to the stable release seems to fix the crashing. (After all, it’s called “stable” for a reason)

EDIT: Which Is weird, since, as far as I know, both stable and nightly pull up their cores and assets from the same folder, don’t they? So it was probably an issue with the RetroArch software itself?

[QUOTE=Typhon;53452] So no offense to the OP, but this kind of seems like a non issue now. (…) But, to be honest, I don’t completely understand how the current implementation could be improved. Do other emulators handle it differently/better?[/QUOTE] No offense taken, but, let me tell you this: I’ve downloaded a standalone Mednafen. Booted up the exact same game (Symphony of the Night) with the exact same BIOS files I was using on RetroArch. Got to a room I wasn’t before (marking it on map), got back to save point. As soon as the “Game Saved” message appeared, I force-killed Mednafen task via Task Manager, booted it up again, loaded the file I just saved, all my progress was intact.

Try doing this with RetroArch. Even if the game tells you “Game Saved”, you’ll most likely NOT see the room as marked when you load that save up.

THAT is the issue.

[QUOTE=hunterk;53471]RetroArch’s current behavior is actually not outside the norm and no one has a magic solution.

Having an option to flush on change would make sense for memcard-based systems but it’s too dangerous, IMO, since someone could enable it accidentally (or because of ignorance or a misunderstanding) for the wrong core and not know anything is wrong until it’s destroyed their SSD. As for wear and tear caused by extraneous 10-second interval flushes, that’s 0.0017 times the potential writes of write-on-change, and it can be stretched out further, of course, so significantly less of an issue.

Adding a hotkey is another option but it’s a lot of work for little gain.[/QUOTE] Okay, this option, under menu, controls only advanced settings for the menu?

0mCGrIe.png960×401 65.4 KB

Because seriously, I’ve seen several emulators that hides options behind “advanced settings”, and also would go beyond and pop up a message like “Warning: This could be a really messy option because of X, Y and Z. Do you really want to enable it? (If you don’t know what you’re doing, pick X)” when you try to activate’em after they were no longer hidden.

Still, All I want is a guarantee RetroArch will NEVER lose not even 10 seconds of my progress. Any emulator is capable of doing so, what keeps RetroArch from doing that?

Once the game says “Game Saved” it should be saved!