[BUG]: Total input counter is not updated upon loading state (input recording)
Describe the Bug
Normally, when one loads a state during an input recording, the total input counter (which is shown next to the current inputs played) is updated, but in PCSX2 this is not the case. For example, your input recording has 35000 frames processed, but during recording or after toggling read+write mode and you decide to load a state to undo your mistakes, that total counter still remains at 35000 and not a previous value that matches with the last savestate you did.
Personal thought: I don't know if this is one of the main causes of general desyncs aside from the lack of a custom RTC setting like Dolphin does.
Reproduction Steps
- Load any game and start input recording, either from power-on or current frame (savestate as shown in the GUI).
- At any point in the game, make a savestate.
- Then, let the input recording continue for some time and load the state that was made prior to this step.
Expected Behavior
The total input counter must be updated after loading a state during input recording, e.g. Frames before the loadstate: 25001/25000 (dunno why this offset). Frames after the loadstate: let's say 22500/22500 and not 22500/25000 as it's currently happening.
PCSX2 Revision
v1.7.4065
Operating System
Windows 10 (64bit)
If Linux - Specify Distro
No response
is this still an issue on latest nightly ?
is this still an issue on latest nightly ?
It still does. Whenever I load a savestate, the second number after the slash symbol isn't updated, not to mention there is another issue where input recordings always start with 1/0 instead of 0/0.
is this still an issue on latest nightly ?
It still does. Whenever I load a savestate, the second number after the slash symbol isn't updated, not to mention there is another issue where input recordings always start with 1/0 instead of 0/0.
At the very least, I've fixed this issue. The internal counter is correct, but the value we display for the current count in ImgGuiOverlays.cpp is the current value + 1, thus it results in "n+1/n (n)" being displayed.
After going way too deep into this rabbit hole, I believe I've fully resolved this with #10793.