Let's talk about Latency (and Game Mode)

Hello guys, it’s me again, looking for more answers.

I’m playing some old games as always, but in one of those games, I had a difficult boss fight, and realized how much important is Latency when the gameplay requires precise but fast moviments.

Now I’m here, looking the Latency options, trying to figure out how to extract the most benefit of it without introducing any gameplay issues like stuttering, crackling, lag, you name it.

I searched a lot for some guide or document, but didn’t find anything that gave me all the information I’m looking for, I’m not satisfied with specific threads that talks about toggle one option or another, I want to know about it all, and the own Retroarch explation only give me little info but not a full understanding of toggling ON/OFF or set a number for that option.

If someone knows where can I find a complete guide, please, share to me.

One more thing, the most interesting option, the last one, the “Game Mode” if toggled off, trying to toggle it ON results in nothing, and shows the text below:

“Failed to enter GameMode - ensure GameMode daemon is installed/r…” I can’t see the full text.

Is Game Mode supported on Android Devices?

3 Likes

Hello @JulianoFdeS .

The optimal way to improve latency is with Run-Ahead. It is activated in the menu “Settings»Latency” default is 1, it can go up depending on your needs. Or with the game loaded, activate the menu and a little below you have the Latency option.

I understand that Gamemode is a feature of Linux to improve CPU load.

3 Likes

Run ahead only won’t do miracles. Frame delay is at least equally important, unless you have a VRR monitor (Gsync / Freesync) in which case frame delay is irrelevant.

3 Likes

Please see the following post.

After setting up Run Ahead, for Frame Delay, I increase it until I start hearing audio issues for example crackling, garbling or audio sync issues. Then I lower it until all audio issues disappear. I then enable Auto Frame Delay and save everything as a Core Override.

Others recommend that you use Game Overrides though as latency differs by game. I just prefer to work with the lowest common denominator for all games within a particular core.

If for some reason a Core or game can’t use Run Ahead, I just use Frame Delay alone.

I mostly play on a TV and use my TV’s game mode exclusively.

https://docs.libretro.com/guides/runahead/

2 Likes

Good to know that Gamemode is not available for Android, it’s weird that this feature still appears in Android devices, anyway, I tried Run-Ahead 1 but it added a bit of crackling, so I turned it off and now I’m gaming at full speed again.

1 Like

If you’re using the default “gl” driver, the biggest improvement you can get is enabling hard GPU sync, preferably with 0 frames, but even 1 frame is a big improvement. Vulkan gets this benefit for “free” but you may still improve it by reducing the max swapchain images.

3 Likes

If you modified the other latency options, return them to their original value, they may be short-circuiting. Also try disabling the second instance and turn off the gamemode. And as hunter pointed out, use Vulkan if it supports it, it is much faster.

2 Likes

By the way, what is the difference between gl and Vulkan drivers? How do I know if some device supports those drivers before buy it? usually I see a lot of people that says Vulkan is the best choice.

I toggled FPS ON to watch it in-game screen, I took a time to see the main MIN and MAX frames per seconds with everything disabled, then I toggled on and as much it didn’t drop my fps enough to create an issue I let it ON, this is the setting I’m currently using in my device: Hard GPU Sync [ON] Hard GPU Sync Frames [3] (I don’t know if higher is better, I would like to know] Frame Delay [1] (higher values than 1 make it stutter) Automatic Frame Delay [ON] (does it overrides the Frame Delay value I set previously?) Audio Latency 128 (Defaut value, I tried lower values, it make the audio crackling, but this wasn’t a big deal to me and I back it to 128 again) Polling Behavior [Late] (I didn’t touched this, as I didn’t understand what this does or in what case I would change this option) Input Block Timeout [1-Default] (does it make any difference with hardware buttons?) Run-Ahead to Reducy Latency [OFF] (even if this was the only option ON, it still would cause gameplay issues) Game Mode [Off] (can’t turn it ON anyway). Didn’t tried the Vulkan driver yet, this is currently in gl driver, and seems that improved, I can do more fast tricks in my games now, but I still want to know more deep about these settings, and how can I improve it to the max my device can supports. I’m going to see if it supports Vulkan, if positive, I’ll try some settings.

  • ‘gl’ is an OpenGL 2.0+ driver, when used with a version above 3.0 it’s called OpenGL Compatibility and can support up to OpenGL 4.6, but some GPU drivers don’t have that OpenGL Compatibility mode.
  • ‘glcore’ is an OpenGL 3.1+ driver, it’s also called OpenGL Core, it supports up to OpenGL 4.6.
  • vukan’ is a new api, faster and more accurate, but it is not compatible with many older hardware.

to find out if it is compatible, activate it in the settings menu, and try a game. or search for it on the internet by the model of your phone.


Each game has delay frames, from the time you press the button until you do the action. Sonic has 1, Mario World has 2. Run-Ahead eliminates those frames.

Every game is different, that’s why @Cyber told you how to know how many frames they are. I have also seen some videos on indicating how.

3 Likes

I saved Vulkan in Driver settings and closed the emulator, it stopped to answer, I had to delete Android\data\com.retroarch.aarch64 to make it work again, seems that I have to config everything from zero but at least now I know it doesn’t work. I would like to know how I would figure out that this driver won’t work in my device before test/buy it, or if it works only in new devices after some year or OS version. How you would figure out if it supports Vulkan if all you have is only the hardware settings in manufacturer page and no one tried the device yet?

I learned a lot, but I still want to know some answers that I asked in my previous post, then I’ll be satisfied, I guess.

1 Like

I have no idea, I don’t use Android, but with a quick search on the internet, I got something that can help you.

https://developer.android.com/ndk/guides/graphics/getting-started

apkpure.com/vulkan-android-test

2 Likes

so…search for the model cpu/gpu that your hardware have and you find vulkan supports or not… example ARM Mali-G710 MP10 VULKAN…YES

2 Likes

Thanks, this list will be useful next time I went to buy a new device.

Thank you as well, I’m kinda dummy for driver stuff so it’s good to know this info.

There is little more I can do, I don’t know Android. Maybe a member with experience can help you, although that is out of RetroArch, it seems to me that it is better to look in an android forum.

Check this out…

1 Like

On smartphones, the most input lag you get, will be from the actual touch screen. A normal smartphone with 60 hz display, will have ~ 90 - 100 ms of touch latency (not to be mistaken with sample rate or sliding rate). Also, do not believe those 1 ms or 8 ms of screen latency, that some advertise. They make you believe it’s related to the touch, but it’s not, it’s related to the change in colours

So, let’s take Street Fighter 2, which has 2 frames of lag in FBNeo. On a typical smartphone you will play it at ~ 8 - 9 total frames of lag. Very playable, but noticeably floaty.

So, as much as you can do inside Retroarch, you can not really compensate for the touchscreen latency.

I recommed a gaming oriented smartphone. I own a Rog 3 and the screen latency is ~ 35 ms in 160 hz, and this obviously makes a huge difference in the overall input lag.

1 Like

Use Retroarch on a low latency OS config, like KMS/DRM on GNU/Linux, and use max_swapchains=2 and Vulkan if possible.

Other than that, you’ll be wasting CPU because your base system won’t give good lag results no matter what you set in RetroArch.

Why people use stinky Android to emulate, and at the same time they pretend to have low input lag, is something that defies logic.

2 Likes

Your comment is pretty interesting! I want to say some stuff!

My Android is the cheap “handhelded” Powkiddy x18 (32GB) gaming oriented device, but I know it is nothing compared with yours Rog 3 (Congratulation for it, unfortunately, this product is too much expensive in my country, it’s equal 3 times my salary, even my notebook that I’m using to write this was cheaper than this phone)

This is the part I most find interesting, but I fear that I didn’t had fully understanded it, could you give me a little more detail? How does colors affect screen latency? This have nothing to do with retroarch?

I’m already using a better setup than the one I had used previously the creation of this thread, now I’m getting fast responses! but this max_swapchains=2 is an option available for GL? I can’t see anywhere, maybe it’s Vulkan only, and unfortunately my device can’t use it.

I can swear my performance got something better after enabling HARD GPU SYNC to 0 and FRAME DELAY to 1.

Does Powkiddy x18 (32GB) is considered stinky for you? well, I paid this device to compensate the nostalgia I had for gameboy, but nowadays, at least where I do live, this is considered a collector’s product, and too much scarce, at the point I can find them at the double the cost I paid in my Powkiddy, needless to say that I would use it only to play it’s own games, on the other hand, with my Powkiddy I have a lot of options, can emulate almost everything from GB until PS1/Dreamcast (some games are hit or miss for them) and I can also map the handheld buttons on the touchscreen to use it as well for Android games, so it doesn’t looks like a bad deal at all to me.

I was just looking forward info about what could be the best latency settings for it, and now I have less problem than before. But this thread can still be useful for learning stuff, and I hope people can use it as reference to solve their own problems.

I was reffering to the time it takes the screen to display the change in colour/grading. For example, on some displays it takes 1 ms to go from white to slight grey, on others it takes more ms. It’s a latency measurement, but not related to touch, just the speed of the display in terms of colours. But they are using this to suggest it’s related to touch.