Let's talk about Latency (and Game Mode)

RetroArch General
,
#19

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.

#20

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.

#21

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
#22

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.

#23

Can you please elaborate on this?
What makes you think VRR makes frame delay irrelevant?

#24

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
Wiser monitor choice for RetroArch Shaders: size & resolution
#25

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:

#26

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
Wiser monitor choice for RetroArch Shaders: size & resolution
#27

So you mean the sequence is the following?

  1. scan-out previous frame
  2. wait for next frame time
  3. poll input and process frame
  4. immediately scan-out current frame

If that’s the case, won’t this result in uneven frame pacing? Step 3 will not always finish at the same time. Is this the reason why I observe slightly uneven panning on the 240p test suit with VRR enabled?

EDIT: Sorry, I made the sequence before your edit. I believe we’re describing the same sequence, yeah.

#28

Yes, that’s the sequence. But it’s important to understand that the “wait for next frame time” step takes into account how long the previous frame took. On a 10ms interval (100FPS), if the core loop took 3ms to present a frame, RetroArch will wait for 7ms afterwards, not 10. Otherwise, you would indeed get uneven pacing (and FPS would be off by a lot.) So when the core’s frame times vary, you still get correct frame pacing.

1 Like
#29

This is very interesting! I had no idea the VRR cycle on RetroArch was like this.

Yeah, it certainly must take into the account the time taken to process the previous frame. What you say makes sense.

But still, frame pacing cannot be as perfect this way, compared to the standard VSync. The previous frame processing time will never be the exact same as the next frame. There will always be a variation in frame times, even if very small.
I believe this is observable on the grid scroll test on the 240p test suit.

But I also believe this can have a relatively simple fix. Why don’t we pad an elastic few microseconds extra to the processing time so that every frame takes the exact same time to be ready? This would give us perfect frame pacing for a negligible amount of input lag.

#30

I noticed that the frame delay settings are still available and have an effect even when VRR is turned on on RetroArch. When setting the frame delay too high, there is still slowdown, and if the Auto frame delay setting is enabled, it still adjusts it.

Shouldn’t these settings be completely ignored if VRR is being used?

#31

VRR is an external thing. RA has no control over it and doesn’t even know whether it’s active or not.

#32

I meant when VRR is turned on in the RetroArch settings. RetroArch is at least aware of the intention of the user to use VRR.
In this situation. What do the frame delay settings do in the VRR loop?

#33

Nice discussion here, it gots into something I had no knowledge enough to understand but still is nice to have it here for future reading.

I would like to know if someone is able to write the best settings ever to enable/disable/modify in Latency and how much powerful the hardware must be to run it at it’s full glory.

1 Like
#34

@JulianoFdeS I just make sure I’m running in exclusive fullscreen mode and set max swapchains to 2. Then I check on the console log that the 2 swapchains are in fact in use (some graphics drivers might only provide more than 2). Oh, and make sure threaded video is turned off (but that’s the default on PC already).

Other than that, you can try to increase frame delay to as high as your computer allows. The faster your hardware, the faster the frame gets ready and the higher you’ll be able to push frame delay. And don’t fret about 2 or 3ms minuscule differences.

Lastly, you can use run-ahead, but that’s a different topic because you’re actually running ahead of real hardware.

3 Likes
#35

Lastly, you can use run-ahead, but that’s a different topic because you’re actually running ahead of real hardware.

Wait, this means that a powerful hardware can use this feature to run a game with less latency than the real console itself?

1 Like
#36

yep. it uses savestate trickery to make it happen, but when done correctly, it’s transparent to the user.

3 Likes
#37

yep. it uses savestate trickery to make it happen, but when done correctly, it’s transparent to the user.

Does it make some games inteded to be hard more easier? Would this be considered cheating? Does speedrunners use this feature?

#38

If artificial latency is part of the difficulty design, yeah. I think a notable shmup has something like 8 frames of latency and plays very differently if you shave off, say, 4 of those frames.

AFAIK, speedrunning rules are pretty strict about this sort of thing and encourage using original hardware for “official” runs. It’s ultimately not really any different from existing tool-assisted cheating (such as playing back a recording and just moving your hands in time, etc.)

However, people who want to be able to practice on an emulator–with all of its inherent conveniences, such as savestates–with a real-hardware-like latency experience will sometimes use runahead to tune their setup to match an otherwise unattainable-with-software level of latency.

2 Likes