When people talk about the feel of a game, they often mention graphics, sound, or nostalgia, but one of the most important elements is rarely discussed outside of enthusiast circles: controls. Controls are more than just button placement and responsiveness. It goes beyond the first party vs third party controller debate. It has very much to do with input latency.
Input latency is the total time between pressing a button and seeing that action happen on screen. Even the difference of a ten milliseconds can affect how responsive a game feels. That’s why we designed our own hardware, Reflex Adapt, to offer modern, low-latency solutions for classic controllers. We also go to great lengths to measure first and third party latency of Bluetooth, wireless, and USB controllers. With precise data, we can finally answer the question: what controllers really let you Play Better?
The Problem
Input lag comes from three main sources:
- Controller latency – how quickly your button press is registered
- System processing – how long the hardware takes to act on the input
- Display latency – how fast the screen updates pixels
One major architectural difference between classic consoles and modern hardware is how inputs are polled.
- On original hardware, controllers are polled synchronously during vertical blank. That means once per frame, right when the system is ready to update the image. There’s no guesswork — the game engine and the hardware are in lockstep.
- On USB and modern systems, controllers are polled asynchronously on a fixed interval (e.g., every 1 ms on MiSTer FPGA). The system has to check constantly and hope to catch the input before the next vertical blank. If it misses that window, the action can be delayed by an entire frame. At 60Hz, each frame lasts 16.67ms. The USB polling rate is significantly higher than the video frame duration. However, since it’s not synchronized with the vertical sync of each frame, fast usb polling (combined with low latency controllers) enhances the likelihood that the button press(es) will be registered within the current frame.
Solutions
That latency difference shows up clearly in Reflex Adapt results. Many classic controllers respond with sub-millisecond averages and same frame probabilities over 90%. Modern wired USB controllers, average nearly 6 ms with much lower same frame probability. Many wireless controllers balloon to more than 16 ms, with almost no inputs consistently registering in the same frame.
Some highlights from our tests:
- Reflex Adapt Neo Geo Mode: 0.77 ms average latency, 95.39% same frame probability
- Reflex Adapt Genesis Mode: 0.91 ms average, 94.53% same frame probability
- Reflex Adapt SNES Mode: 1.48 ms average, 91.12% same frame probability
- Reflex Adapt NES Mode: 1.56 ms average, 90.61% same frame probability
- Reflex Adapt GameCube Mode: 2.38 ms average, 85.72% same frame probability
- Reflex Adapt PlayStation Mode: 2.39 ms average, 85.67% same frame probability
- Average wired USB controllers (Non-Reflex): 5.93 ms average, 64.45% same frame probability
- Average wireless controllers (Non-Reflex): 16.16 ms average, only 3.02% same frame probability
What do these numbers mean in practice?
- Reflex Adapt’s 90% same frame probability provides an extremely close match to original hardware controls.
- Wired USB controllers (which are often not designed with low-latency in mind) can add disrupting input latency, often noted by “floaty” controls.
- Wireless introduces both latency jitter (the latency information shared earlier is the average latency). 2.4GHz controllers with proprietary dongles often fare better than Bluetooth controllers.
What about SNAC (for MiSTer FPGA)?
-
SNAC stands for “Serial Native Accessory Converter”. In its purest sense, it converts 5V control signals to 3.3V control signals, connecting the controller to the core directly. In essence, this is exactly the way that real hardware behaves. While this seems like a slam dunk, there are a few limitations:
- Only 7 data pins available: That’s right, there are only 7 signals connected to the FPGA core. That’s enough for 2 or more player for many systems (NES, SNES, N64, PlayStation, etc.), but only enough for a single player for Sega systems (each Genesis/Saturn controller used all 7 pins).
- Each input device can only be used with the correct core. The only exception to this is SNES controllers on the NES core because SNES controller protocol is an extension of the NES controller protocol.
The weak link
Even though our Reflex Adapt measurements show sub-millisecond differences between systems, it’s worth remembering that the ultimate bottleneck is often the player. A blink of an eye takes around 100-150 milliseconds, and average human reaction time to a visual stimulus is closer to 200–250 milliseconds. That’s hundreds of times slower than the latency of a wired retro controller.
But video games are not purely reaction-based. Most players are not waiting passively for a stimulus. They are anticipating what comes next based on patterns, previous plays, or even the way the screen scrolls. That’s why minimizing latency down into the single-digit millisecond range still matters. Even though our nervous system is slow compared to the hardware, tighter consistency makes games feel more predictable and makes player anticipation more reliable.
So what now?
- Use original hardware with CRTs if you want the truest experience.
- On FPGA systems like MiSTer, use low-latency options like 1ms usb polling, or SNAC.
- Stick with wired controllers when performance matters. Ask yourself: is the convenience of wireless worth adding 10+ ms of delay?
- Try a back-to-back test: play the same game with wireless, then wired. Pay attention not just to whether inputs register, but to how the game feels.
- Best of all, use native low-latency devices like Reflex Adapt.
Latency isn’t just about averages, it’s about predictability. Original hardware, by design, gives you that predictability because polling and display are locked together. Modern systems have to “hope” they catch your input in time. That’s why the numbers matter, and that’s why we keep testing.
What do you think? Have you noticed your own setup feel inconsistent? Would you trade convenience for responsiveness? Should manufacturers publish polling rates and latency numbers the same way they advertise resolution and frame rate?
Join the conversation, and together let’s measure, understand, and Play Better.