An input lag investigation


#810

Does enabling rewind increase the input lag?


#811

Enabling rewind adds a savestate to every frame, which increases processing time by a very small amount. Saving state is usually far less work than emulating a frame.

It’s so insignificant that it only matters for people who are using the Frame Delay feature, and might need to turn that down a notch.


#812

Processing time as in additional input lag or additional cpu usage? I’m aware that it increases the cpu requirements for a core but didn’t know if it increased input latency.


#813

Rewind does have a significant performance hit though. It may depend on how the savestate code is implemented in each core I guess.


#814

If you’re using frame delay, at worst, rewind is going to cost you a couple of milliseconds for most cores (i.e., you might only get up to frame delay 8 instead of 10 or whatever). So, that’s a couple more milliseconds of latency. If you’re not using frame delay, there won’t be any increase at all.


#815

How does it impact run ahead?


#816

It shouldn’t have any effect at all, as both rewind and runahead require taking states on each frame.


#817

Does using either gsync or freesync decrease input lag? I know that in traditional pc games, using either helps to eliminate most of regular vsync lag.

edit: Wow, using scan line sync from RTSS with SSF brings the input lag below beetle saturn + vulkan. Also am not noticing any tearing or stuttering. Hopefully retroarch can get that some day.


#818

Hello Brunis, thank you for all your work on input lag, it is very thorough. Do you own any arcade/fight sticks that you could possibly do any input lag testing on? Really interested to know how the 8bitdo N30 arcade stick stacks up to other sticks like Qanba, Hori, Brooks, etc.


#819

Sorry, I only own a bunch of gamepads, no arcade controls.