What's new
By:

PCB lag database using Is It Snappy

alamone

alamone

Professional
Joined
Nov 14, 2020
Messages
174
Reaction score
359
Location
SoCal, USA
Inspired by the Astro City Mini V... I decided to start measuring the "native" lag of PCBs - that is, the lag from sending an input signal (measured by an inline LED) until the PCB recognizes the input. I've only tested a few PCBs so far but I will continue to test my collection.

In response to feedback, I've made the following changes:
- Measure in-game movement (ship movement or firing a shot) instead of using the PCB's I/O test
- Subtract the measured lag of the LCD I'm using for each measured data point

Link:
PCB Lag database

A description of the methodology is on the 2nd sheet.
 
Last edited:
What does it mean:

End frame is when the text in the PCB's I/O check for Button 1 changes fully to "ON".

How do you check the PCB responds to the input signal? With a scope?
 
The app uses 240fps video recording mode of iPhone. So, you just find the frame when the on-screen text in the I/O test changes from "OFF" to "ON". Compare that to the starting frame when the LED on the joystick is lit, and you have the total latency from joystick input to visible change in video output.
 
So I'm gonna be honest and say that I think this is a super cool idea, but your approach feels flawed to the point of being somewhat useless. In that I utterly don't trust the I/O test mode to be indicatative of anything. If you're not testing for a state change in gameplay, with the game engine running, it's just not telling you much of any value. Many games have higher input lag because of how code in the game is running, that is very unlikely to be reflected in any way in an input test.
 
Hi Aurich. Good point, but I think that the I/O test is actually pretty accurate for the most part. The reason why I was using I/O test was it was easy to tell when the PCB registered the input. But I'll try testing in-game (maybe using directions instead of fire button) and see if there's any differences.
 
Well I retested in-game, and here's the findings:

Detana Twinbee: I/O test 1 frame, in-game 2 frames
Gradius IV: I/O test 2 frames, in-game 3 frames
Raiden II: I/O test 2.6 frames, in-game 2 frames
Strikers 1945: I/O test 3.8 frames, in-game 4 frames
Strikers 1945 II: I/O test 3 frames, in-game 1.6 frames

So, the biggest difference is Strikers 1945 II, which has a much reduced lag in-game. Otherwise, differences are within 1 frame.
Given that gameplay is the most important, I'll be testing in-game going forward.

Also, I noticed that lag differs between shot and movement. For example, Detana Twinbee was about 3 frames on shot, but 2 frames on movement.
I think shots may be sometimes delayed/buffered, whereas movement is immediate. So, testing movement is probably the best measurement.

Also, while I'm at it, I'm also testing scaler compatibility using OSSC, Retrotink 5X, GBS-Control, and Medusa.
So far, OSSC is the most compatible scaler. If there are any other modern scalers of note, please let me know.
I'm not testing older scalers like XRGB series because I feel they are superseded by modern scalers.
 
alamone said:
The app uses 240fps video recording mode of iPhone. So, you just find the frame when the on-screen text in the I/O test changes from "OFF" to "ON". Compare that to the starting frame when the LED on the joystick is lit, and you have the total latency from joystick input to visible change in video output.
Click to expand...
Got that, but that is not "native" lag of PCBs as you describe it. In your database you mention you have a LCD screen; that means you are including the lag of the LCD-processing. If you use a CRT (which is near zero lag) your measurement would be more accurate.
 
waiwainl said:
Got that, but that is not "native" lag of PCBs as you describe it. In your database you mention you have a LCD screen; that means you are including the lag of the LCD-processing. If you use a CRT (which is near zero lag) your measurement would be more accurate.
Click to expand...
This is true, that monitor is very low lag for a PC running high refresh applications, but at 60hz with PCBs you're adding roughly half a frame of lag using it.

https://www.rtings.com/monitor/reviews/lg/27gn750-b
 
Not sure how rtings does lag measurement, but according to Leo Bodnar tester this LCD has minimal lag. I do have a PVM, but it's inconvenient to use with the space required.

FZYWZcLVUAAkfmG.jpg
 
Are you subtracting that ~2.7msec of display lag from the measurements before you add them to the spreadsheet? Also is the lag the same for the other measurement points on that display?
 
alamone said:
I do have a PVM, but it's inconvenient to use with the space required.
Click to expand...
Well with the LCD you're measuring your setup. The entire video chain including the LCD, not just the PCB itself.
 
The measurements do not include subtracting the display lag, I could subtract them in the spreadsheet. I have not tested the other bars - obviously the lag on those will be different. But that should be the same case for a CRT as well, as the electron gun has to scan downwards.

I might get around to RGB modding the little 9 inch Trinitron I have so I can use it as a test display.
 
Nice work @alamone.

I have done something similar before but ended up wiring the LED to the down direction on the stick. The reason being is that shot often has some extra graphic updates associated with it.

Also to make sure the LED is switched off/on as fast as possible use an inverter (thank you @Hatsune Mike )

JAMMA switch/button input --> pin 1 of 7404; pin 2 of 7404 --> resistor --> anode of LED --> GND

7404, 74LS04, 74F04, 74S04, 74HCT04 all work

This way the LED turns on when the button is pressed

I made a small JAMMA interposer PCB so I can test all my PCBs easily.
 
alamone said:
Not sure how rtings does lag measurement, but according to Leo Bodnar tester this LCD has minimal lag. I do have a PVM, but it's inconvenient to use with the space required.
Click to expand...
Excellent point, I didn't think to look up their process, and it's well done, but also somewhat deceptive for our purposes.

https://www.rtings.com/monitor/tests/inputs/input-lag

They're measuring from the center of the screen. Which matches up with your measurement, because at 60hz it takes roughly 16ms to draw from the top to the bottom, so the middle of the screen will be around 8ms higher than the very top. They're seeing around 9 in the middle, you're seeing around 2 at the top, so checks out.

The reason I say it's a little deceptive is because we tend to baseline CRTs as "zero lag", which isn't really true. It's only zero at the very top. There's still the same draw time issue that makes the center lag around 8ms behind.

Long story short: your LCD is roughly 2ms laggier than a CRT. This is so close to inconsequential that I think you should ignore it. Your testing methodology already has a margin for error larger than 2ms anyways.
 
Yes, this LCD is already pretty low latency so I'm inclined to just keep using it and just subtract the top bar lag from the measurements. As Aurich mentioned, 240fps is the limiting factor anyway, so there's going to be some error in the measurement. I ordered some inverters from ebay and I'll solder them on once they arrive.
 
Aurich said:
Excellent point, I didn't think to look up their process, and it's well done, but also somewhat deceptive for our purposes.

https://www.rtings.com/monitor/tests/inputs/input-lag

They're measuring from the center of the screen. Which matches up with your measurement, because at 60hz it takes roughly 16ms to draw from the top to the bottom, so the middle of the screen will be around 8ms higher than the very top. They're seeing around 9 in the middle, you're seeing around 2 at the top, so checks out.

The reason I say it's a little deceptive is because we tend to baseline CRTs as "zero lag", which isn't really true. It's only zero at the very top. There's still the same draw time issue that makes the center lag around 8ms behind.

Long story short: your LCD is roughly 2ms laggier than a CRT. This is so close to inconsequential that I think you should ignore it. Your testing methodology already has a margin for error larger than 2ms anyways.
Click to expand...
This is thrown around a lot. The CRT is shown as “zero lag” because it shows the signal it’s given instantly. That’s true at the top, and the center, and the bottom. Before the beam reaches the bottom of the screen, the signal for the bottom does not yet exist.

Just about every LCD also scans from top to bottom like this, and the same is true. How much it elects to buffer between the signal and the transition of the crystals under scan is what’s important. Watch an LCD under a high speed camera and this scan pattern is readily evident.

As for methodology, I also say you shouldn’t use the IO test. For example, on CPS2, a background tile write can be done instantaneously, but sprites are double buffered in both the draw list and the framebuffer. You may see a 2F discrepancy there that doesn’t represent how the game engine reacts or can render.
 
You must log in or register to reply here.
Back
Top