Page 7 of 8

Re: New device: GILT Game Input Lag Tester

Posted: 29 Oct 2016, 19:28
by Oomek
From what I'm seeing we are aiming at two different things. You want to completely eliminate the display latency. I'm aiming at receptive threshold to the human eye. With TEMT6000 and 200kOhm resistor I'm getting up to value of 900 with the analogRead(). On the other hand that's a huge surface area of that photo diode, very teasing.

Re: New device: GILT Game Input Lag Tester

Posted: 30 Oct 2016, 12:56
by flood
if you add in the factor of the human visual system, things get quite fuzzy. i'm not quite sure what would be the correct threshold in that case.

my immediate goals are to
1. characterize the base latency related to the processing overhead of the operating system and whatever program is ran. this is done by measuring full-chain latency from a teensy to a crt monitor for a program that flashes white upon mouse motion
2. measure my new lcd monitor's latency by comparing to 1 and its response time/overshoot on an oscilloscope

Re: New device: GILT Game Input Lag Tester

Posted: 30 Oct 2016, 18:24
by Oomek
Damn, i had to ask my friend to bring me a crt from the town depot and I ordered teensy. I want to try rawHID, maybe the usb latency will be more stable and predictable.

Re: New device: GILT Game Input Lag Tester

Posted: 30 Oct 2016, 18:28
by Sparky
Well, the main reason to simulate a mouse input is so you can test actual games in addition to your test program.

Re: New device: GILT Game Input Lag Tester

Posted: 31 Oct 2016, 06:02
by Oomek
Sparky wrote:Well, the main reason to simulate a mouse input is so you can test actual games in addition to your test program.
That's correct. I also prepared a directx shader wrapper to make games display a white rectangle like in my standalone app.

Re: New device: GILT Game Input Lag Tester

Posted: 05 Nov 2016, 21:26
by flood
Image
k so i made this circuit deadbug style, but non-inverting input on the first ad8655 is connected to a voltage divider (430kohm/560ohm) instead of ground. otherwise the circuit is unstable in complete darkness, i believe because the inputs aren't truly rail-to-rail
Image

step response:
Image

a lot of overshoot, coming from the first stage.
probably because the wizard didn't take into account the ad8655's input capacitance

Re: New device: GILT Game Input Lag Tester

Posted: 11 Nov 2016, 22:57
by Sparky
Oomek wrote:
Sparky wrote:Well, the main reason to simulate a mouse input is so you can test actual games in addition to your test program.
That's correct. I also prepared a directx shader wrapper to make games display a white rectangle like in my standalone app.
How does the wrapper decide whether or not to display the white rectangle? Do you just read the mouse input yourself, or do you somehow check that the frame you're modifying includes the result of the input event?

Re: New device: GILT Game Input Lag Tester

Posted: 12 Nov 2016, 07:34
by Oomek
Sparky wrote:
Oomek wrote:
Sparky wrote:Well, the main reason to simulate a mouse input is so you can test actual games in addition to your test program.
That's correct. I also prepared a directx shader wrapper to make games display a white rectangle like in my standalone app.
How does the wrapper decide whether or not to display the white rectangle? Do you just read the mouse input yourself, or do you somehow check that the frame you're modifying includes the result of the input event?
I use a directx shader wrapper. I generate a keyboard event with AVR and read it in the postprocess shader and then I draw the rectangle. It's late only by the time the game spends to process logic for a given frame. It preserves all the prendered frames and double/triple buffer delays.

Re: New device: GILT Game Input Lag Tester

Posted: 12 Nov 2016, 12:15
by Sparky
Oomek wrote:It's late only by the time the game spends to process logic for a given frame.
That's what I was worried about, that can be several to many milliseconds depending on the game.

Re: New device: GILT Game Input Lag Tester

Posted: 25 Nov 2016, 15:32
by Chief Blur Buster
In 2012, I developed an input lag tester under the same principles (Photodiode connected to an Arduino connected to a computer).

Image

It uses the same photodiode, connected to an Arduino, and then connected to the computer by USB cable.

I put it on the back burner while doing other projects, but I was able to achieve incredibly accurate results in a superior way than Leo Bodnar, top/center/bottom, at all possible refresh rates. Also, since then, I was able to reduce USB cable lag error margin to less than 0.2ms via a better Arduino-compatible microcontroller that had buffer-flush support for small packets. The big challenge is using DirectX full screen mode, to bypass windows compositing buffer delay.

I have been wanting to bring this to completion. While my device purpose is somewhat different (display focussed, rather than the whole input chain) -- maybe we can pool efforts. Share code, etc, help complete each other's products faster. I'd love to have BlurBustersSCOPE a complete project in the Blur Busters repertoire. Send me a PM.