I just learned about (and immediately tried) this, and it's pretty amazing. And a genius idea, even though the process seems rather obvious in retrospect (like many great ideas). I hope I didn't miss a thread about this!
Some background information:
A new innovation in Retroarch takes this (trading performance for decreased input latency) one step further: below real hardware.
Basically, most games, even on older hardware, have some built-in amount of input delay. On many NES games it's 1 frame (16 ms), on a lot of SNES games it's 2 frames (33 ms) and so on.
What the new options in Retroarch allow is this:
In effect, what this does from your perspective is move your input backwards in time, since you are reacting to output which happened N frames later. It's so neat.
(Note: there is an alternative mode which runs another instance of the emulator core "normally" to generate audio, since the audio output of some emulation cores gets confused/choppy using the method above)
Obviously, this has a high performance cost (i.e. it increases the CPU emulation overhead by a factor of N compared to normal, plus the additional save state overhead) but for fast cores and older systems it works perfectly.
Here's the thread discussing the feature on the libretro forums, with a download link.
Let me tag a few people who I remember from emulator latency discussions back in the old world Tain Dark1x
Some background information:
- Due to various factors, input lag increases when emulating a system have been an issue for a while -- generally more for older platforms (ie. 16 bit and earlier, maybe 32) that had short processing loops/pipelines
- Over the past few years, many improvements were made to popular emulators (or emulation platforms such as retroarch) to reduce or even eliminate that increase in input lag (ie. hard GPU sync, reducing buffering, late-latching inputs, etc)
- At this point, you can get close to (or even, in some cases, match) the original latency for some older systems
- This generally takes more performance since many options to reduce latency trade efficiency for minimizing delay -- this is usually not an issue on PC, but might be on other platforms
A new innovation in Retroarch takes this (trading performance for decreased input latency) one step further: below real hardware.
Basically, most games, even on older hardware, have some built-in amount of input delay. On many NES games it's 1 frame (16 ms), on a lot of SNES games it's 2 frames (33 ms) and so on.
What the new options in Retroarch allow is this:
- Poll the input.
- Run one frame (frame 1) without output (video/audio).
- Create a save state.
- Emulate N-2 (configurable parameter) additional frames without output.
- Render a final frame (frame N) with output -- this is what you see.
- Restore the state saved in 3.
In effect, what this does from your perspective is move your input backwards in time, since you are reacting to output which happened N frames later. It's so neat.
(Note: there is an alternative mode which runs another instance of the emulator core "normally" to generate audio, since the audio output of some emulation cores gets confused/choppy using the method above)
Obviously, this has a high performance cost (i.e. it increases the CPU emulation overhead by a factor of N compared to normal, plus the additional save state overhead) but for fast cores and older systems it works perfectly.
Here's the thread discussing the feature on the libretro forums, with a download link.
Let me tag a few people who I remember from emulator latency discussions back in the old world Tain Dark1x
