Page 10 of 44
Re: flood's input lag measurements
Posted: 06 Dec 2014, 05:32
by spacediver
flood wrote:what i'm trying to figure out is where every millisecond of input lag comes from.
3) time to process the gamestate and draw the frame
...
(3) is a constant equal to the inverse of the uncapped framerate.
(4) depends on how much of the image responds to the physical event, and the amount of display my camera/photodiode/whatever is focused on. if either of these is small, then (4) would correspond to a uniform random variable between 0 and the inverse of the screen refresh rate. but if the entire iamge shows a change and my camera/photodiode is looking at the entire screen, then (4) would be 0 ~90% of the time, and a uniform random variable between 0 and the vblank length ~10% of the time.
Well if you had the photodiode only measuring the top of the screen, then that constant would effectively be zero, right?
And if you combine that technique with a reliable and reproducible "event", such as a black to white frame transition, you're getting rid of the random variable in (4), right?
Re: flood's input lag measurements
Posted: 06 Dec 2014, 07:22
by flood
there's no vsync. the framebuffer is updated instantly whenever a frame is done rendering. the graphics card's dac outputs data from the frame buffer row by row, and a crt instantly draws each row. when the framebuffer is updated, the monitor instantly responds since it is constantly reading data from the framebuffer (except during vblank). if the monitor is drawing the new data at the middle of the display, you'll have to wait until the monitor finishes drawing at the bottom of the display before the electrons go back to the top row, and only then would the photodiode see anything
Re: flood's input lag measurements
Posted: 06 Dec 2014, 14:28
by spacediver
right, hence the tear line. doh.
Re: flood's input lag measurements
Posted: 06 Dec 2014, 16:54
by spacediver
might be cool to have a vertical array of photodiodes lined up down the display
You could take some interesting measurements, and get a sense of how position sensitive the diodes are.
For example, if you had a vertical array of 10 diodes, and they all recorded a signal at the same time, then it would imply their sensitivity is great enough that position doesn't matter.
Re: flood's input lag measurements
Posted: 07 Dec 2014, 00:30
by flood
yep and i'll definitely be comparing against camera measurements
the ones at frys were kind of expensive ($8 for 1) so i only got one
i'll probably get some more from radioshack tmrw or just order online at some point
Re: flood's input lag measurements
Posted: 07 Dec 2014, 01:35
by flood
dam this one has a lens and turns out to be really really directional.
Re: flood's input lag measurements
Posted: 07 Dec 2014, 02:34
by spacediver
You might be able to take advantage of that in the following way:
If you can render at, say, 1200 fps, and you're running at 60 hz, then a single white frame, sandwiched by black frames, will occupy a vertical strip whose thickness is 1/20 of the full vertical height.
If you position the diode somewhere on the screen, and run 100 experiments, then you should expect, on average, five of them to involve tears at the diode's position.
(i'm too lazy to double check my logic right now, so correct me if I've made a thinking error).
Re: flood's input lag measurements
Posted: 07 Dec 2014, 03:02
by flood
still better to have something that isn't directional though... more data
bleh i really wish i had an oscilloscope to check the phototransistor's rise and fall times...
Re: flood's input lag measurements
Posted: 07 Dec 2014, 03:15
by spacediver
some very cursory googling indicates that it might be under 15 microseconds, in which case it's not worth worrying about.
also see
http://www.cel.com/pdf/appnotes/an3009.pdf
Re: flood's input lag measurements
Posted: 08 Dec 2014, 21:24
by flood
got a photodiode and an op amp...
almost everything's set up now.
if everything works as i expect, it should have <10 microsecond precision and accuracy, and it should be able to take >100 measurements a second.