orange808 wrote:
Are we using frame rate conversion? When is the emulator finished rendering the frame? When did the emulator poll the controller? Is the "vsync" really synced up to our emulator application output or is it synced to the OS? (It isn't sync to our emulated machine, mate.)
Admittedly I don't know the emulator terminology. I do know modern graphics API's quite a bit though.
The only scenarios where a well implemented vsync pipeline should produce more than 1 frame of lag on it's own is when the game is trying to display more than 1 frame per monitor refresh. Or when simulation and rendering of a frame takes longer than the monitor refresh interval.
If we're talking older monitors. We can assume 60Hz refresh rate. But if we're talking gsync then it's pretty safe to assume it's upwards of 120. Let's call this
Is frame rate conversion attempting to produce more than

frames per second?
Is the emulator taking more than 1/

to produce a frame from start to finish?
Is the emulator caching controller inputs at some odd time? Or is it adapting the emulator poll to a current hardware poll?
vsync doesn't synchronize to the OS. It's either synchronized to the gpu itself or completely disabled under the hood. And if the OS is disabling it under the hood then that's a strictly different problem set than beam racing is attempting to solve.
So, assuming the emulator has some notion of when the emulated game would have expected the television to restart at the top. It's pretty trivial to synchronize it's modern output to that emulated wait state. And as long as it finishes everything else in less than 1/

then it shouldn't matter. You're capped at 1 frame of lag generated by vsync itself.