New device: GILT Game Input Lag Tester

[Oomek]

It looks neat. Is black to white transition time used?

That's what the slider is for. If set to 50% the threshold is set to gray. At 10% it measures the lag without LCD response time.

[spacediver]

I had no idea though that people are still playing Quake. I'm a retro lover myself, but Quake for me is not oldschool enough

There are a number of ppl who play quakelive, myself included

What if I play quake?

Quakelive? What name do you use? (I'm Julios)

[Oomek]

A little update.
After connecting my photoresistor's output to the scope I went into shock. This damn thing has rising and falling slopes going for more than 50ms ! No surprise I've had problems with min/max brightness calibration. I bought a handfull of phototransistors with the 15us slopes. That should make the device even more accurate. Will keep you posted how the tests went as soon as I get it.

[Sparky]

A little update.
After connecting my photoresistor's output to the scope I went into shock. This damn thing has rising and falling slopes going for more than 50ms ! No surprise I've had problems with min/max brightness calibration. I bought a handfull of phototransistors with the 15us slopes. That should make the device even more accurate. Will keep you posted how the tests went as soon as I get it.

One option for a photoresistor is to use its slope for your trigger instead of or in addition to its value. It also helps to set your threshold with a pot, so you can adjust the sensitivity to whatever the lighting conditions in your room are, while whatever game you're testing is open and on the test scene.

[Oomek]

No Sparky, I cannot do that. I read the analog value from the photo sensitive element, my sensor is shielded from the ambient light with a black foam, when the photosensitive element has any inertia it affects readings of the falling and rising slopes of a pixel (LCD response times) threshold with a pot is a no no as I won't be able to adjust it within my app. Now I can separate the display input lag and the LCD response time by setting the slider to 10% and if the new light detector will be more accurate maybe I will be able to lower that value even more. I still recommend the 50% point for measurements though.

[Sparky]

Well, you can put a button on the thing that sets the threshold to the current reading + x, and since you're using analog reads you can get slope by subtracting the current measurement from the previous measurement.

The main problem sticking the photosensor on the monitor with black foam is that it rounds all your vsync off results up to the next time the scanline crosses the photosensor. That's tolerable in some cases, but not when you're comparing different refresh rates.

[Oomek]

Well, you can put a button on the thing that sets the threshold to the current reading + x, and since you're using analog reads you can get slope by subtracting the current measurement from the previous measurement.

Calibrating the sensor threshold with the panel itself might be not bad idea.

The main problem sticking the photosensor on the monitor with black foam is that it rounds all your vsync off results up to the next time the scanline crosses the photosensor. That's tolerable in some cases, but not when you're comparing different refresh rates.

My vsync off display routine is very tightly synced. I draw everything on vblank(yes, it's a trick I discovered and you can do it in DX11, don't need DX9 anymore) It rarely goes off a few pixels from the top, but for that I got a table of results and take a minimum value as a result, so it's stable now and accurate even more than with vsync on.

[Sparky]

My vsync off display routine is very tightly synced. I draw everything on vblank(yes, it's a trick I discovered and you can do it in DX11, don't need DX9 anymore) It rarely goes off a few pixels from the top, but for that I got a table of results and take a minimum value as a result, so it's stable now and accurate even more than with vsync on.

I don't see how drawing everything during vblank changes anything, that still rounds the latency up to the next time the scanline crosses the sensor. Measuring the brightness of the whole screen is more useful for characterizing games.

I don't think throwing away data is a good idea unless the only thing you're interested in is the minimum value, as you wouldn't be able to see the variation in latency caused by things other than refresh rate.

[Oomek]

There is no point in measuring the latency on the other part of the screen than the very top if you want to measure just the cable latency. My method works I can assure you.

[Sparky]

There is no point in measuring the latency on the other part of the screen than the very top if you want to measure just the cable latency. My method works I can assure you.

If you want to measure the latency of of your cable, you use a time domain reflectometer, or at least that principle: https://www.youtube.com/watch?v=9cP6w2odGUc

I guarantee any setup that involves a monitor and a photosensor is too slow for that.