Page 3 of 3

Re: Measure button to pixel full input lag

Posted: 04 Jan 2017, 17:37
by Comanglia
Q83Ia7ta wrote: Next step is to make tests on both monitors at Quake Live. Quake Live because I perform much better at PG248Q at 170Hz than XL2540 at 240Hz. Values will higher for sure. max fps 250 is one of the reasons.
May be Quake Live engine (not directx9) works wrong at such high refresh rate. May be almost same full input lag (mouse button to pixel latency) affects my aim and overall feelings. May be I need to unbox and try GTX 1060 instead GTX 950...
Any ideas?
Might depend on what you're used too. Looks like most of the monitors you've tested are 24in panels and I'm going to assume that's what you typically use. Going to a 24.5in screen might be causing you to incorrectly estimate how much you need to move your mouse, or perhaps your crosshair looks slightly different causing you to expect it to be somewhere else when you snap to someone. Of course this would only affect you by a pixel or 2.

Could also be some other issues have you tried calibrating the monitors to look exactly the same? I know that messing with contrast and brightness dramatically affects my aim especially contrast.

Re: Measure button to pixel full input lag

Posted: 04 Jan 2017, 18:05
by Q83Ia7ta
Comanglia wrote:Might depend on what you're used too. Looks like most of the monitors you've tested are 24in panels and I'm going to assume that's what you typically use. Going to a 24.5in screen might be causing you to incorrectly estimate how much you need to move your mouse, or perhaps your crosshair looks slightly different causing you to expect it to be somewhere else when you snap to someone. Of course this would only affect you by a pixel or 2.

Could also be some other issues have you tried calibrating the monitors to look exactly the same? I know that messing with contrast and brightness dramatically affects my aim especially contrast.
Sorry for late update but that statement "I perform much better at PG248Q at 170Hz than XL2540 at 240Hz." is wrong now :) Just got used now and 240Hz rocks :) I played at 27" 144Hz and used quickly but yeah some time needed. They aren't calibrated to look exactly same. Just got used.

Re: Measure button to pixel full input lag

Posted: 05 Jan 2017, 17:17
by dhaine
do you play with blur mode on?

Re: Measure button to pixel full input lag

Posted: 05 Jan 2017, 18:45
by Q83Ia7ta
dhaine wrote:do you play with blur mode on?
Trying with and without. Hard to say. It's almost same.

Re: Measure button to pixel full input lag

Posted: 07 Jan 2017, 04:45
by gulul
Q83Ia7ta wrote:Sorry for late update but that statement "I perform much better at PG248Q at 170Hz than XL2540 at 240Hz." is wrong now :) Just got used now and 240Hz rocks :)
I think you had to get used to display scaling again. If you were playing everything @144hz or more on your old monitors, you were using gpu scaling, and the mouse feel is totally different. For example i never played cs @144 and i didn't notice any difference going @240. On other games, where i was using 144, the feeling was totally different (i can summarize it with "lack of control") and i needed some time to adjust.

Re: Measure button to pixel full input lag

Posted: 07 Jan 2017, 08:25
by Q83Ia7ta
gulul wrote: I think you had to get used to display scaling again. If you were playing everything @144hz or more on your old monitors, you were using gpu scaling, and the mouse feel is totally different. For example i never played cs @144 and i didn't notice any difference going @240. On other games, where i was using 144, the feeling was totally different (i can summarize it with "lack of control") and i needed some time to adjust.
I always use native resolution even it's 1440p@24" or 1440p@27" to prevent any scaling processing.

Re: Measure button to pixel full input lag

Posted: 09 Jan 2017, 13:12
by Chief Blur Buster
Sparky wrote:
lexlazootin wrote:
Chief Blur Buster wrote:The ideal debounce for a very mechanically reliable button could be done only on the button-release end, so you can avoid MOUSEDOWN latency -- since games often trigger actions on the press rather than the release. And that the mouse button is mechanically new enough that ultra-short debounce logic (<50ms) only on the releases, would be fully reliable for your gaming habit
I'm really not too sure if i understand.

So are you saying that RIGHT NOW mouse debounce is only applied to the mouse-down but not on the mouse-up? if that's the case wouldn't you have the same electrical bouncing interference ether way? It doesn't make any sense to me.

Couldn't you just keep checking until the click and then just ignore all input for 10ms remove all debounce and latency?
Actually, thnking further, I amend what I say to:

The ideal debounce for a very mechanically reliable button could be done lagessly only on the first state change after a delay, so you can avoid debounce-related latency -- since games often trigger actions on the press rather than the release. And that the mouse button is mechanically new enough that ultra-short debounce logic (<50ms) only on the releases, would be fully
reliable for your gaming habit


--

The button signal sequence is really something like: PRESS --> [button signal-flickers/bounces] --> [button signal '1' continuous] --> RELEASE --> [button signal flickers/bounces] --> [button signal '0' continuous].

On a good fresh mechanical sensor, you'd certainly have no problems detecting the initial state change and acting upon that immediately, but thereafter ignoring state changes for a number of milliseconds. This would work perfectly fine for games whose actions only depended on precision of press/release events, as long as button erraticness was less than a user's most rapid repeat fire-button pressing (as it is often the case, for a fresh/new button). But as a button wears down, button erraticness starts to require longer debounce logic.

This is really a good case for user-customizable debounce logic, as many gamers use their mouse harder than others. Even limited, such as a selection of 3 values, or a fully user-customizable value.

Code: Select all

Select Time for De-Bounce Logic:
         [ ] OFF: Not Recommended
         [X] eSports Ultrashort/New Mouse: 5ms
         [ ] Enthusaist Gamer: 25ms
         [ ] Old Mouse: 100ms
In this case, any state change (a press or a release event) shorter than the specific threshold, will be lagless and non-delayed.

An advanced (eSports league) user diagnostic utility would be included, to analyze whether the mouse has bounce issues or not. Mice would be tested before they leave the factory. This eSports-league mouse could have somewhat of price premium in exchange for a stronger debounce warranty (return mouse if 5ms debounce fails to be reliable within a time period, such as 90 days or 365 days). Logitech, Razer, etc, could be all over this.

The problem is most mice manufacturers use cookie-cutter debounce logic to cover "lowest common denominator", sometimes handicapping a fresh mouse (adding latency to button presses) in exchange for having no problems with older/worn mice. I think debounce logic is probably already customizable in some undocumented ways (registry, etc) on some mice, but officializing this with easy mouse utilities would be a good idea.

The truth is there really doesn't need to be debounce-related lag at all (not even +1ms) for brand new mice, as for a new microswitch, bounce is far faster than the best human rapid-fire pressing. That can easily be filtered-out laglessly. It only becomes a problem with older mice.

NOW....
On a very old mouse, it can be: PRESS --> [button signal-flickers/bounces a LOT] --> [button signal '1' mostly continuous but slightly erratic] --> RELEASE --> [button signal flickers/bounces a LOT] --> [button signal '0' mostly continuous but slightly erratic].

While filterable for Desktop use, this mouse is now [bleep] for competitive and eSports play, and you must get a new mouse, no sense in trying to continue to play with worn equipment. Now, in some mice, it still works fine because manufacturers often include a permanent button press/release delay to filter the slightly-erratic mostly-continuous signal. This permanent delay (sometimes tiny like 1ms) is junk, and not needed on brand new mice, but some mouse manufacturers seem to include it anyway so they have fewer warranty claims. Perhaps this could be a second debounce setting:

Code: Select all

Select Time for STATE-CHANGE De-Bounce Logic:
         [ ] OFF: Not Recommended
         [X] 5ms: eSports Ultrashort/New Mouse
         [ ] 25ms: Enthusaist Gamer
         [ ] 100ms: Old Mouse
        NOTE: All button state changes are lagless after the specified threshold.

Select Time for STATE-HOLD De-Bounce Logic:
         [ ] OFF: eSports/New Mouse Lagless Mode
         [X] 0.1ms: eSports/New Mouse Accidental Itchy Finger Filter
         [ ] 1ms: Enthusaist Gamer
         [ ] 10ms: Old Mouse
        NOTE: This number adds a permanent button-release delay in exchange for trigger-finger reliability.
(If for specific high end mice, button presses give internal microcontroller analog value between 0 and 1, due to varying pressure or varying resistance values on a mouse button, then additional settings might be required for customizable button-pressure).

So, Logitech/Razer, if you are reading these forums, here's your cue for a premium eSports mouse with lagless debounce modes.

Re: Measure button to pixel full input lag

Posted: 09 Jan 2017, 14:39
by Sparky
Chief Blur Buster wrote:
Sparky wrote:
lexlazootin wrote:
Chief Blur Buster wrote:The ideal debounce for a very mechanically reliable button could be done only on the button-release end, so you can avoid MOUSEDOWN latency -- since games often trigger actions on the press rather than the release. And that the mouse button is mechanically new enough that ultra-short debounce logic (<50ms) only on the releases, would be fully reliable for your gaming habit
I'm really not too sure if i understand.

So are you saying that RIGHT NOW mouse debounce is only applied to the mouse-down but not on the mouse-up? if that's the case wouldn't you have the same electrical bouncing interference ether way? It doesn't make any sense to me.

Couldn't you just keep checking until the click and then just ignore all input for 10ms remove all debounce and latency?
Actually, thnking further, I amend what I say to:

The ideal debounce for a very mechanically reliable button could be done lagessly only on the first state change after a delay, so you can avoid debounce-related latency -- since games often trigger actions on the press rather than the release. And that the mouse button is mechanically new enough that ultra-short debounce logic (<50ms) only on the releases, would be fully
reliable for your gaming habit


--

The button signal sequence is really something like: PRESS --> [button signal-flickers/bounces] --> [button signal '1' continuous] --> RELEASE --> [button signal flickers/bounces] --> [button signal '0' continuous].

On a good fresh mechanical sensor, you'd certainly have no problems detecting the initial state change and acting upon that immediately, but thereafter ignoring state changes for a number of milliseconds. This would work perfectly fine for games whose actions only depended on precision of press/release events, as long as button erraticness was less than a user's most rapid repeat fire-button pressing (as it is often the case, for a fresh/new button). But as a button wears down, button erraticness starts to require longer debounce logic.

This is really a good case for user-customizable debounce logic, as many gamers use their mouse harder than others. Even limited, such as a selection of 3 values, or a fully user-customizable value.

Code: Select all

Select Time for De-Bounce Logic:
         [ ] OFF: Not Recommended
         [X] eSports Ultrashort/New Mouse: 5ms
         [ ] Enthusaist Gamer: 25ms
         [ ] Old Mouse: 100ms
In this case, any state change (a press or a release event) shorter than the specific threshold, will be lagless and non-delayed.

An advanced (eSports league) user diagnostic utility would be included, to analyze whether the mouse has bounce issues or not. Mice would be tested before they leave the factory. This eSports-league mouse could have somewhat of price premium in exchange for a stronger debounce warranty (return mouse if 5ms debounce fails to be reliable within a time period, such as 90 days or 365 days). Logitech, Razer, etc, could be all over this.

The problem is most mice manufacturers use cookie-cutter debounce logic to cover "lowest common denominator", sometimes handicapping a fresh mouse (adding latency to button presses) in exchange for having no problems with older/worn mice. I think debounce logic is probably already customizable in some undocumented ways (registry, etc) on some mice, but officializing this with easy mouse utilities would be a good idea.

The truth is there really doesn't need to be debounce-related lag at all (not even +1ms) for brand new mice, as for a new microswitch, bounce is far faster than the best human rapid-fire pressing. That can easily be filtered-out laglessly. It only becomes a problem with older mice.

NOW....
On a very old mouse, it can be: PRESS --> [button signal-flickers/bounces a LOT] --> [button signal '1' mostly continuous but slightly erratic] --> RELEASE --> [button signal flickers/bounces a LOT] --> [button signal '0' mostly continuous but slightly erratic].

While filterable for Desktop use, this mouse is now [bleep] for competitive and eSports play, and you must get a new mouse, no sense in trying to continue to play with worn equipment. Now, in some mice, it still works fine because manufacturers often include a permanent button press/release delay to filter the slightly-erratic mostly-continuous signal. This permanent delay (sometimes tiny like 1ms) is junk, and not needed on brand new mice, but some mouse manufacturers seem to include it anyway so they have fewer warranty claims. Perhaps this could be a second debounce setting:

Code: Select all

Select Time for STATE-CHANGE De-Bounce Logic:
         [ ] OFF: Not Recommended
         [X] 5ms: eSports Ultrashort/New Mouse
         [ ] 25ms: Enthusaist Gamer
         [ ] 100ms: Old Mouse
        NOTE: All button state changes are lagless after the specified threshold.

Select Time for STATE-HOLD De-Bounce Logic:
         [ ] OFF: eSports/New Mouse Lagless Mode
         [X] 0.1ms: eSports/New Mouse Accidental Itchy Finger Filter
         [ ] 1ms: Enthusaist Gamer
         [ ] 10ms: Old Mouse
        NOTE: This number adds a permanent button-release delay in exchange for trigger-finger reliability.
(If for specific high end mice, button presses give internal microcontroller analog value between 0 and 1, due to varying pressure or varying resistance values on a mouse button, then additional settings might be required for customizable button-pressure).

So, Logitech/Razer, if you are reading these forums, here's your cue for a premium eSports mouse with lagless debounce modes.
If you use the normally closed contact of the switch for debouncing you can avoid all of these delays. If the normally closed contact is closed, the button is definitely not pressed, if the normally open contact is closed, the switch is definitely pressed. If both switches are open, maintain current state.

There are a couple ways to implement this on the PCB, one is to use two pins of the microcontroller connected to the normally open and normally closed pins of the switch with pullup resistors, and ground the common contact, the other is to connect the common contact to your input pin(maybe with a small cap and schmitt trigger to filter out any noise), and connect the other two contacts to the positive rail and ground.