Runahead in favour of Linux compared to Windows?

RetroArch Linux devices
#1

I see a big difference between the two platforms when it comes to runahead. I have OpenSUSE TW/W10 dual boot desktop and a Linux Mint 22 laptop. On the laptop , gamemode driver came preinstalled as it is activated on Retroarch. On TW I had to install it manually.

I experimented with various cores and noticed that the Linux version of Retroarch could play games with up to 3 run-ahead frames without issues. I’d say 3 was the limit before breaks start to occur. However on Windows 10 with Genesis Plus GX core for example, 3 frames run-ahead make the games unplayable. 1 was really the limit.

Similarly on MAME, Linux can reach up to 2 frames runahead before breaks, when compared to 1 frame run-ahead on Windows.

Is it because of the different API on Linux that is less demanding than in the Windows port?

I see similar difference in another emulator (Ares) but there I was informed that the Linux API is much less demanding

#2

When you say “breaks,” do you mean starts losing frames of animation? if so, that should be consistent across platforms, since it’s based on the games’ own internal latency.

#3

MAME “breaks” as soon as you enable runahead; there’s an hiccup when you hit a button, breaking any smooth scrolling.
Their savestates are usually not fast and reliable enough for it.

#4

I notice a difference in Genesis Plus GX core, on game Acme Allstars. On Linux motion is smooth with 3 frames run-ahead. On Windows it is unplayable at 3 and even at 1 you get occasional breaks, needing to disable it. There is parity with SNES9X core.

#5

I played Shinobi 1 and it tolerates up to 1 frame runahead for smooth motion. 2 frames you notice a barely noticable break when turning left or right. But at 3 it gets unplayable.

Am not sure if it matters that monitor is Gsync and kinda compensates for it

#6

3 seems like a lot of frames for a Genesis/MD game. How are you coming up with these numbers? are you doing the frame advance method?

#7

If you just want to mitigate input lag, then you’d better be served by changing the video driver to vulkan and lowering the max swapchain images to value 2. Run-ahead messes with the game’s intrinsic internal lag, which varies from title to title, and you can achieve latency potentially lower than the original console, so only use it if that’s exactly what you want. At any rate, you cannot set a number of frames higher than the internal lag (which can be determined by the method hunterk suggested). If you don’t want to bother, just set value 1 for everything, since it’s safe (though not necessarily optimal).

1 Like
#8

I only activated the runahead option (not the pre-emptive frames one) and set it to 3.

#9

Yes but why do you set it at 3 frames? That’s too much.

I tried Shinobi on GenesisPusGX in Windows. Using the frame advance method it reveals that the game has 2 frames of lag when you jump or shoot as the sprite reacts on the third frame. So, setting it to 3 frames is going to cause problems because you lose 1 active frame. Which is most likely true for most Genesis games as i don’t think many games have more than 2 frames of lag on that system. Sonic, for instance, only has 1 frame of lag on my setup.

If i set it to 2 frames Shinobi runs fine for me without breaks and zero frames of lag. But personally i don’t like to “hit the limit”, i always leave one frame, just to be safe. So in this game i would just put 1 frame in the setting.

The fact that the game doesn’t break on Linux for you when you put 3 frames in the setting most likely means it has more input lag than it has on Windows. So if on Linux the game has 3 frames of lag instead of 2, putting 3 frames on the setting is going to work OK since you still don’t hit any active frames.

If that’s the case that means Windows is better than Linux, not worse. You actually want the game to break when you set too many frames of frame advance, because that means your setup produces lower input lag.

Anyway, 3 frames is too much for Genesis 60fps games. It’s too much for most 8/16 bit games. 3 frames should only be fine on 30fps games or games that are notoriously slow, like the Mortal Kombat games on the SNES.

Always use the frame advance trick for each game individually, to see how many frames of lag it has, before setting that number in the setting.

#10

I meant Shinobi on MAME, where 2 frames are the limit,both on Windows and Linux. So no difference there. Setting is Run-ahead to reduce latency, use second instance to run ahead, max swap chain 3, audio latency&input 64. The game I was referring to was Acme Allstars, a toon soccer game where many sprites move at once in 8 directions so it is easier to spot the breaks. Some Saturn games, eg Cotton 2,face issues even at 1,so it is better deactivated.

But in that particular game there is a stark contrast between Windows and Linux. On Windows it is better to deactivate run ahead completely. Not so on Linux. because I tried other md games and run ahead performance was the same. But this particular game benefits more on Linux. Probably a build source code omission? So I wonder whether there are similar cases where Windows or Linux is better in that regard.

#11

I just tested Shinobi on MAME in Windows and more or less the same applies to this game too.

The game only has 1 frame of lag. So the maximum you should set is 1 frame. I did this and the game runs without issues.

Also tried the Acme Tiny Toons game on GenesisPlusGX. It’s hard to determine how many frames of lag the game has because of all the havoc, but i’m pretty sure it only has 1. So, if you set it to 2 or 3 you are bound to have issues.

Though, when i set it to 2 or 3, i didn’t notice any major issues other than some stuttering maybe, which i’m not sure if it’s normal or not. But either way, you are not supposed to set more frames than the game actually has.

You still don’t provide enough info about the difference between Windows and Linux. What do you mean by “it benefits more on Linux”? What exactly are you looking at? What do the issues look like? Do you measure how many frames of lag the games have using frame advance? Do both Windows and Linux give you the same numbers?

#12

By the way, can’t latency settings be saved separately, like shader and core options? For now, they always need an override if you don’t want global settings. Just asking out of curiosity, as there’s some confusion about some settings being able to be saved separately, whilst others need to be bundled inside an override.

#13

I am not delved into technical details. I recorded the game on phone. Here is the Windows 10 version. You can see towards the last 5-6 second that a teleport occured and sprites disappered for a while. Same issue on the laptop with the Mint machine and CRT VGA and Switchres.

While here is the Linux version on same machine (dual boot, OpenSUSE 15.6 TW)

Same stage. There is not any sort of teleport like on Windows. Both with runahead frames to 3. I played even after the recording and no teleport occured.The other games perform the same on both OS.

I guess the core omitted to utilise the game for Windows or else I do not see any other explanation

#14

No, there’s no such thing. And i already offered you another explanation.

I posted this many times already but you continue to ignore me for some reason: Setting 3 frames of lag is way too high. That “teleport” you saw is a typical artifact of going higher than the game’s actual input lag frames. And you are setting it 2 frames more than you should.

Again, when you set the run ahead frames more than the game actually has, you are going to have a bad time. And that’s exactly what happens in Tiny Toons.

So now you will ask: Why this problem doesn’t exist on Linux?"

Well, i don’t have Linux so i can’t know. I can only speak for Windows. But i can tell you this: There is no scenario where setting 3 frames of Run Ahead is a good thing for this game in GenesisPlusGX. If it seems to work there’s something else wrong with your system. The behavior you get in Windows is the correct one.

#15

but the thing is that this teleport happens only with that specific game so far. There is parity with the other ROMs I tried and they teleport on both the same. Though in my case there is the advantage that I use a light windows manager (LXQT) when compared to the bloated mess of Windows 10, so this might contribute to some less latency, especially with Gsync active. This manager has also the best Gsync compatibility, as all others failed to activate it on Retroarch. So yes, some quirks can influence those minor details.

Also there are cases where Linux benefits some emulators. Eg Ares libco Win64 Abi vs SysV Abi, where the former requires much more code and hence more demanding runahead. But this is not the case with Retroarch.

#16

This game seems to be able to hide the run ahead artifacts better than other games. Not sure why. I played for a while and i don’t think i even got such a teleport but i could be wrong. Whatever though, it doesn’t matter. 3 frames or run ahead is bad.

It’s not like i tested many games at that high Run Ahead setting, there is no point. Genesis games on GenesisPlusGX only have 1 or 2 lag frames on average. There are probably only a handful that have 3 though i haven’t found any yet.

1 frame of Run Ahead is usually safe for any system but keep in mind some games may even have zero frames (like Bubble Bobble in MAME/FBNeo for instance). So there is no safe number that can work for all games. You need to find how many frames a game has and put the correct number for that game.

Also, setting it too high doesn’t give you any benefit if that’s what you are after. If a game has 1 frame of lag setting it to 1 or 3 will make no difference in lag improvement. It will only make it act weird if you set it too high.

1 Like