subjective notes to be tested tomorrow:
old pc, de_nuke ct spawn, max graphics settings (heavily gpu-limited rendering)
mat_queue_mode 0: ~111fps, reference
mat_queue_mode 1: ~111fps, feels same as reference
mat_queue_mode 2: ~111fps, feels laggier than reference
fps_max 100
all three settings now feel more responsive than reference
edit:
actually, not sure. there are just my initial impressions, and of course biased by my existing knowledge
maybe mqm1 uncapped is better than mqm0 uncapped.
Measure button to pixel full input lag
Re: Measure button to pixel full input lag
I haven't noticed any clicks that failed to release over a couple thousand clicks with interrupt based latched debouncing, though that contact has only been worn mechanically, not electrically (because the mouse left that pin unconnected). There is a lot more bouncing on the NC contact than the NO contact(when the button is released or pressed respectively), but that is true of the new switch as well.flood wrote:ah yes the latch method
but the danger is if the switch is so worn that the release isn't registered
For latched debouncing we only need intermittent contact. By the time a switch has worn to the point where there isn't any signal whatsoever on the NC contact, the NO contact will be hopelessly worn as well, far beyond any single contact debouncing method I'm aware of.
I wasn't able to make it malfunction in this manner with simple finger pressure. While I was able to hold the NC contact open with finger pressure, it wasn't enough to keep the snap action from making momentary contact during a slow release. I believe it's a matter of rigidity, as the force increases during the snap action of the switch, and if the finger pressure doesn't increase as fast as the spring force, the common contact gains enough momentum to make NC contact. It was possible with a lever to release the button slowly enough that the switch didn't click on the release, and when this happened I was able to click the button down without the NC contact closing.
- Chief Blur Buster
- Site Admin
- Posts: 11653
- Joined: 05 Dec 2013, 15:44
- Location: Toronto / Hamilton, Ontario, Canada
- Contact:
Re: Measure button to pixel full input lag
In theory, with properly engineered hardware, the debounce is programmable on the computer end (which might send a signal to the mouse to use new microcontroller logic). In theory, you could adjust everything related to debounce logic in 100% software from the PC end -- e.g. debounce presses or releases or both, and adjust thresholds (10ms, 50ms 100ms, "X" ms, etc). I wish it was exposed in many more mouse drivers!
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. If it starts being less reliable, then just replace mouse or lengthen threshold via a theoretical advanced mouse control panel (if you're able to set a new threshold that's still acceptable, i.e. you're physically unable to click faster than the new debounce threshold).
Has any mouse manufacturers started exposing large numbers of adjustable settings for custom control of debounce logic?
To allow "Choose-Your-Own-Debounce-Logic" via Control Panel?
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. If it starts being less reliable, then just replace mouse or lengthen threshold via a theoretical advanced mouse control panel (if you're able to set a new threshold that's still acceptable, i.e. you're physically unable to click faster than the new debounce threshold).
Has any mouse manufacturers started exposing large numbers of adjustable settings for custom control of debounce logic?
To allow "Choose-Your-Own-Debounce-Logic" via Control Panel?
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter
Forum Rules wrote: 1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
2. Please report rule violations If you see a post that violates forum rules, then report the post.
3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!
Re: Measure button to pixel full input lag
I have done some tests with my new method with BenQ XL2540 and Asus PG248Q. Simple directx9 app (thanks blurbuster flood a lot!), vsync off, high fps. dunno why but I get only 6000-6700 fps depending on refresh rate.
Left mouse button changes screen color to black, right to white. raw mouse input. Camera captures black to white transition and LED at right mouse button.
Results are: I highlighted only same refresh rate.
app source: http://pastebin.com/XyfhU5nE
1200fps videos: https://drive.google.com/file/d/0B_8ge_ ... sp=sharing
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?
Left mouse button changes screen color to black, right to white. raw mouse input. Camera captures black to white transition and LED at right mouse button.
Results are: I highlighted only same refresh rate.
app source: http://pastebin.com/XyfhU5nE
1200fps videos: https://drive.google.com/file/d/0B_8ge_ ... sp=sharing
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?
- lexlazootin
- Posts: 1251
- Joined: 16 Dec 2014, 02:57
Re: Measure button to pixel full input lag
to get 16k i run at 800x600Q83Ia7ta wrote:dunno why but I get only 6000-6700 fps depending on refresh rate.
But yea, the results are very weird. I felt like if the monitor was made correctly it would have less latency.
Can you please send me the compiled windows version of your build, i would love to see if i can get that low latency with my mouse click, you using rinput or something?
- lexlazootin
- Posts: 1251
- Joined: 16 Dec 2014, 02:57
Re: Measure button to pixel full input lag
I'm really not too sure if i understand.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
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?
Like this?: http://imgur.com/wXr69FU
Re: Measure button to pixel full input lag
Depends on the switch, but probably not with mouse switches, as you get some really ugly intermittent contact when you release the button, so you're likely to get extra clicks. IMO the only good option is to use the normally open contact to decide the button has been pressed, and the normally closed contact to decide the button has been released. Preferably by using two pins on the microcontroller. The second best option is to connect the common contact of the switch to the microcontroller and the NC and NO pins of the switch to opposite power rails, though you'd want an extra resistor and cap in there to keep the pin from floating while you're putting pressure on the switch but not yet clicking it, and to smooth out the transition.lexlazootin wrote:I'm really not too sure if i understand.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
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?
Like this?: http://imgur.com/wXr69FU
Re: Measure button to pixel full input lag
Maybe its because of ghosting that you perform a little less with the benq I read in the hardware.info review that some pixel transitions took longer then 4ms. I think the asus also had a similar problem if you would run it at 180hz instead of 170hz. Could be if you tinker with the refresh rate or the overdrive it plays as well or better then the asus. It would be very strange if the monitor refresh rate influences a game that is not run with vsync and I have never heard of such a case. Skyrim and fallout behaved wrong with high refresh rate screens because they depended on vsync as their fps cap but quake does not care about that as far as I know.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?
Re: Measure button to pixel full input lag
nice work Q83Ia7ta
please keep us updated if you find out why you are doing worse on the 240hz
from your tests it doesn't seem to be related to input lag since that panel is still the fastest, i'm surprised it's such a small margin compared to a 144hz monitor, by the way did you also test the korean 220hz monitor ?
please keep us updated if you find out why you are doing worse on the 240hz
from your tests it doesn't seem to be related to input lag since that panel is still the fastest, i'm surprised it's such a small margin compared to a 144hz monitor, by the way did you also test the korean 220hz monitor ?
Re: Measure button to pixel full input lag
I didn't test it because i dissasebled monitor and used panel with ZisWorks 240Hz DVI board.dhaine wrote:from your tests it doesn't seem to be related to input lag since that panel is still the fastest, i'm surprised it's such a small margin compared to a 144hz monitor, by the way did you also test the korean 220hz monitor ?