brunnis
Participant
Post count: 11

Just thought I’d add some observations here as well. I notice input lag in RetroPie as well. It’s not a big issue when I use it on a computer monitor, but it is an issue for some types of games when I use it on my Samsung plasma.

I used a very crude method of getting an idea of the input lag. I only had a 30 fps camera available and I used that to film while I performed quick taps on the controller and mouse I used for testing. I’ve taken the liberty of multiplying the number of frames I counted in my recorded material by two, since that better corresponds to the actual number of frames rendered by the source (since it runs at 60 FPS).

The PCs were tested at the Windows desktop, recording the response from the built-in game controller configuration program and from double-clicking to select text in Notepad. [Granted, that’s a bit apples and oranges, so I’ve added some actual RetroArch measurements in an edit further down.]

[b]Hardware & software[/b]

– Raspberry Pi 3 with RetroPie 3.6 and Super Mario World 2: Yoshi’s Island
– Core i7-6700K with Windows 10
– Core i5-5300U with Windows 7
– Samsung plasma TV
– HP Z24i desktop monitor (24″, 1920×1200, IPS)

[b]Results[/b]

RetroPie + Samsung plasma TV: [b]12 frames (200 ms)[/b]

RetroPie + HP Z24i: [b]8 frames (133 ms)[/b]

Windows 10 + HP Z24i: [b]4 frames (67 ms)[/b]

Windows 7 + HP Z24i: [b]2 frames (33 ms)[/b]

I know of one test that has measured the HP monitor’s input lag and found it to be almost non-existent (less than 1 ms). That would put the plasma at around 60-70 ms, which sounds plausible. I tested many times and these results were quite consistent.

So, RetroPie on the HP monitor responds approximately 100 ms slower than the Windows 7 laptop using the same HP monitor. That’s a very significant difference, but the Windows 7 laptop also wasn’t running an emulator.

I love RetroPie, but this issue (which, granted, may have nothing to do with RetroPie itself) kind of kills it for me. A lot of the games I play/want to play on it are fast paced and rely on exact timing to succeed. And I have definitely noticed that they’re harder because of this.

Is there any work being done on attempting to profile this and come up with a solution?

[b]EDIT:[/b]

Did some more testing with the Windows 7 machine, using RetroArch and Yoshi’s Island:

[b]8 frames (133 ms)[/b] with Snes9x Next and video_hard_sync = false
[b]6 frames (100 ms)[/b] with Snes9x Next and video_hard_sync = true
[b]4-6 frames (67-100 ms)[/b] with bsnes (balanced) and video_hard_sync = true

video_hard_sync did not seem to have any effect on RetroPie, but it did seem to shave off a couple of frames in the Windows case.

What’s interesting here is that I could not come close to reproduce the input reponse from the Windows desktop (2 frames). Input response time (with video_hard_sync disabled) was actually the same as using RetroPie. Does the emulator really need that much time to output to the screen?

[b]EDIT2:[/b]

I just tested the input lag when typing at the command line in RetroPie. A typed character shows up in the next recorded frame, which means that input lag is 33 ms at the most.

So, the Raspberry Pi and the PCs have similar low latency input when just reacting on USB input (such as writing on a keyboard). All devices also seem similarly slow to react on input when running the SNES emulator, although video_hard_sync = true seems to help the PCs slightly.