Snes controller lag

Rion

@rbcastro Activate game mode on you TV like @BuZz mentioned and then have a look at @Brunnis thread An input lag investigation

rbcastro

I'll try all these options mentioned.

Thanks guys

Rion

@rbcastro One more thing about Cpu Governor and performace here

rbcastro

My TV only have DEFAULT, MOVIE, NATURAL and DYNAMIC image modes.

BuZz

@rbcastro What is the model number of your TV ?

rbcastro

@BuZz is a SAMSUNG SMART TV UN40ES6100GXZD.

Is something to do with VIDEO OUTPUT on configurations (type A when the rom is about to run)?

Capeman

Im pretty sure that emulation in general creates at least a frame or 2 of lag. I hooked the pi up to a CRT to test Mario World, and compared it to a real SNES running the same game, and even with the lagless analog TV, there is still a frame or 2 of lag coming out of the pi. Add that to the few frames you lose by connecting to a LCD (even on game mode) and it's definitely noticeable.

Mario World is a special case, Mario's jump is frame perfect to the button press and it's so instant that even a single frame of lag is noticeable. No matter what emulator i used in the present or past (openemu on mac this week, snes9x back in the windows xp era, zsnes on an old windows machine with a VGA monitor on win98), i've always noticed a lost frame or 2 in this game.

BuZz

@Capeman yes there are a couple of frames by default due to the buffering etc. there is a good thread about it on the libretro forums with details of settings to tweak to reduce it - see https://forums.libretro.com/t/an-input-lag-investigation/

BuZz

@rbcastro I would have thought that tv would have the settings - check the e-manual. Check under settings -> System -> General (your menus might be different - I wasn't sure from the manual I found for your screen and the samsung manual download didn't seem to work!

rbcastro

@BuZz I found the GAME mode, but I changed the output video configuration to:

800x600 @ 75Hz 4:3, clock:49MHz progressive

Doing that, the lag seems to get a bit better.

BuZz

@rbcastro you might get jitters though as 75hz vs 60hz refresh of NTSC games. I would use a 60hz mode.

Brunnis

@Capeman said in Snes controller lag:

Mario World is a special case, Mario's jump is frame perfect to the button press and it's so instant that even a single frame of lag is noticeable. No matter what emulator i used in the present or past (openemu on mac this week, snes9x back in the windows xp era, zsnes on an old windows machine with a VGA monitor on win98), i've always noticed a lost frame or 2 in this game.

I've spent a lot of time on this subject (see the thread BuZz linked to) and my understanding/theory right now is that even the original SNES had some lag, which varied slightly from game to game. Super Mario World is not really a special case, nor is it instant. It needs three emulator loops to respond to input. On a real SNES, that "should" correspond to:

0.5 frames on average between pressing button and the console sampling the input.
+2 frames in which no reaction is seen.
+0.5 frames: The third frame after button press will show a reaction. The frame is scanned out from top to bottom, so content at the top will be seen earlier than content at the bottom. A good way of measuring an average would be to stop the stopwatch when a reaction in the middle of the screen can be seen.

The above summarizes to an average input lag of 3 frames (50 ms).

I have seen some (slightly flawed) tests of input lag of real SNES hardware on a CRT, and they seem to confirm this hypothesis. I've yet to confirm this with my own testing, but I have an SNES and an original controller equipped with an LED, so I will hopefully get around to it soon.

@Capeman said in Snes controller lag:

Im pretty sure that emulation in general creates at least a frame or 2 of lag. I hooked the pi up to a CRT to test Mario World, and compared it to a real SNES running the same game, and even with the lagless analog TV, there is still a frame or 2 of lag coming out of the pi. Add that to the few frames you lose by connecting to a LCD (even on game mode) and it's definitely noticeable.

Yes, if you have a fast system that allows you to minimize buffering and utilize a feature like RetroArch's Frame Delay, you'll arrive at 1-2 frames of additional input lag over the real thing. That kind of lag is generally not a problem, even for very discerning players. For example, my tweaked RetroArch-based Pentium J4205 system achieves an actual measured average input lag of 4.5 frames in Super Mario World on my HP Z24i LCD display. And it feels pretty awesome.

The "problem" appears when using slower or untweaked systems and slow displays. For example: The default RetroPie setup uses default settings for both buffering (video_max_swapchain_images) and Frame Delay (video_frame_delay). It does so for good reason, since the Raspberry Pi is not fast enough, generally speaking, to maintain framerate otherwise. Using these default settings, input lag increases by 1.5 frames over my Pentium J4205 system mentioned above.

The Raspberry Pi also has a pretty slow, in terms of input lag, OpenGL implementation. My tests have shown that it's 1 frame slower than Intel's and AMD's linux drivers in this regard.

So, compared to my Pentium J4205 system at 4.5 frames in Super Mario World, a default RetroPie setup achieves an input lag of 7 frames on the same display. The result for the Raspberry Pi can be improved by tweaking the settings, but they all have some drawbacks compared to using the default settings. Now, add in a typical TV with 2.5 frames of additional input lag and we're at 9.5 frames. The spread, depending on setup/configuration is therefore pretty big:

Original console on CRT (not confirmed): 3 frames (50 ms)
Moderately tweaked PC setup on fast display: 4.5 frames (75 ms)
Default RetroPie setup on average TV: 9.5 frames (158 ms)

In general, I'd say emulation itself isn't that prone to input lag, as long as long as the emulator works well and the host system is fast (computationally) and has a good video driver. The 4.5 frames input lag I get with my Pentium J4205 system could actually be further improved upon. With a faster CPU, additional Frame Delay could be used in RetroArch. With an interrupt based input scheme, we could get rid of the USB polling interval. All in all, we'd likely be down to just a single frame behind the "real thing".

Note: The measurements I've done are all on my HP Z24i. Although it has been tested by one reviewer to have less than 1 ms of input lag, I have not been able to confirm this with my own testing.

Capeman

@Brunnis Wow that was very in-depth, glad there are more educated people than me looking into this kind of stuff. All my tests were done using slow motion iphone video with side by side comparisons, not very accurate in the technical sense. Thanks for the extra info!