[snes] saving is implemented badly
So, I've just lost a save, likely due to ares crashing.
I've got autosave turned off cause time based saving is just plain bad idea.
My question is: I've saved in-game several times, yet it was never written to disk. Why ?
Shouldn't it be natural to save to disk when the game writes its save ?
Due to the nature of a lot of these retro systems, it's not always viable to detect when gamesaves happen: on some systems/games, there is no difference between writing to ram, or writing to save-ram.
There's also the issue with some games that spam save-data so often that if we write to disk on any save-data write, the disk thrashing would cause emulation speed to scroll down to a crawl.
Saving on exit, or periodic flushing of saves to disk is the best way to avoid this situation.
The ares autosave feature will write the games sram to disk at 30 second intervals; as well as the standard functionality of saving on emulator close, or unloading a core.
Because remember: the S in SRAM does not stand for Save.
I've always used both savestates and ingame saves. Even if one goes bad, I have the other.
But yeah, it would be natural to save to disk when the game writes its save, but not all in-cart SRAM is actually used as save. Because it's Static RAM, not Save RAM. The battery just makes it useable for that purpose.
Well, on the other other hand, my point about timeout based autosaves being dumb is that it makes for a lot of pointless writes when the state didn't change at all.
Those would only make sense if it was "autosave every <time period> if the state has been modified".
...and on an unrelated note: currently I'm working around the problem by unloading after I save.
That kinda 'works', but there's a minor gotcha.
I'm not sure if it's toolkit dependent or not, but gtk3 frontend is prone to random gui freezes during unload/reload cycle. It doesn't happen every time, but often enough to be at least mildly annoying.
closing as this is not an issue so much as an intentional design decision.