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
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.
A visible change in pixel color is much faster. The full transition takes more time, but a visible change happens much quicker. This is why pixel response doesn’t have much to do with input latency. It affects motion ghosting though.
1 Like
Why people use stinky Android to emulate, and at the same time they pretend to have low input lag, is something that defies logic.
I agree so much with you. I just got a Steam Deck and the latency is night and day compared to my old GPD XD Plus running Android.
Can you please elaborate on this?
What makes you think VRR makes frame delay irrelevant?
Frame delay supposedly only reduces Vsync lag. When your framerate is in VRR range (anything below your max refresh rate) Vsync isn’t active, so frame delay should be irrelevant. Since most emulated games are 60 FPS or below (Wonderswan is like 75) you should always be in VRR range on a 120hz or higher display.
1 Like
That is true for most standard games, but not for RetroArch.
While on a normal game, the frame is processed and then displayed as fast as possible, on RetroArch you poll input and process the frame right after the previous frame is displayed, and then you need to wait for the next emulated game Vsync. This wait is the input lag that can be reduced by using frame delay.
Even if VRR is active, RetroArch is artificially limiting the framerate to the the emulated game’s framerate. This means that (with frame delay disabled) the input is polled as soon as the previous frame was scanned out, meaning the input lag is theoretically the same as without VRR.
EDIT: Apparently I was wrong. @RealNC explains it on the posts below.
At least that’s how I think things happen on RetroArch. But please correct me if I’m wrong.
Has anyone measured this before? I did measurements here, but I have yet to test with VRR on:
The frame limiting happens before input polling, so frame delay does indeed nothing useful with VRR.
Frame delay is a method to bring input polling closer to the vblank interval. You can’t move the vblank, so you have to move the input polling.
With VRR, you do move the vblank. It’s not necessary to move the input polling. RetroArch waits (frame limit requested by core,) then polls input, then runs the core loop. When the core presents the frame, that’s when the vblank happens. Frame delay has no place at all here.
2 Likes