Emulation Does Not Have Input Lag

Published on 26 May 2026

Emulation VS FPGA

When people talk about the benefits of FPGA for playing older systems, accuracy tends to be one of the answers (which I think is partially dishonest, but that’s not the topic of this post), but one other thing that comes a lot is a lack of input lag. Fundamentally, that’s not wrong, but it shows in my opinion a bit of a lack of care on what happened to emulation in the past decade.

While FPGA retrogaming has been largely gaining a lot of ground because of how FPGAs became more affordable over time, and there are definitely a lot of pros (and cons) that makes it very interesting for that purpose and more, it’s like that emulation has been stagnant to people, where FPGA is considered the gold standard now, and I really do not agree with that. FPGAs are still a bit expensive and not the most accessible to everyone, one clear thing in favor of software emulation is how it does work on basically anything you can think of, but somehow, always with cons compared to FPGAs.

Run Ahead

Input Lag comes in different flavors all at once:

These make the cocktail of lag, and modern gaming is certainly familiar with every of these aspects over time, particularly screen lag.
The standard is basically the original lag on the original system and screens of the time, we can call that zero input lag because that’s the best you could deal with at the time.

This has been an invention for quite some time, not all emulators do it, but a large amount of them do have it: It’s generally called “Run Ahead”.

In a nutshell, it’s like you’re sending controller inputs to the past. That’s not really the reality in all fairness but I think that’s the easiest way to explain it in layman’s terms.

Run Ahead is basically the bruteforce answer to not only reach zero input lag, but also go negative lag. Honestly it’s kind of black magic. Technically there’s still lag, but you’re no longer punished to it.

The reality is more like the opposite, you’re sending inputs and the emulator constantly fast forwards a specific amount of frames. It’s not too far off from the concept of rollback netcode too, but obviously, that means depending on the amount of frames to skip, it asks for more performance out of your system that emulates because now it has to be able to emulate at least 2 frames of a system in one go. That’s the significant drawback of Run Ahead, and that means it can’t necessarily be used on everything, but in all fairness, any computer today can manage it for up to a 32-bit system most likely, depending on the level of accuracy that the emulator is doing.

One other thing is that too many frames of Run Ahead would essentially break continuity, but the point is to maintain the illusion so you don’t really need more than up to 4 frames at most, and it works very well to counter all of aspects of input lag that I’ve explained above, you could counter the screen lag, you could counter your controller’s input lag, and you could even counter the game’s inherent lag, something that honestly, you can’t really do on FPGA, at least for the the time being.

So while FPGA gaming does have a lot of good, I consider the input lag argument to be dated, there are definitely more subtle differences in polling the controller works depending on both, so I do think FPGA does have an edge about input anyway, but I really want to remind people that this feature exists.

Please look at the settings of your emulator and look into Run Ahead, I swear it’s worth setting it up.

Official Emulation

Also, a message to everyone working on legal emulation, please look into this feature. Not many are doing it, and I think we could really get an even better emulation experience. The games of back then can be particularly hard, and input lag is largely one of the causes that made them age more than they actually were.