Stumbled upon this thread via reddit. Some perspective from a community that's done quite a bit of research on this:

Retroarch is as accurate as the core you choose is, UNTIL you turn on RunAhead. RunAhead is an optional feature that uses multiple concurrent cores, savestates and reloads to reduce input delay to sub-console levels. Console, by the by, does have input delay, usually 1-3 frames on any given game. Multiple communities, ALTTP and Super Metroid for instance, have done significant testing and found RetroArch to be perfectly fine, but have outright banned RunAhead.

If you are at all concerned about the speeds, I suggest you simply require RetroArch runs to include framecount and FPS display, as well as specifically approved cores (FCEUX in your case).

I'm happy to provide as much additional insight as I can on this topic via discord or otherwise.

I have made a lot of tests today and thing I have noticed that 'overclocking' option makes the most influence on lag reduction, if it is off gameplay seems the same a bit laggy like on console. Run ahead seems not that influent but maybe it has some optimization too. But even if both that featured are off retroarch seems much better to play than pure nestopia I tried.

Ok yeah, that overclock feature also has to go. It is specific to the FCEUX core and will eliminate lag frames. https://docs.libretro.com/library/fceumm/

Overclocking [fceumm_overclocking] (disabled|2x-Postrender|2x-VBlank) Overclocks the NES using PPU method to minimize ingame slowdowns of some games. Contra Force needs VBlank mode (stage 3 slowdowns). Choose which ever minimizes slowdowns without image distortion

The goal, as a conscientious emulator player, should be to attempt to achieve as level a playing field with original hardware as possible without giving yourself an example. This particular feature, however, would definitely surpass console, and should be avoided.

@screevo Just curious if anyone (speedrunning related) has done any direct comparisons with runahead using a high FPS camera recording the input and screen etc and when it shows on screen between console and retroarch with runahead? Not with the target of being ahead of console, but matching it.

Bottom line (for me) is there are multiple factors that affect input latency on an emulator, which can even be down to which controller or monitor you choose to use, for controllers, bluetooth adds more than USB, and USB still isn't perfect unless you use something like a blissbox to remove that,.

We did have a console runner who used a blissbox with retroarch as well and deemed that 1 frame runahead was close to actual console but still not quite as responsive. Not 100% sure of their tests, but others in the community who have done frame perfect tricks on both console and with retroarch and 1 frame runahead and have come to the same conclusion. Not scientific by any means, but hasn't caused any reason for concern thus far.

Given that this appears to be down to an FCEU overclocking option, it's clear that Retroarch's options were not the cause of the speed difference anyway, so hopefully this matter can be considered resolved :)

RunAhead literally uses savestates and rewind to eliminate the native input delay on console. Retroarch's authors themselves say "This feature is not hardware accurate." Because of those facts, It didn't matter to us in the ALTTP community to test anything further; it's emulator specific functionality intended to provide an advantage over console so that feature was banned.

There are plenty of other settings that can be tweaked to get RetroArch to run exactly at 60.099 FPS like a NES or SNES, but RunAhead should not be touched by any serious speedrunner. FrameDelay is the feature you want to use to reduce emulator input delay, but frame-delay is resource-intensive.

I'm not sure why you are talking about FPS with regards to RunAhead, RunAhead has zero impact on fps, if RunAhead causes a lag frame to be jumped over, it is still classed as a frame, so the fps remains unchanged.

Also, there are only 2 ways of being able to get RetroArch to run at exactly 60.099fps, turn vsync off and audio sync on, and get tearing (or dupe frame if sub-60fps core). With vsync turned off you also lose the ability for frame delay (since it uses vsync to time the delay). With vsync on; retroarch will deviate from 60.099fps dependant on other settings to ensure vsync is hit (or attempted to). The other option is "Sync to exact content frame rate" which can only be used with GSync/FreeSync monitors, where it will run at what fps the core has stipulated.

Showing the FPS display in Retroarch is a fairly pointless endeavour as well, as when you have exact content framerate on and audio sync off, it's a static figure (the core's desired fps, which in the case for fceu with an NTSC game is 1008307711.0/16777215.0 i.e. 60.0998265207, but obviously retroarch truncates/rounds the figure for the display). And when exact content frame rate isn't used, it's based on an average of Retroarch's attempts to try to get vsync/DRC/audio sync etc at a consistent point. There is very little you can deliberately do to get the FPS higher without it being noticeable, there are some things that will have a minor effect on it, like a monitor refresh rate that isn't 60hz or 120hz.

Frame Delay is no more resource intensive than it set to 0. It just gives the core less time to generate the frame, if it doesn't generate it in time then the frame is skipped, the core still processes it in the same time regardless.

I'll say again; a few of our (apparently "non-serious") speedrunners did like for like testing for input lag between real console and retroarch with different runahead settings to come to the conclusion that RunAhead of 1 for genesis provided the closest match for input delay between the two, and even then it still didn't provide an advantage to emulator.

Also, I should point out that Hardcore mode in Retroarch which disables emulator advantage features, like save states, rewind, fast foward, etc, does not disable RunAhead.

So I stand by my point, it should be dealt with in a case by case basis, with investigation being done (preferably by console runners, who are acustomed to the lag on console).

But what do I know? I'm not a serious speedrunner apparently.

Just wanted to state my two cents.

The main issue with emulation in general, is that it allows the user to apply tweaks very easily. So even an inexperienced player can "cheat" by reducing lag, speeding up the game, etc. And the only way to identify these tweaks is by very closely examining the video.

There are specific emulators that allow greater flexibility than others. It's one of the reasons I always stress people to use Mesen or Bizhawk (newest version), as both are 99% accurate. Mesen is my personal preferred choice, since it doesn't allow such tweaks. But considering the vast array of emulator choices out there and people with extremely different computer setups, it comes down to making rules that eliminate some of those as choices.

The other issue that was brought up comes in the form of rom hacks that are slightly sped up versions of the original games. These can be MUCH harder to identify. Especially since they can be used on real hardware. I've been working with the Deadpool (Nes) team now for roughly 1.5 years. And almost everyone there is a self-taught rom hacker. It's not that hard to do. My concern is in the future, we will see more people applying these methods over emulator tweaks since they're harder to identify.

Lastly, another issue is TASing. FCEUX and Bizhawk are the two emulators that have the best TAS features. The issue with TAS is that it's really easy to do...anyone can make a TAS. And these videos are impossible to spot if done correctly. Its fairly easy to make a bunch of doctored up runs and then one that PBs and then run them in order and act like youre playing.

The point Im trying to make is, outside of emulators, there are a significant amount of ways to "cheat". And it's exactly why its so important that mods enforce rules that make the players using emulators specifically to put things up like their FPS, Frame Counter, etc. To make it easier to see whats going on. And why it's important for everyone, not just mods, to come together and make things happen.

And just to be clear, I'm not calling anyone a cheater, Im just stating facts that SOME people may use tweaks in order to cheat. Others apply them simply to get a better gaming experience...which is the intended use for such tweaks.

I'm not here for passive aggressiveness. I'll simply restate what the authors of RetroArch themselves have said: RunAhead is not hardware accurate, nor does it strive to be. RunAhead relies on utilizing emulator savestates to function. Speedrunning typically bans emulator-specific functions, such as savestating. Using RunAhead is literally using an automated series of savestates in order to attempt to reduce input delay. You may have found a different use for it, but that doesn't change the fact that it is utilizing emulator savestates.

Quoting the developer of the feature, here: https://www.reddit.com/r/emulation/comments/886ucq/novel_method_to_reduce_emulator_input_lag_beyond/dwj3chb/:

"In Single-Instance mode, when it wants to run a frame, instead it does this: Disable audio and video, run a frame, Save State Run additional frames with audio and video disabled if we want to run ahead more than one frame Enable audio and video and run the frame we want to see Load State"

You guys do know that BIZHAWK has tasing capabilities inside of it right? but you're allowing that? also basically the runner used a core option to overclock the core. which is a core option, not a retroarch option. therefore you banned retroarch? EVEN the standalone EMU has the SAME option but you're still allowing it. IF you runahead 1 frame on retroarch there is literally no advantage. THIS IS NOT a retroarch problem.

Also this is how Tenebrae (mod) and even the classic sonic leaderboards mostly handle our leaderboards with retroarch. Emulators:

No save states or other emulator-specific functions. Not even for reset!

Please specify the emulator used. Different emulators handle the lag differently.

Allowed emulators: • Genesis Plus GX (RetroArch, BizHawk, etc.) - Recommended, but faster than console • BlastEm (stand-alone, RetroArch, etc.) - Seems more accurate than GPGX, still in development • Fusion 3.64 - Deprecated, but allowed for accessibility and ease of use

Emulator comparison https://tinyurl.com/y5fb8r2d

Analogue Mega Sg:

The buffer options screen must be shown. If using the "Zero Delay" buffer option, time will be multiplied by 60/59.9228 to account for the frame rate difference. This will also be done if the options screen is not shown.

Also please look at the emulator comparsion. in more times then not. FUSION is faster then RETROARCH (GPGX). You really shouldn't be banning emulators that are more accurate to console. You're literally banning something that is more accurate just because the core has overclocking options. It was never retroarch. Running ahead 1 frame does nothing but give you less input lag. Running ahead 2 or more frames is easily noticeable and makes the game choppy and skips frames. run ahead 1 frame does not do that. Anyways In all my games I speedrun and the games ive seen modded. Retroarch is always allowed because its very accurate to console. Most accurate afaiko. Getting rid of it is only turning away runners that dont want a huge advantage over console like fusion has. Anyways theres my rant. I do believe the rules i posted are basically the best rules though. Thanks to tenebrae for the great rulesets.