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.

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 : )

That's interesting LuckyYump! I didn't know that. When I tested mine, I did it using the HDMI out (I did it by running Excitebike for about 10 minutes and compare clocks to a standard NES using the avidemux frame counter). I tried the frame buffer but the lag and screen tearing it created was too much for me so I didn't bother to test it. Maybe I'll go back and test it with analog out and see what it does.

Correct. 60.0988 or something like that. The AVS is a 60 FPS unit as well. My understanding is the MiSTer operates at the correct framerate but I haven't tested it personally.

Note that the Analogue Mini, like most FPGA systems, runs at 60 fps. So you'll probably lose about a second during the course of a Ninja Gaiden run. Its my understanding the Nt Mini has a frame buffer option that may correct for some or all of the framerate discrepancy, but I believe it introduces lag/screen tearing. Just something to be mindful of for speedrunning.

Hopefully answered my own question. I downloaded the top two Game C 250k runs and frame counted them and it looks like the beginning frame is the earliest possible frame that the title screen starts to get fuzzy on game select. If that's wrong please let me know.

I have a run I need to frame count before submitting and I want to make sure I do it right. Where do we begin the frame count? Is it when the screen goes black, when the playing screen comes up, or during the fuzzy part in between? Thanks!