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.