RetroArch
RetroArch copied to clipboard
libretro
Save state wrap-around
Description
When save state auto indexing is enabled, and maximum kept states are limited, wrap around to slot 0 after reaching the configured maximum.
A gap in the indexing is used to keep track of most recent state. If e.g. maximum kept amount is 5, then indexes 0..5 will be used, if 3 is empty, most recent state is 2. Presence of gap is maintained by garbage collector function.
Tested in several scenarios:
- no limit (maximum kept = 0)
- limit set up, load/save
- limit change from lower to higher
- limit change from higher to lower (extra saves created earlier will remain, but wraparound works correctly)
Previous maximum finder and garbage collector logic unified since now it requires very similar processing.
Originally, I planned to implement a more complicated version, where e.g. 10 lowest slots were reserved for saving manually (hence the "_without_reservation" in the branch name), but it turned out to be overly complex, with extra options, and still having lots of quirks, so I trimmed it down to this, without any optionality.
Also, doing extended cleanup would be tricky and easy for the user to make errors, so the only-one-delete-per-save rule is kept.
Related Issues
Fixes #10471 Fixes #16723 (will not allow loading old slots >999, but will prevent it from occurring)
If e.g. maximum kept amount is 5, then indexes 0..5 will be used
This is another weird behaviour in Retroarch, a mix of array indexing and natural numbers. If 5 is the upper limit, why are there 6 save slots being occupied? I think slot 0 should be removed entirely.
Yes, it is stupid on every possible level that the count starts at 0. I would not mind changing it all the way regardless of breaking previous saves, but a cosmetic change is also ok.
I don't think it would break previous saves if Retroarch simply couldn't create a savestate at index 0, or load from it. It would just leave an orphaned save state if one existed.
If 5 is the upper limit, why are there 6 save slots being occupied?
The reason is the gap that allows to determine which one is the most recent. So, out of the 6 slots, 5 is occupied at any time (after the range is filled up).
Having an index 0 is needlessly technical, I can agree with that, but I personally would not like to bring a breaking change just because of that. Cosmetics can be adjusted at some point, but maybe it will be confusing to someone who has just lost "state14" in a filesystem accident.
Anyway, the point of auto-indexing is that one can just spam F2 to save, F4 to load last, and only go to the slot list when an older save is needed, and in this case I guess it is easier to look through the first x+1 entries, instead of a long list which is mostly empty.
I think it's not worth it to try to mess with save state slot 0 even if we only represented it visually as Slot 1. Probably would cause a lot of unintended confusion among users who have grown accustomed to this over the years for very questionable gains if at all.
