What's wrong with run ahead?
Texas, USA

There's been a lot of talk recently about the use of Mesen as an emulator and its ability to use a lag reduction feature called run ahead. My understanding is it introduces a display delay one frame at a time to reduce lag for the user. My question is, why is this not allowed?

As a hardware user I started on flat screens and experimented with different systems and setups to change the degree of lag I experienced. I used FPGA consoles, frame buffers, and different TVs all with the result of varying lag. Why wouldn't we allow software (emu) runners to do the same with software?

The only issue I can see is if an emulation user had the run ahead settings past say 2 frames. At that point you've likely overcome the lag introduced by the emulator/computer and are truly working ahead (which is a condition not available to hardware users and I would see as being a problem). But if setting the run ahead to 1 or 2 frames results in the user still dealing with some small amount of lag, how is that any different than an FPGA user who uses a frame buffer and a low lag monitor?

I'd always just assumed there was good reason for it, but today I thought about it (as I recently became a mod for another game) and I couldn't figure out why it would be a problem. Thanks yall : )

California, USA

indeed, only using runahead to a small degree would bring emulators runs closer to original hardware performance, and shouldn't be a problem if the only thing we're worried about is maintaining a fair playing field. it's my belief that some of the motivations for banning run-ahead (or worse, banning emulators simply for having the feature available) were made from a place of ignorance and confusion over how the feature actually works. However, as a moderator myself, i think maintaining a ban on the feature has merit.

WHY PEOPLE FREAKED OUT ABOUT RUNAHEAD IN THE FIRST PLACE As far as I can tell, the original concerns with runahead is because people thought it did something it doesn't. Even in your post you refer to it as "lag reduction". it's really "input latency reduction". calling it lag reduction makes people think it reduces lag... obviously. some games have parts that lag. metroid gets laggy when there are too many sprites on screen, for example. these are conditions of the games that hardware users experience and therefore emu users should also have to deal with for fair play. when people think the feature "reduces lag", they think it effects those types of things. time and time again i see games with rules that say "mesen is banned because it has lag reduction features". also there was a lot of confusion over whether or not run ahead can be detected (i have a youtube video explaining how to detect it, so long as the input display is turned on), and some people even thought that there was a default amount of run ahead even when it was set to 0. Due to these misunderstandings, SMB banned Mesen after the feature was added, and a lot of other games followed suit. I've tried to get some of these bans reversed by educating moderators with my youtube video.

WHY A RUNAHEAD BAN MIGHT STILL BE A GOOD IDEA Moderating a game, especially a popular one like NInja Gaiden, can be time consuming. And this isn't a paying gig. It's feels like it would be a pain in the butt to have to prove that someone used the "right amount" of runahead. never have i seen a rule that says "it's ok for you to use this feature, but only if you use it a little bit!" it's so much simpler to say NO, and then only check high level runs or runs that look fishy. And frankly, the input latency is not that big a deal. the only game i've ever run were i felt like the latency was a problem was MTPO. most of the time you can just compensate for it.

SD_GeNo, Edo_87 and 3 others like this
Texas, USA

Thanks the the reply man! I was hoping you'd chime in here since your knowledge of this is pretty extensive. Its sad that we've saddled emu users with additional handicaps just out of a misunderstanding (sounds like I need to be a stickler on using the term input latency vs input lag from now on).

Ninja Gaiden currently doesn't require showing the emulator window until 12:10. I think we can all agree that's a much bigger deal than input latency reduction. So that being that case, maybe we check run ahead usage sub 12:10? It would be pretty simple to require runners to show it at the end of their runs as well. Its also visibly obvious from 3 frames and up. At 3 frames you can see the judder on occasion. At 4 frames the game looks like its dropping frames and the run would easily be invalidated. At 5 frames its a total rodeo. So its not like its a hard thing to notice on this game from a mod perspective.

Maybe MesenRTA needs an update or an alternate version that allows 1 or 2 frames of run ahead?

Also, to be clear, I run Gaiden on OG hardware, so this doesn't affect me. It just seems like an unfairness worth mentioning.

Remz and SpaceColonizer like this
United States

I am a CV1 runner, but I did want to share my experiments with this as I think it likely has good crossover into ng.

I originally used bizhawk for my cv1 runs and then moved to the mister (fpga where input latency replicates original hardware). The improvement in input latency has been wonderful. Unfortunately, I had developed and released a series of CV1 training tools for bizhawk. The input latency differences made it extremely hard to use them for training.

To solve this, I thought I could port my training tools to mesen and calibrate the mesen latency to mister using runahead. Unfortunately, that porting failed since mesen disables scripts in runahead mode (probably a good thing actually for speedruns). However, before figuring that out, I spent some time trying to calibrate the latency. Here is what I learned:

I tried calibrating two ways. I used an iphone camera at 240fps and timed the number of frames at 240fps between button press and an animation event. I used the same monitor and controller. It wasn’t extremely scientific with the button press aspect, but it gave a reasonable ballpark. I also sanity tested by trying to hit a frame perfect input trick.

3 frame runahead —--------------------- This was faster than original hardware. At the same time though, it was visually clear by looking at the gameplay that runahead was enabled. During motion scenes where attacks cause you to lose frames, you can see the character moving backwards when he attacks.

1-2 frame runahead —--------------------- This is where it gets a little complicated. I would say that 1 frame runahead is slower than original hardware. 2 frame runahead is at or slightly faster than original hardware, however, it was really close. I am not 100% sure the reason for not having an exact match, but I have a theory. I think the reason for this is variability from running on a modern computer. First, you have the operating system polling the usb controllers. I think by default the polling is quite high (but not 100%) (in the 5-10ms range). The game polls every 16 ms, so you can have varied input lag depending on when that polling is relative to the operating system polling. In addition, the monitor is likely getting input at 60hz. However, the game is outputting at 60.09hz. I think for that to work properly, this would force the display to build up latency over time (10 second interval). I’m not 100% on either of those being the cause, but that is my current running theory.

The above makes me lose very little sleep over runahead functionality. If the feature is past 2, there should be clear visual artifacts. If the runahead is 2, it seems very close to original hardware and possibly with the downside of more input latency variability relative to original hardware.

arnaud33200, Fabricator_General and 2 others like this
Game stats
Latest threads
Posted 2 years ago
1 reply
Posted 9 months ago
6 replies
Posted 1 year ago
5 replies
Posted 1 year ago
3 replies