Latency - real hardware + CRT versus PC emulation

[andykara2003]

What do you guys think is the lowest latency possible attainable when using emulators? - Specifically Mame and the Nintendo stuff (Nes, Snes, N64, Dolphin etc.)

i.e. in real world terms, what is the closest a PC emulated game can get compared to a console/CRT setup in terms of overall latency in milliseconds. Obviously this will vary from emulator to emulator and from PC to PC but I'm assuming that we'd be using the most optimised setup & emulators possible.

I guess the factors involved in reducing latency in the various parts of the chain are:

1: Having the lowest latency monitor possible - I'm not sure how accurate manufacturer's figures are but perhaps sub-5ms overall latency is possible?

2: The inherent latency of the emulator - I suppose this will vary among the various emulators, so I'd assume we'd be using the fastest emulator for each system.

3: Obviously using a wired controller

4: Having a PC that is well optimised for the job. Not sure of the precise factors involved here but I'd be interested to know.

5: I'm assuming that a PC is being used that's more than powerful enough to run any of the emulators.

6: Is it necessary to use v-sync to completely avoid screen tearing? If so, that will introduce lag - but by how much?

I realise that there are so many factors involved that it would be impossible to predict exact numbers, but I'm interested to hear a ball park figure of what might be possible.

Cheers

[BONKERS]

A lot of PC monitors are in the sub 10ms range. A wired controller obviously helps.

Using Dolphin as an example. In exclusive full screen mode there AFIK is no lag over what exists from the games themselves. This was a big point for them a while back. And is one of the reasons why it's so popular with Smash players.

[Asbrandt]

A1:

A lot of PC monitors are in the sub 10ms range.

It should be noted that this value, presumably from displaylag, does not account for the pixel clock time being roughly equivalent to the beam sweep time of a CRT, a 10ms average is in reality about 2ms behind a CRT, a very respectable value.

A2:
PC graphics is a framebuffer based system, emulating another framebuffer based system, such as most 3D hardware (I'm not sure about the Saturn) or CGA/EGA/VGA DOS hardware, should not introduce lag on it's own. It takes approximately 4ms for input to trickle through the DirectInput API, but that can be accounted for on any system capable of running the target system at 134% speed without too much difficulty.

The trouble comes when emulating a system that is -not- framebuffer based, such as any tile based PPU/VDP type system, where the framebuffer introduces a full frame of lag, because it takes 16.66ms to build the frame and then another 16.66ms to clock it out to the monitor, while normally a PPU/VDP generates each pixel and sends it to the display immediately.
The timing sensitivity of those systems also makes accounting for that 4ms from DirectInput much more difficult.
Both of these hurdles can be overcome but it is significantly more complex involving parallel emulations at different speeds, which also involves more CPU performance (and I could be mistaken, but also a 120hz monitor). GroovyMAME uses this strategy to an extreme due to complications introduced by MAME's focus on preservation.

A3:
Wireless seems to depend on the protocol involved, but wired is just less to worry about in this regard. A high polling rate controller also helps.

A4 / A5:
CPU single-threaded performance is almost always the limiting factor, although GPU power shouldn't be neglected either for PS2/GC, otherwise, see A6 since it it relevant aswell.

A6:
No old system is exactly 60.00hz, so the necessity of vsync depends on the flexibility of your monitor regarding input. The further away from 60 the target system is, the more likely you will need a technology like adaptivesync or gsync to avoid tearing without vsync.
In either case, you will need to be running the emulator in fullscreen so it has full control of the GPU without having to cooperate with your OS' desktop rendering.
The amount of lag introduced by vsync depends on the buffering scheme used by the particular implimentation, it could be anywhere from 1 to 2 frames, if memory serves.

[andykara2003]

Thanks for that Asbrandt - much appreciated.

So could I gather from that that we could get a very rough ballpark by:

1: Discounting any latency advantage of a CRT as explained in A1.

2: Assuming that the NES, SNES and N64 are PPU based, start with 16.66+16.66= ~33ms for framebuilding & clocking out to the monitor.

3: Adding the 4ms DirectInput delay (assuming that using parallel emulation is not the norm).

4: If we use v-sync, adding an extra 16-32ms - or if using an adaptive sync setup, no extra latency.

Therefore at best case scenario, 33ms+4ms= ~37ms, worse case scenario, 33ms+4ms+32ms= ~69ms?

[Asbrandt]

Thanks for that Asbrandt - much appreciated.

So could I gather from that that we could get a very rough ballpark by:

1: The 2ms still counts if you want to be technical about it, since it's not affected by anything on the system side.

2: The 16.66ms should only be counted once, the framebuffer time, the clockout / scan time will exist on the original system with a CRT too. And iirc N64 is a framebuffer system, not PPU/VDP.

3: This one is slightly complicated, because it depends entirely on how the target system reads input. If input is read 4ms into a frame or later, then it is 0 latency, but if it's read before that, it's a full frame of latency, hence the timing adjustments of the emulation to compensate. Using RawInput would make it a narrower window but emulation generally uses SDL for easier porting between OS' iirc.

4: Correct, although some monitors will take a range from 59.4 up to 60.6, you'll need to test with your own monitor to be sure.

For VDP/PPU systems, worst case would be 2+16.66+16.66+33.32 = 68.64 as you said, but I suspect you could realisticly run without vsync if you have a gaming monitor, knocking off that last 33.32.
It is entirely possible to achieve only the 2ms latency, but it would require emulator developers for PPU/VDP systems to leverage every trick in the book and it can become a challenge of multi-threaded programming to do so.

For Framebuffer systems, you should only be looking at a 2+16.66+33.32 = 51.98, but the same possibility to run without vsync and removing the 33.32 still stands, and the 16.66 is significantly easier to fix for these types of systems in general, hence why Dolphin can be lag-free (aside from the 2ms of a good monitor).

[andykara2003]

Thanks - In that case would I be correct in saying that assuming the emulator devs aren't currently using the PPU/VDP workaround, the input is read 4ms into a frame or later & we are using a gaming monitor that can cope with the slight variations or an adaptive sync setup, then the best case scenario for the NES & SNES could be 2ms+33.32ms= ~35.32ms and best case for the N64 emulation could be as low as 51.98-33.32-16.66= ~2ms - similar to Dolphin & basically the same as a CRT/N64 setup?

[Asbrandt]

Thanks - In that case would I be correct in saying that assuming the emulator devs aren't currently using the PPU/VDP workaround, the input is read 4ms into a frame or later & we are using a gaming monitor that can cope with the slight variations or an adaptive sync setup, then the best case scenario for the NES & SNES could be 2ms+33.32ms= ~35.32ms and best case for the N64 emulation could be as low as 2ms, making it basically equivalent to a CRT/N64 setup?

For PPU/VDP systems 35.32ms is the best case if you assume that control reads come -before- the 4ms window and since the game code determines control read timing on those systems, I would stick to including that frame of latency, so 35.32ms would be correct anyway.
For N64 and other Framebuffer systems, the timing adjustment for the 4ms window still requires purposeful implimentation so I would say 18.66 is the best case unless it's developer has mentioned reducing input latency.

So you could say as a rule; If you are not using vsync, 2ms of display latency for a good gaming monitor, plus one frame of input latency, plus one frame of display latency for PPU/VDP and other framebuffer-less systems.

Here's to hoping that as emulator development progresses, we see forks that do go out of thier way to fight latency like GroovyMAME has.

[andykara2003]

Thanks very much for your insights - this is something I've wondered about for a while so it's good to finally have some answers... Also, I'd always thought that 50/60Hz CRTs were sub 1ms - learn a new thing every day

[Asbrandt]

Thanks very much for your insights - this is something I've wondered about for a while so it's good to finally have some answers... Also, I'd always thought that 50/60Hz CRTs were sub 1ms - learn a new thing every day

If you're using a CRT monitor on your emulation machine then you would remove the 2ms from the total.

If you mean the frame of display latency in the "rule", that has nothing to do with the monitor itself, that is all the framebuffer of the PC platform being forced upon the emulator for PPU/VDP systems, I just count it as display latency because it is adding to how long it takes the image to be displayed, which is different from how long it takes your button presses to register.

[andykara2003]

Ahh I see - I was thinking of a CRT in use with console hardware - i.e. a 50/60Hz CRT + NES/SNES/N64= sub 1ms.. Is that incorrect?

[Asbrandt]

Ahh I see - I was thinking of a CRT in use with console hardware - i.e. a 50/60Hz CRT + NES/SNES/N64= sub 1ms.. Is that incorrect?

Original system + a non-HDTV CRT is considered the benchmark, 0 latency, yes.
I say non-HDTV because many or most HDTV CRTs have image processing that introduces latency.

[andykara2003]

Ah great thanks :)

[Pasky]

Don't forget about input delay from the serial (USB or otherwise) controller.

[Asbrandt]

Don't forget about input delay from the serial (USB or otherwise) controller.

This is included in the 4ms number for DirectInput, which is really 3ms + 1ms for a maximum poll rate input device. As far as I know any decent gaming oriented input device will use maximum poll rate nowadays.

EDIT; Even 360 and PS3/PS4 controllers, which use a low poll rate on console, are configured for full speed on thier PC drivers from what I found via google.

USB adapters for console controllers is another question entirely however, and I don't have any experience with them to give you a quote on how much they could add to the input window.