flood's input lag measurements

[stirner]

Why would you expect them to ramp up? With fixed delay + 1ms random delay cascading around the frame intervals seems logical.
Thanks for all the measurements so far, my test setup is coming along as well. In the mean time, can you test triple vsync 85hz vs. triple vsync 85hz fps_max 84.9 with the updated randomizer code?

[Sparky]

Why would you expect them to ramp up? With fixed delay + 1ms random delay cascading around the frame intervals seems logical.

I might have been suffering from caffeine deficiency, I was probably still thinking in terms of v-sync off, where the detection isn't locked to the phase of the rendering.

Thanks for all the measurements so far, my test setup is coming along as well. In the mean time, can you test triple vsync 85hz vs. triple vsync 85hz fps_max 84.9 with the updated randomizer code?

Wasn't sure if it did decimals, so I threw in 84 as well(turns out it does do decimals). If the 85fps cap wasn't doing anything, the latency would be 70~80ms(though it might take a while to creep up that high). the threshold for fps_max seems to be about 85.2 on my system. As for averages, All 84, 84.9, and 85 were within 2ms of each other, with 84.9 being the fastest.

[flood]

which map/position did you use for csgo?

i found it pretty hard to find a spot from the default maps where turning 90/180 can make the screen go from nearly completely black to nearly completely white. i used a small program i wrote to change the graphics card's lut to a step function, and the best spot in csgo that i found was on nuke, staring into ct red, and turning to face ct spawn. ofc there are custom maps for which finding such a transition is much easier, but framerate isn't as low on those.

[lexlazootin]

I'm surprised no one has made one yet, threw this together.

It disables post fx, removes weapon models, disables hud and sticks you in the centre. video on how to load it and how it works.
https://youtu.be/HasevyKpm18

phpBB [video]

Do what ever you want with it.
http://www.mediafire.com/download/s7qsl ... _flood.zip

[Sparky]

which map/position did you use for csgo?

i found it pretty hard to find a spot from the default maps where turning 90/180 can make the screen go from nearly completely black to nearly completely white. i used a small program i wrote to change the graphics card's lut to a step function, and the best spot in csgo that i found was on nuke, staring into ct red, and turning to face ct spawn. ofc there are custom maps for which finding such a transition is much easier, but framerate isn't as low on those.

Don't really need the whole screen light, just enough of it to trip the threshold, so you can use the corner of a building from the side that's in shadow. I was using Dust, but I didn't try many maps.

I'm having better luck with the combination of a threshold and direction check, instead of just the direction check. Other changes are cleaning up my breadboard, adding a pot to control the threshold(which is checked either after a sample is captured, before the delay, or when the time since last sample is >100ms). I also added button to turn sampling on and off, and took the photoresistor off the breadboard, so I can fix it near the center of the CRT, at whatever distance I want.

re-doing some testing now, Will repeat rivatuner but not radeonpro, because radeonpro is really annoying, and was still slower than rivatuner in the tests with vsync off.

[Sparky]

here we go:

[stirner]

Thanks again. Very comprehensive.

Wasn't sure if it did decimals, so I threw in 84 as well(turns out it does do decimals)

The engine just looks at fps_max X in a 1000/X manner and so can adjust interval timings regardless of there always being a discrete amount of possible frames in a second.

I'm very suprised that fps_max 84.X 85hz sync doesn't net you a decrease in latency because I can definitely feel an improvement there and thought I had an explanation for it as well. With standard vsync frames can finish and be delayed for the next sync, so you get standard 1 cycle vsync lag plus added lag by grabbing input earlier with the frame and waiting for swap after finishing that frame. With frames finishing at a slightly slower pace than refresh, you will mostly (ignoring framerate fluctuation/frametime variance) be able to buffer swap immediately after the frames finish except for 1 refresh cycle in a second where you get a frame that doesn't finish in time for sync and so it will display the old frame still in the front buffer a second time, so 2 cycles of vsync lag for that. But on average you should get less "buffered" frames that wait for the monitor sync.
It would be interesting to hard-sync inputs with monitor refresh for a clearer indication of how the implementations affect pipe activity. But that wouldn't change the practical implications either. Are you using the internal vsync options from the game or forcing them from the GPU controls?

I'm still waiting on my teensy that I had to get in a seperate store.

[Sparky]

This is the transition I'm using now: http://imgur.com/KPA1wqG,waahs40#1 It works a lot better if I turn the brightness down on my monitor.

Thanks again. Very comprehensive.

Wasn't sure if it did decimals, so I threw in 84 as well(turns out it does do decimals)

The engine just looks at fps_max X in a 1000/X manner and so can adjust interval timings regardless of there always being a discrete amount of possible frames in a second.

I'm very suprised that fps_max 84.X 85hz sync doesn't net you a decrease in latency because I can definitely feel an improvement there and thought I had an explanation for it as well. With standard vsync frames can finish and be delayed for the next sync, so you get standard 1 cycle vsync lag plus added lag by grabbing input earlier with the frame and waiting for swap after finishing that frame. With frames finishing at a slightly slower pace than refresh, you will mostly (ignoring framerate fluctuation/frametime variance) be able to buffer swap immediately after the frames finish except for 1 refresh cycle in a second where you get a frame that doesn't finish in time for sync and so it will display the old frame still in the front buffer a second time, so 2 cycles of vsync lag for that. But on average you should get less "buffered" frames that wait for the monitor sync.
It would be interesting to hard-sync inputs with monitor refresh for a clearer indication of how the implementations affect pipe activity. But that wouldn't change the practical implications either. Are you using the internal vsync options from the game or forcing them from the GPU controls?

I'm still waiting on my teensy that I had to get in a seperate store.

Apparently when I select 85hz, my monitor's actually running at 85.2hz, just a quirk of frequency multiplication I guess. If you can feel a difference there, it's probably real, as the gap between game engine limited and vsync limited is 45ms~55ms(more if it's a 60hz monitor).

I've tried forcing v-sync either way and can't see any difference at all, except for the double/triple buffering, where applicable.

[flood]

I'm surprised no one has made one yet, threw this together.

It disables post fx, removes weapon models, disables hud and sticks you in the centre. video on how to load it and how it works.
https://youtu.be/HasevyKpm18

phpBB [video]

Do what ever you want with it.
http://www.mediafire.com/download/s7qsl ... _flood.zip

thanks, this will be really useful

is it possible to easily add (a lot of) complexity to the map so that the game renders more slowly?

[stirner]

Yeah I'm excited to start my own tests but I can see there are some little maybe annyoing variables involved that you have to account for and I know it takes time and motivation to even go ahead and mess with the settings over and over again when we know latency-wise nocap nosync is the optimum that most use and fps_max just adds an expected interval-bound average latency there.
But things like vsync not only help with tear but microstutter, because swap synced with refresh is perfectly timed presentation of frames, more so than frame limiting that acts before the frame is finished. So maybe if we can find low-latency vsync implementations the necessary1 refresh cycle of latency can be an acceptable compromise. Gsync'd CRTs would be nice, but gsync only solves tearing, not microstutter.

Is that transition really optimal? Because in the bright state you have 1/3 of the bottom darker. Depending on timing of input initial output could begin at the bottom of the screen and then you don't get a crass brightness change.

is it possible to easily add (a lot of) complexity to the map so that the game renders more slowly?

can't you flood the thing with water? Smoke grenades could be useful because they allow you to add different amounts of complexity on the fly and can be set to stay up all the time, but they have to be in your FOV to really affect rendering. Maybe that can be done without compromising brightness, or you need custom invisible smokes particles.