Let's talk about Latency (and Game Mode)

RetroArch General
,
#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
#39

Learned a lot with that! I never imagined some games would input artificial latency to make them harder. I guess genres like FPS and Racing that are genres where Milliseconds is everything can extract the best benefit of it. So, the best setup would be an 1ms monitor, mechanical keyboard/wired gamepad and a powerful - compatible with vulcan drivers - hardware, to turn ON the latency settings to the max, without getting any stutter, can be expensive but probably can enhance some hard games experience to the max and making them less frustrating. The only sad part of it is that this isn’t something a portable emulating handheld as my PowKiddy can do, but now I know that I don’t suck in some hard games that are only harder because I’m not playing them in real hardware, so I can try those games again later after getting an better hardware setup in my hands.

2 Likes
#40

I wouldn’t say the developers put the latency there intentionally. I believe it was related to technical limitations.

And yes, playing a game with lower latency than the original hardware will make it easier. You can consider that cheating, I guess, as you’re essentially altering the original game somewhat. But that depends on how strict you wanna be about it.
I personally don’t use it because I want to feel the same difficulty as when I originally played the game, but using runnahead to offset the software latency and make it closer to real hardware might be a valid usage as hunterk said.

Runahead is amazing and was a groundbreaking addition to RetroArch, but it doesn’t come without some caveats.
Not all games have the same ammount of frames of latency, so you need to configure them individually. And to make matters worse, the same game might have different frames of latency on different areas (such as gameplay vs menus), which might introduce runahead stutters.
Also, depending on the core in use, it might be very performance intensive.

2 Likes
#41

How does run ahead work regarding save states? Does it use the hdd/ssd in any way or is everything done in RAM?

1 Like
#42

Everything stays in RAM.

1 Like
#43

No. If someone would use that in a run, that run can only be classified as tool-assisted.

2 Likes
#44

Let’s see if I understood what is runahead correctly: the game on the original console plugged in a real CRT tv would draw the image instantly, but when it comes to computer, all depends on how much powerful the hardware is to render the image the software sent to it before this is sent to display, so, the runahead uses savestate to save the game in the exactly frame the player is looking at, but NOT the actual frame he is because the display is currently receiving the rendering from the hardware and didn’t displayed to monitor yet, so it back some miliseconds to the past (saved on RAM memory) to let the player’s input to work on that very moment. This is it?

#45

I’m a big fan of some hard games, but sometimes I feel the game was made for a better hardware than the console it was released, and I wonder if latency was added accidentaly in this transition, so maybe the better the latency, more like developer intended, so I guess the best is to set runahead in every game you can, but can’t let it stutter, or it will ruin the experience. I like games as hard as Contra and F-Zero, and I can swear lot of times that I pressed the button at the time to dodge something but I get dead anyways, I never stopped playing games so this can’t be lack of practing, but on real console I was better, emulating it, on the other hand, I feel more depressed in those hard games, other games like Mario or Donkey Kong is the same experience it was back them because they are not that intensive (unless you want to play a hard rom hack).

But now I’m interested in something: how do you set your runeahead settings to make it exactly the same as the original hardware? Not better, neither worse, but exactly the same latency, for every game?

#46

The way it works is: states are being made constantly and held in memory, and any time you change your inputs (e.g., you press a button or let go of a button that’s currently held), it rolls back X frames (where X is your runahead value) and applies your input change in the past and then emulates the frames between then and the current frame with your input change applied, all within the time it takes to show the next frame.

So, depending on your perspective, it’s either showing you the future based on your current inputs (i.e., running ahead) or sending your inputs into the past and then retroactively applying them to the present.

As long as the runahead frames do not exceed the game’s internal latency, you will not see any of this. It all happens invisibly, under the hood. However, if you exceed the game’s internal latency, you will see rollback artifacts in the form of skipped animation frames, choppy motion, etc., just like you would see during rollback-based netplay on a dodgy connection.

To make the latency match the original hardware, you first need to measure the total latency of the original hardware setup (we’ll call this A), then measure the total latency of your emulation setup (we’ll call this B). Subtract A from B and the remainder is what you need to shave off, either with runahead or whatever other mitigation strategy (frame delay, hard gpu sync, etc). Since latency is experienced as a total of all contributing factors, reducing it via any of the available means feels the same. That is, you reduce the time between your finger pressing a button and your eyeballs seeing the effects produced on-screen.

3 Likes
#47

In addition to everything hunterk said, you can check this too:
https://docs.libretro.com/guides/runahead/

It teaches you the correct way to find how many frames of internal latency a game has.

3 Likes
#48

An interesting game to try out and totally feel the difference is King of Dragons for the arcade, it probably has an intended input delay to give your character more “weight”. In my current setup, it’s running on Vulkan, max swapchains 2, if runahead is OFF, the character will react in the 4th frame (tested using the frame-to-frame function with the K key, the core used is FBNEO since MAME doesn’t support runahead so far, but still have even less natural input latency in some cases. Turning runhead and setting it to 3 makes the character react in the next frame, the difference is huge, but Capcom games often have this delay, maybe one frame less on real hardware, which I suppose is intended. If you run this test yourself, I’d say that that once you get used to the more responsive controls these functions provide, it will be a bit hard to play like we used to back then, or even on older hardware that can’t afford such features.

1 Like