GSYNC Input Lag Test Results in Chivalry: Medieval Warfare

[sharknice]

Yep, VSYNC OFF

[nimbulan]

I have a feeling my reply got lost in the shuffle there.

Could you test if the configuration variable OneFrameThreadLag has any effect on input lag? It's found in UDKSystemSettings.ini.

[sharknice]

I have a feeling my reply got lost in the shuffle there.

Could you test if the configuration variable OneFrameThreadLag has any effect on input lag? It's found in UDKSystemSettings.ini.

The only place I see that file are in the PCServer config files.

[nimbulan]

I have a feeling my reply got lost in the shuffle there.

Could you test if the configuration variable OneFrameThreadLag has any effect on input lag? It's found in UDKSystemSettings.ini.

The only place I see that file are in the PCServer config files.

That's odd, I have the line

Code: Select all

OneFrameThreadLag=True

up near the top of UDKSystemSettings.ini under the [SystemSettings] section. I know it's a standard UE3 variable and it's set to true in every UE3 game I've tinkered with the config files on.

[Trip]

Got a great idea for everyone to test input lag. Simply bind an action (like fire a gun) to the capslock, scroll lock or num lock in the game and record the light. Now you only need a good camera.

[RealNC]

Got a great idea for everyone to test input lag. Simply bind an action (like fire a gun) to the capslock, scroll lock or num lock in the game and record the light. Now you only need a good camera.

I made the suggestion in the past, but the experts assured me that this won't work, since those keyboard LEDs are very inaccurate.

But no one tested to see if that's actually true though.

[nimbulan]

Got a great idea for everyone to test input lag. Simply bind an action (like fire a gun) to the capslock, scroll lock or num lock in the game and record the light. Now you only need a good camera.

I made the suggestion in the past, but the experts assured me that this won't work, since those keyboard LEDs are very inaccurate.

But no one tested to see if that's actually true though.

There's two issues with this method. The LEDs are controlled by the motherboard, and the system controlling them doesn't need to be designed for speed so it's probably not. The other is that it would be extremely difficult to determine the delay for these LEDs coming on because you can't accurately determine the activation point of the key visually.

One person was able to use this method because his high-end keyboard is confirmed to have locally controlled LEDs with no lag. I doubt there are more than one or two models of keyboard that are capable of this.

[Chief Blur Buster]

One person was able to use this method because his high-end keyboard is confirmed to have locally controlled LEDs with no lag. I doubt there are more than one or two models of keyboard that are capable of this.

Yeah, that's user "sharknice" here.
He used a high speed camera to confirm that the LED illuminated within 1ms, so it was suitable for input lag tests.

That said, the physical computer mouse modification is a much more guaranteed/reliable method of for the highspeed camera technique of "buttons-to-pixels" input lag testing, done at http://www.blurbusters.com/gsync/preview2

[RealNC]

The other is that it would be extremely difficult to determine the delay for these LEDs coming on because you can't accurately determine the activation point of the key visually.

You can do this comparatively. We know the mouse-mod method is fairly accurate, so to determine whether the keyboard LEDs are accurate or not, we would need to compare input latency results between these two methods. If the results match, then the keyboard LEDs on the specific system must be accurate. If they don't match, but we observe a constant offset, then this too means that they accurate. If they are not accurate, the variance should indicate whether they are accurate enough or totally worthless.

I assume a PS/2 keyboard is needed for this though.

[Chief Blur Buster]

I assume a PS/2 keyboard is needed for this though.

I did some tests in the past and found the keyboard LED latency is a bit variable. It's somewhat based on CPU workload, and a very slow/overloaded system (especially older verisons of Windows, like Window 95, running so many apps) can have a delay between pressing a CapsLock and the LED turning on. The keyboard driver software turns on the LED after receiving the keypress events. I feel it isn't trustworthy enough for mullisecond-accurate input lag tests, as it hasn't been constant-offset (at least in previous versions of Windows).