I have been emulating many different systems (including SNES) on lots of platforms, and have almost never been bothered by lag in the emulation itself.
But one day someone was harping on about lag in an SNES game, so I loaded it up (Android RA SNES9x core) just to double-check before arguing with them… and indeed found the lag quite noticeable. But I also found two ways to reduce the lag significantly.
The first thing is to try different cores. There are multiple versions of SNES9x available on most versions of Retroarch, and there’s a reason for it. The different cores can give surprisingly different results for a single game.
The second thing (which had the greater impact for me) is to enable Retroarch’s look-ahead emulation for one or two frames. Just as it sounds, this will cause the core to emulate the next n frames with every possible combination of inputs. It increases the processing requirements exponentially, but for something like the SNES, many platforms can handle it. I know it seems counterintuitive (if it can emulate hundreds or thousands of possible frames in realtime, why can’t it do just one?) but it worked for me. It must be some kind of throughput vs. latency thing.
Sorry, that’s almost it but they don’t emulate hundreds or thousands of frames, you’re right in thinking that would be implausible. Basically what happens is retroarch makes a savestate every frame and keeps a running list of the last few. When you press a button, retroarch will load one of those states from a few frames ago, press the same button then, then disable video and re-emulate those “rewound” few frames in fast forward. Then once it’s caught up to the present it re-enable video rendering. The end result is that you see the effect of your input happening the frame after you press it, instead of the normal input delay of 2 or more frames. It’s pretty neat. But yea, this means that they’re only emulating an extra 3-5 frames or so not hundreds, and they only have to do it when you press a button, not all the time.
I have been emulating many different systems (including SNES) on lots of platforms, and have almost never been bothered by lag in the emulation itself.
But one day someone was harping on about lag in an SNES game, so I loaded it up (Android RA SNES9x core) just to double-check before arguing with them… and indeed found the lag quite noticeable. But I also found two ways to reduce the lag significantly.
The first thing is to try different cores. There are multiple versions of SNES9x available on most versions of Retroarch, and there’s a reason for it. The different cores can give surprisingly different results for a single game.
The second thing (which had the greater impact for me) is to enable Retroarch’s look-ahead emulation for one or two frames. Just as it sounds, this will cause the core to emulate the next n frames with every possible combination of inputs. It increases the processing requirements exponentially, but for something like the SNES, many platforms can handle it. I know it seems counterintuitive (if it can emulate hundreds or thousands of possible frames in realtime, why can’t it do just one?) but it worked for me. It must be some kind of throughput vs. latency thing.
Sorry, that’s almost it but they don’t emulate hundreds or thousands of frames, you’re right in thinking that would be implausible. Basically what happens is retroarch makes a savestate every frame and keeps a running list of the last few. When you press a button, retroarch will load one of those states from a few frames ago, press the same button then, then disable video and re-emulate those “rewound” few frames in fast forward. Then once it’s caught up to the present it re-enable video rendering. The end result is that you see the effect of your input happening the frame after you press it, instead of the normal input delay of 2 or more frames. It’s pretty neat. But yea, this means that they’re only emulating an extra 3-5 frames or so not hundreds, and they only have to do it when you press a button, not all the time.
Ah, that makes much more sense. Thanks!