Late emulation to reduce input lag?

[mark_k]

This post has a rambling suggestion about how to (maybe) minimise input lag in emulation. [After writing most of this I discovered that RetroArch/libretro apparently implements something like this; they call it "frame delay".]

By input lag I mean the delay between pressing a controller button and the result being shown on the PC monitor. Maybe low-latency vsync mode does exactly this already???

I'll assume emulation runs vsynced, so the emulated Amiga frame rate matches that of the PC display. I'll also assume that emulation of each Amiga frame takes only a small proportion of a PC frame. For example WinUAE might take 10% of PC frame time to emulate one Amiga frame.

How does the timing work then? Is it like this?

[PC vblank]
[PC output image is of previously-rendered Amiga frame n]
WinUAE wakes up, detects user input, renders Amiga frame n+1 and hands it off to the graphics driver
WinUAE sleeps until the next PC vblank (i.e. for ~90% of frame time).
[PC vblank]
[PC output image is Amiga frame n+1]
etc.

In that case there is a delay of ~90% frame time between when WinUAE finishes rendering the Amiga image, and when it gets shown on the PC display.

An alternative would delay emulating each frame, so there is a smaller delay between sampling input devices/emulating/handing off image to graphics driver and when the image is displayed on the PC monitor.

[PC vblank]
[PC output image is of previously-rendered Amiga frame n]
WinUAE sleeps for 80% of frame time.
WinUAE wakes up, detects user input, renders Amiga frame n+1 and hands it off to the graphics driver
WinUAE sleeps until (next vblank time + 80%)
[PC vblank]
[PC output image is Amiga frame n+1]
etc.

Waking up at the 80% point of each PC frame allows for some leeway; some Amiga frames take longer to emulate than others, other programs running on the PC might make emulating that frame take longer etc. With that scheme, the delay between checking for user input and when the emulated Amiga frame gets displayed would be <= 20% of a frame.

Different speed PCs, emulation settings and graphics drivers would need the amount of sleep to be adjustable.

[Toni Wilen]

There is -extraframewait <value> command line parameter that waits <value> milliseconds after each frame before emulation of current frame starts, made just for this purpose. (not officially supported!)

Note that next version will have lower input latency and also sound latency (wasapi only currently).

[mark_k]

Excellent, I didn't know about that. I'll give it a try next time I boot into Windows. (It's unlikely to work well on Wine.)

Perhaps a future version could add GUI support and some kind of auto-adjust feature. E.g. start emulation, WinUAE initially uses 10ms delay. If no overruns (emulating Amiga frame always completes before PC vblank) after a certain number of frames then try 15ms, 17.5ms. If overrun dial back to 16ms etc. Or just tell the user there was an overrun in the log so they can adjust manually.

Edit to add: How does the current -extraframewait work with black frame insertion? It should sleep from PC vblank prior to a non-black frame, and wake up part way through displaying a black frame. As opposed to the other way around of course.

[mark_k]

Are any other config settings required for the -extraframewait setting to be used?

Looking at the framewait() function in custom.cpp, it seems the value returned by isvsync_chipset() needs to be < 0 but not -2 or -3 for the code

if (extraframewait && !currprefs.turbo_emulation)
    cpu_sleep_millis(extraframewait);

to be executed. I couldn't find which file defines the isvsync_chipset() function, at least a search for the function name in the WinUAE repository on github didn't show that.

Also in win32.cpp there is

cfgfile_target_dwrite (f, _T("extraframewait"), _T("%d"), extraframewait);

Does that mean it can be used in config files too?

[Tomislav]

Originally Posted by mark_k

I couldn't find which file defines the isvsync_chipset() function, at least a search for the function name in the WinUAE repository on github didn't show that.

isvsync_chipset() is in drawing.cpp in root of WinUAE source directory.

[Toni Wilen]

It is unsupported, don't ask too specific questions

It should work with low latency vsync and with black frame injection.

It is impossible (without time machine) to make it automatic, emulation time usage can be extremely variable.

[Dr.Venom]

Originally Posted by mark_k

Are any other config settings required for the -extraframewait setting to be used?

Hi mark_k,

Since you're interested in it (or anyone else for that matter), it's probably good to mention that -extraframewait (framedelay) currently does not work with Wasapi audio modes, as framewait gets aborted as soon as there's a Wasapi pull event.

Just so that you don't get the wrong impression when testing it.

But as Toni mentioned, it's an unsupported feature (currently).