I don’t think anyone’s done the comparison to higan. I did some limited testing a long time ago, but I’d need to redo those tests before presenting any findings.
The fixes are enabled by default since a while back, so you don’t need to do anything other than download the cores. The fixes are completely unrelated to the frame delay feature. Frame delay is an external (frontend) feature and will further lower the input lag.
[QUOTE=e-tank;44628]@Brunnis: i want to start by thanking you for doing these tests and confirming that this issue your patch addresses is indeed not theoretical but actually causes ~1 frame input delay. years ago i brought this up with a few emu authors (you can see how one of those discussions went here: https://web.archive.org/web/20160325102948/https://code.google.com/p/genplus-gx/issues/detail?id=274 , although to his credit ekeeke did change his mind, eventually (ty ekeeke!), you can see the result of the patch required to change the emu’s behaviour here: https://bitbucket.org/eke/genesis-plus-gx/commits/ec554b4b702d337168dfcaf4b4a6248062e2db5b ), albeit w/o any concrete proof to convince ppl, and essentially pretty much everyone told me to piss off. i always hoped to get around acquiring the hardware in order to do these kinds of tests but never had the time, energy, etc. to get it done, so really thank you so much for this. that said your fix kind of does have to do with vsync.
the real issue here is that in order to minimize input latency, when the guest polls input the host should poll input as close to (or better yet after, which we can now achieve in retroarch thanks to the frame_delay parameter) where the guest machine would be in real time. in other words ideally when the guest polls input you’d have the host sync, giving us have realtime >= emutime, and then poll hardware on the host. now, this wouldn’t be very practical to do, but by being clever we can at least minimize the amount of time between realtime and emutime when the guest polls input, which brings me to…
the reason your fix works so well is that retroarch is designed primarily to use vsync in order to sync realtime = emutime. with your fix the guest resumes emulation at the start of its vblank instead of the start its active frame. and since most games on the guest poll input either in vblank or shortly thereafter you’ve effectively cut the time between when the guest polls input and when the host does by ~1 frame, since for most games emutime be only be slightly > realtime when the game/guest polls.
higan on the otherhand syncs realtime = emutime using audio. for example, if you set the audio latency to 8ms in higan (8ms is the lowest my hardware can achieve in retroarch using just audio_sync without audio issues) then once the guest has built up 8ms worth of audio samples it then uses that to have the host sync realtime = emutime. using this setup if higan were to poll input on the host on demand, then it would only ever do so at most 8ms ahead of realtime (emutime > realtime), if this is what higan’s doing your patch would have no affect on stand alone higan (not higan/bsnes in retroarch, that’s different). however, if i understand correctly according to byuu higan only polls input on the host once per frame at the start of emulated active frame. if this is true then your fix would reduce input latency in higan by some amount, i don’t think it be a full frame worth on the avg but i’m not sure, i’m too tired at the moment to do the back of the envelope calculation needed to give a ballpark answer…
anyway, the frame step method you describe is meaningless without context. yes it can help pinpoint problems but you also need to have a good idea of both how the emulator works, particularly when it polls input and when / how it syncs realtime = emutime, and also a basic understating of how the game handles and responds to input.
that said i’m willing to admit i could be wrong, regardless i’m happy to discuss the topic further, well when i’m not so tired and can find the time at least (i’ll try!).
also, i’d like to comment on byuu’s article sometime as from my understanding he’s most def wrong on a few issues.[/QUOTE]
Thanks for a detailed response. Interesting to see the “historic” links. However, I’m afraid you might be overcomplicating the explanation of this particular fix. The reason the fix works is not that it changes the relationship between when host and guest polls. What the fix does is change when the emulator actually uses the input it reads from the host system. Before my fix, the emulator would read the input from the host system, but it would never use that input to produce a frame until the next time the emulator main loop was called. Vsync or no vsync, the calls to the emulator main loop occur 60 times per second, with a periodicity of 16.7 ms. Splitting the input read and the execution of game logic between two calls to the emulator main loop will add additional input lag of almost a full frame, vsync or no vsync (if we assume that the emulator main loop execution time is small compared to the frame period).
So, vsync or no vsync, higan still runs the main loop 60 times per second, with a periodicity of 16.7 ms, which means that reading and caching the input in one call to the main loop and using it in the next will add the same amount of input lag as it does when using vsync. Only disabling all synchronization (i.e. letting the emulator run free at uncapped framerate) would remove the effect of my fix.
Should be pretty simple to test though. I can just disable vsync in RetroArch and test with and without my fix and see if the effect remains. I’ll do it when I can find some time for it.