Page 4 of 44
Re: flood's input lag measurements
Posted: 28 Sep 2014, 02:51
by flood
spacediver wrote:just so i'm following on one of your lines of thought:
assuming equal base input lag, over many measurements one would expect the same distribution of input lag in both these situations:
1) artificially capping a game at 125 fps (when uncapped it could do 1000000 fps)
2) a game that can only render at 125 fps even when uncapped
correct?
suppose the base input lag is 0 (i.e. uncapped has 0 input lag
for 1 you'd get anything between 0-8ms lag
for 2 you'd get anything between 8-16ms lag
this depends on the cap working by sleeping after drawing instead of sleeping between getting the input and drawing.
explanation for my formula:
http://i.imgur.com/9cSP1bM.png
Re: flood's input lag measurements
Posted: 28 Sep 2014, 08:27
by stirner
How do you get results as low if your monitor's refresh interval of 85Hz dictates on average at least ~12ms delay? You could naturally be looking for changes at the bottom of the screen, but I imagine it takes countless takes to get the impact timing right if you do that.
Re: flood's input lag measurements
Posted: 28 Sep 2014, 13:01
by spacediver
stirner wrote:How do you get results as low if your monitor's refresh interval of 85Hz dictates on average at least ~12ms delay?
look at the image flood posted - there are a range of possible values. if baseline input lag is 0 ms, then the maximum input lag will be 1/85. The average would be 0.5 * (1/85).
Re: flood's input lag measurements
Posted: 28 Sep 2014, 15:00
by flood
stirner wrote:How do you get results as low if your monitor's refresh interval of 85Hz dictates on average at least ~12ms delay? You could naturally be looking for changes at the bottom of the screen, but I imagine it takes countless takes to get the impact timing right if you do that.
when vsync is off, and fps is high, the screen is constantly updated and it doesnt matter what the refresh rate is.
watch the video:
https://www.youtube.com/watch?v=vlHEpju24-Q
i capture an entire vertical stripe of the screen
it really depends on the definition of input lag
what i'm measuring is the time between (initial movement of the mouse) to (ANY change on the screen)
if you only look at a specific part of the screen, that measures the time between (initial movement of the mouse) to (change on the screen at that part)
the time difference between the two is equal to a uniformly distributed random variable between 0 and 1/85 s
so if for the first definition i can consistently measure 1ms of lag, for the second definition i would measure anything between 1-13ms of lag.
in practice, the second type is more relevant. for instance if an enemy pops out of somewhere, he's probably not covering the entire screen.
but for measurement, i prefer the first type as there is less variation between measurements
Re: flood's input lag measurements
Posted: 28 Sep 2014, 19:09
by blargg
flood, I looked at your picture and have read your reasoning and I am impressed that you have thought this through carefully. I like how your approach focuses entirely on how to get the data, with flexibility in how things are configured so that it is collected in the most straight forward manner.
Re: flood's input lag measurements
Posted: 28 Sep 2014, 20:08
by flood
uh thanks :d
Re: flood's input lag measurements
Posted: 29 Sep 2014, 13:04
by silikone
So you're measuring the lag from mouse input to the first pixels being drawn from the new framebuffer instead of waiting for a whole scan? Makes sense, it shows the theoretical minimum amount of lag created independently by the computer. Practically, the display will add more lag to the pipeline, but monitors always have room for improvement, while existing games at specified frame rates don't have.
Re: flood's input lag measurements
Posted: 29 Sep 2014, 14:42
by flood
well the entire chain for csgo still has 3-4 ms of lag that i can't account for...
Re: flood's input lag measurements
Posted: 29 Sep 2014, 16:20
by stirner
flood wrote:stirner wrote:How do you get results as low if your monitor's refresh interval of 85Hz dictates on average at least ~12ms delay? You could naturally be looking for changes at the bottom of the screen, but I imagine it takes countless takes to get the impact timing right if you do that.
when vsync is off, and fps is high, the screen is constantly updated and it doesnt matter what the refresh rate is.
watch the video:
https://www.youtube.com/watch?v=vlHEpju24-Q
i capture an entire vertical stripe of the screen
it really depends on the definition of input lag
what i'm measuring is the time between (initial movement of the mouse) to (ANY change on the screen)
if you only look at a specific part of the screen, that measures the time between (initial movement of the mouse) to (change on the screen at that part)
the time difference between the two is equal to a uniformly distributed random variable between 0 and 1/85 s
so if for the first definition i can consistently measure 1ms of lag, for the second definition i would measure anything between 1-13ms of lag.
in practice, the second type is more relevant. for instance if an enemy pops out of somewhere, he's probably not covering the entire screen.
but for measurement, i prefer the first type as there is less variation between measurements
I know, that's why I said looking for changes at the bottom of the screen (where the most recent frame data is rendered as per non-vsync). Still, to get the measurements consistently as low, your input timing in relation to framerate/refresh rate plays a role. But if you manage to get the whole screen striped on the low resolution camera, I guess initial changes would be noticable without considering blanking interval which I had to in my tests where I only got my camera to capture the bottom of the screen.
Re: flood's input lag measurements
Posted: 29 Sep 2014, 18:56
by spacediver
just picked up my casio ZR700, and am looking forward to following in your footsteps :p
any advice on what software to use to analyze the video files?