RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login

    Input Lag Analysis on RetroPie

    Scheduled Pinned Locked Moved General Discussion and Gaming
    input laglatencyemulatorpdfanalysis
    6 Posts 3 Posters 3.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • thelostsoulT
      thelostsoul
      last edited by

      Author: thelostsoul (Tuncay D.)
      Date: 2019-01-07
      License: Free to download and share without editing
      Source: Input Lag Analysis on RetroPie.pdf

      For now, the whole article is only available for download. If everything is correct, I may reconsider to add its content at this place. The document is just 8 page "long". It is about my personal setup, so no universal application here. The content talks about what I measure, how I did, what settings are used and shows the results. It includes some screenshots and even links to 240 fps video footages. Multiple games and systems are tested, in hope to find the latency values for my RetroPie build. If something is wrong, please let me know. Tell me what you think. Here is some example content:

      Test 1: Game and emulator lag
      NES Mega Man 2 (U): 40 ms latency

      Test 2: Overall real time lag
      NES Mega Man 2 (U): 63.4 ms latency

      Mega Man 2_small.jpg

      Conclusion

      So, this was a little adventure. At the end of day, I am a lot surprised. Some results
      are not consistent and others look unbelievable. My hope for a clear answer just dis-
      appeared. In example, the lag with King of Fighters ‘98 in Test 1 sounds a
      bit too high for my taste. The outcome of Super Mario World at Test 2
      looks suspicious too. Super Metroid, Sonic and Donkey Kong share at
      least one thing in common: Their difference between Test 1 to Test 2 are
      around 33 to 36 milliseconds. I consider this value as the added latency of
      my input and output devices.

      What can I take from this? The total latency on my setup is approximately 70 to 100
      milliseconds (4 to 6 frames) for most games, if everything is taken into account and is
      correctly done. That sounds and feels acceptable to me.

      📜 RE/SET: 100 SNES Games for your RetroPie, 🎁 Share your hidden gems and insider tips

      1 Reply Last reply Reply Quote 0
      • ?
        A Former User
        last edited by

        Would be interesting to see a similar test done on a Pi connected to a CRT, either using the composite out, or Pi2Scart. I noticed far less lag going from originally a 1080p LCD TV, to my Trinitron CRT. I also swear the lag has also slightly decreased going from my USB Hori Rap V4, to the Scorpion Arcade Stick. The Hori was seen as a USB stick, while the Scorpion is seen as a keyboard controller. I wonder if the keyboard controller has less lag ? It feels like it does - tested on Super Mario 2 NES.

        thelostsoulT 1 Reply Last reply Reply Quote 0
        • thelostsoulT
          thelostsoul @A Former User
          last edited by thelostsoul

          @John_RM_70
          I actually use a CRT pc monitor (60 Hz), but it is connected with HDMI to VGA converter. The fightstick I have can operate in different modes, forgot to mention that, it was set to PC mode. Available modes are Xinput, PS3/Dinput and default game mode, which is essentially PC and Android mode. I have an old CRT here, but it is 50 Hz only (I live in the EU, which is 50 Hz for CRTs tvs) and I am not sure if the cable I have is correct. So, I'll pass this anyway. I am also interested in how to count the frames correctly. Do I have to add up the last frame (when the animation starts) into the count? Like this:

          Counter=0.
          (Pause the emulation.)
          Frame 010: Push jump button and the LED goes on.
          (Click to process frame via Frameadvance.)
          Frame 011: Nothing happens.
          (Add 1 to counter.)
          (Click to process frame via Frameadvance.)
          Frame 012: Nothing happens.
          (Add 1 to counter.)
          (Click to process frame via Frameadvance.)
          Frame 013: Start of a jump animation.
          (Don't add anything to counter. Stop now.)

          So after this logic, I would have counted 2 frames of delay. Is that correct?

          📜 RE/SET: 100 SNES Games for your RetroPie, 🎁 Share your hidden gems and insider tips

          1 Reply Last reply Reply Quote 0
          • thelostsoulT
            thelostsoul
            last edited by thelostsoul

            Edit: Ah, just forget this. I tried it with Snes9x 1.54.1 on SMW and it slows down even if Runahead is set to 1, regardless of second instance. Same with Nestopia 1.49 on Mega Man 2. I think, this will not gonna work on the Pi.

            Small comparison with Brunnis from libreto.com. He uses Windows and have a beefy pc and highly optimized settings.

            1. https://forums.libretro.com/t/an-input-lag-investigation/4407/100
              The emulator lag he gets with lr-snes9x on Yoshi's Island is 4 frames and with his fix 3 frames. I did not test it, but on Super Mario World I get around 3 frames too. Doing a full real time test on same emulator, he gets 6 frames and I got 7.2 frames. Not too bad.
            2. https://forums.libretro.com/t/an-input-lag-investigation/4407/169
              In Nestopia on Mega Man 2 he has 4.3 frames and optimized he gets 3.4 frames on a full real time test. On a real NES hardware he gets 2.2 or 1.2 frames (didn't understand). I get 3.8 frames, very close to his Nestopia. Quite good.

            Overall impressive results from this little device. While I don't know if all other games and systems are good as these results, I am still satisfied.


            I am reading threads here and there and consider to enable Runahead at 1 frame on 8 and 16 bit systems. I am confused about the second instance thing. Do you guys use it on Raspberry Pi? And if yes, which systems and what settings? What is the current state? I have an overclocked Pi 3B, which should roughly the same performance as 3B+. Would it be safe at 1 frame Runahead, if 60 fps is maintained all the time or are there any side effects? Or is it something I only should enable for specific games?
            Btw, I will not do the same test again, as I changed everything back to normal; so no comparison.

            📜 RE/SET: 100 SNES Games for your RetroPie, 🎁 Share your hidden gems and insider tips

            1 Reply Last reply Reply Quote 0
            • B
              Brunnis
              last edited by

              I'm sorry to say, but your results appear all over the place and are quite different compared to mine. A few notes:

              First of all, it's very curious that you get such varying results when doing the frame advance tests. I have personally never found the input lag to vary during the same game/scene when using this method. However, it can vary depending on which action you perform (jumping, shooting, etc.), due to how the particular game is coded.

              Second, the real time tests contain some strange results. For example, real time input lag in Mega Man 2 and Battletoads is just marginally worse (0.4-0.8 frames) than when frame advancing. That looks too good. Also, if the test method was reliable, Metroid would be 1 frame faster than SMW, but in your results it's 3 frames faster.

              You should count the first frame when you see animation as well. So you need to add one frame to your real time measurements to get accurate results. I guess this is why your NES results look too good.

              Also, my experience is that you should take ~25 samples to get stable averages.

              Here's the most recent test I've done with Raspberry Pi 3 with RetroPie 4.3: https://forums.libretro.com/t/an-input-lag-investigation/4407/583

              Please note that the results in the graph in that post include the TV's internal lag, which is ~1 frame. So you need to subtract one frame from those results to get the input lag of the systems excluding the display lag (the scan-out time is still included).

              As you can see, on the high performance PC, RetroArch is at 3.6 frames average in Super Mario World and would be at 2.6 frames average in Mega Man 2 (given the same vertical placement of the character as in SMW), since Mega Man 2 has exactly one frame lower built-in lag.

              thelostsoulT 1 Reply Last reply Reply Quote 2
              • thelostsoulT
                thelostsoul @Brunnis
                last edited by thelostsoul

                @Brunnis Hello Brunnis, I am glad you had a quick look at my results. I have high respect for your work.

                I know something must went wrong on my test, as the outcome wasn't consistent and I didn't know the actual delay for input and output devices or even used wrong emulator settings. I expected some sort of delay and just wanted to know how my personal setup works. Currently, there the only way to play on CRT for me is to use that converter.

                Quick test of GAMEPAD and CONVERTER

                I did a quick test on my USB Fightstick on my PC without RetroPie.

                Test 1 does not involve any display. It was just to see how long the LED light on the stick needs to turn on after pressing a button. This is hard to tell, as I can't say for 100% sure when the actual press of button sends a signal. At least the converter, monitor and usb aren't involved here.
                Result: 1 or 2 frames of 240 fps, which translates to 0.25 to 0.5 frames at 60 fps (right?).

                For Test 2 I used my daily Linux PC with 144 Hz HDMI monitor (without converter). jstest-gtk on Ubuntu was used to visualize a press button on display.
                Result: I think 4 frames of 240 fps footage in addition after the LED is lighting up. That translates to 1 frame delay at 60 fps.

                At Test 3 I connected same PC to the CRT PC monitor via HDMI to VGA converter. Same jstest-gtk was used as previous test.
                Result: 6 or 7 frames at 240 fps footage after the LED is lighting up. Which translates to about 1.5 or 1.75 frames at 60 fps.

                Conclusion:

                • The arcade stick seems to add 1 or 1.5 frame delay on its own, which would mean 16.7ms or 25ms.
                • If Test 2 and 3 are compared, the converter seems to add 1.5 or 1.75 frame delay on its own, which would mean 25ms or 29.2 ms.
                • So, both together are in total adding up approx. about 3 frames or 50 ms latency.

                Do you think the autofire/turbo-2 function of arcade stick could send too many key press events, so the emulator or driver gets too busy? Could this have an effect? What do you think about all of this? Does these sound reasonable?

                And, should I also just copy the posting to Reddit?

                📜 RE/SET: 100 SNES Games for your RetroPie, 🎁 Share your hidden gems and insider tips

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post

                Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

                Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.