Can I play on Retroarch and use runahead frames to help reduce the input delay?

After lengthy discussion, we have decided that runahead is banned as it can convey an advantage over console, as seen here. Note that frame delay is set to '6' in this situation, so higher values could lower the average input delay difference between emu and console as shown previously.

The main rules posts has been updated to reflect the leaderboard discussions

Can this be demonstrated that it has an advantage in a competitive setting?

It has been demonstrated that, on average, there can be less than half a frame difference of input delay between retroarch and console. Retroarch having less than half a frame more input delay than console. Runahead 1 should lower the input delay by about a frame, resulting in less input delay than console.

Show me in a way that proves an advantage in real time Yoshi's Island speedruns. Let me see this

I have deductively in the past couple posts, I can lay it out more clearly:

1. Retroarch can have, on average, less than half of a frame more input delay than console (premise 1) source

2. Runahead = 1 would reduce input delay by 1 frame (premise 2)

3. Therefore, Retroarch with runahead = 1 can have, on average, more than half of a frame less input delay than console (conclusion)

4. Emulators or emulator features that can result in an advantage over console, during a speedrun, are not allowed (axiom)

5. Retroarch with runahead = 1 can have, on average, more than half of a frame less input delay than console (premise)

6. Therefore, Retroarch with runahead = 1 can result in an advantage over console, and is not allowed (conclusion)

Can you show me what real world tests have been done by the moderation team?

nope

How come?

Because a real world test with YI has already been done, I've linked it twice.

Am I correct to infer that you nor anyone else on the moderation side has bothered to play for themself?

As far as I know, people in the community have played the game using retroarch with and without runahead.

Has anyone on the moderation team personally played with runahead frames to evaluate its advantage? It's a yes or no question

to evaluate any possible advantage, nope

Having played on this myself and adjusting the runahead frames to a number that does not adversely affect the game, runahead frames gives no competitive advantage to someone running stock emulator or console in terms of input lag. It is in fact still worse than a console, just not as bad.

I think had anyone truly played this instead of looking at someone else's graphs you would have the same findings.

But fear not because I am not only up to the daunting task of opening an emulator, I will also return with my own real test that would be meaningful to speedrunners. I have not done my own yet, but I am confident this will back up my own claim.

I would also implore the moderation team to actively engage in their own independant, real world testing before coming to a conclusion.

Alright so you haven't disagreed with the any of the reasoning I laid out.

While more data is always nice to have, additional tests are very unlikely to be relevant. The only way they may become relevant is if someone raises a meaningful methodological flaw or another issue with the input delay test that has been linked.

One of my issues with those graphs is how the delay is shown as a measurement of frames. This game only polls inputs once per 60th second. Any inputs pressed midway through a frames, so like 8 milliseconds, would be polled on the next available frame and shown the next after that. a "half frame" cannot exist. its just not a thing. It should be counted, in frames, from 0 and up

I've also done a test to show the amount of time it takes for my screen to be refreshed. I use the R button for it's low travel time to bottoming out and the map screen arrow for being something that displays next frame upon a press.

the results, recorded at 120fps: CRT: 4 frames @ 120fps EMU + runahead: 6 to 8 frames @ 120fps

What can be made of this?

[quote]Any inputs pressed midway through a frames, so like 8 milliseconds, would be polled on the next available frame and shown the next after that. a "half frame" cannot exist. its just not a thing. It should be counted, in frames, from 0 and up[/quote]I disagree but I'll adjust the data as you suggested. After rounding up all the decimals for each trial and averaging: Retroarch: 31 4 frames, 8 5 frames. 164 / 39 = 4.2 frames Console: 3 3 frames, 31 4 frames, 5 5 frames. 158 / 39 = 4.05 frames

After truncating decimals for each trial and averaging: Retroarch: 18 3 frames, 21 4 frames. 138 / 39 = 3.54 frames Console: 3 2 frames, 31 3 frames, 5 4 frames. 119 / 39 = 3.05 frames

Applying runahead 1 would result in less input delay for retroarch regardless of if you round up, truncate, or preserve decimals.

[quote]What can be made of this?[/quote]It is possible something in your setup is introducing more input delay.

I probably would test this myself for curiosity sake, but I don't have a 120fps+ camera.

Understandable. so I did it in 60fps.

CRT: 2 frames @ 60fps EMU + runahead: 3-6 frames @ 60fps

I really think more people should play this and understand that input lag is still present.