Input lag of (analog video) arcade games
This page aims to be a collection of verified input lag measurements for different arcade hardware. I have yet to see such a site with actual verifiable data proving the measurements, or even a clear definition of how they’ve been measured.
How I define “frames of input lag”
The typical definition of “input lag” is something like “time between an input is triggered and the resulting action is visible on screen”. This can easily be measured in milliseconds, but will depend heavily on at least two factors.
- Timing of input in comparison to when the game engine samples the port
- Position of player sprite on screen
If a button is pressed just before the input port is sampled, no additional latency is added, but if a button is pressed right after the input port has been sampled, there will be close to a full frame before the input is actually triggered.
Since (CRT) monitors render frames from top to bottom, the top lines of the display will be output close to a full frame before the bottom lines.
To abstract away these factors, I will use the following constant definition of “Frames of input lag". For further reading, also see the site inputlag.science, which uses a similar standard.
Input lag = Count of frames of inaction between an "input frame" and a visible "output frame"
This means that if an input is triggered during a frame, and immediately visible the frame after it, there will be an input lag of 0 frames. Click measurements below for details.
Measurements
All data is measured from original PCBs. Click one of the games to show the measurements data for it.
The image where input was triggered will be marked GREEN and the first image where sprite movement is visible will be marked RED.
How to measure input lag
The high-level procedure for measuring input lags is quite simple:
- Using a high speed camera (I use an 240fps iphone), shoot video of an input triggering, and the output being displayed
- Measure lag in frames as described above using result
- Make sure to share the raw data along with the output, so it can be independently verified
There are some details that need to be considered when doing this.
Detecting input
Simply checking which exact 240fps frame a button or lever is activated can be complicated. A simple solution to work around this is to wire up a LED to light up when the input is triggered, and have this be visible in the video.
Inspecting video
There is a great iPhone app called “Is it snappy” which allows quickly going through the 240fps frames, marking input and output. Alternatively you can feed the video into avidemux and step through frames manually.
Running several samples
Make sure to run several measurements, to get the input to trigger at different raster positions. This should give you a variance of approximately 16 milliseconds spread out over a rendered frame. Use this frame as FRAME_WHERE_INPUT_TRIGGERED and verify that the number of frames until FRAME_OF_VISIBLE_OUTPUT is consistent.
Circuit for hooking up LED to buttons/lever
I recommend buffering the input to the LED through an inverter such as a 7404 or similar. You can assume that the PCB input will have an onboard pullup resistor. In practice this means:
- VCC and GND of 7404 to +5V and GND of PSU.
- Lever/button wired to inverted input.
- Use negated output to power a LED + resistor.