Blur Busters Forums

Who you gonna call? The Blur Busters! For Everything Better Than 60Hz™ Skip to content

spacediver and ad8e public collaboration [reaction research]

Talk to software developers and aspiring geeks. Programming tips. Improve motion fluidity. Reduce input lag. Come Present() yourself!

Re: spacediver and ad8e public collaboration [reaction resea

Postby ad8e » 15 Jul 2019, 17:19

spacediver wrote:I've spent too much time today trying to overclock my other mouse (the one with higher cpi) to 1000 hz, as it's currently stuck on 125hz. No success. I can pick up this mouse for about $15 down the street: ... ming-mouse

That mouse doesn't mention its sensor, so its sensor is probably something extremely misleading and useless. You want something from this list: ... t-perfect/
Or this one:
I just bought another G403 for $30 from amazon, since my current one is sporadically turning off. That's a mark against it, but I hope the next one works. None of the mice on the market are problem-free. (Competitive gamers will probably want a mouse with lower click latency.)

spacediver wrote:I'm still not clear why the parallel and orthogonal "subcomponents" (with respect to XYVelocity) will show the "conceptually distinct parts of this [sweep] behaviour".

In my mind, the onset of the snap is associated with an abrupt change in regime of incoming force pulses.

Is the idea that if when this snap occurs, that the component-of-accel-and-jerk-that-show-the-greatest-change would be the component that is orthogonal to XYVelocity? And if so, is this primarily due to the rapid change in intensity of these pulses? Or the rapid change in direction of mouse movement?

It's a mixture of snaps changing orthogonal acceleration and force pulses causing problems with parallel acceleration. But I think you should ignore the pulse concept; that is too advanced.
The velocity direction won't change rapidly enough during a snap to be useful, if the mouse is already moving at a fast rate.
Note that the snap's acceleration won't necessarily be orthogonal to velocity the entire time: as the mouse starts to move left, it becomes parallel to the velocity between two timepoints, so the eventual snap detection will need an "overall downward direction" that considers a longer time period. But for the downward sweep alone, it's not necessary and velocities between timepoints are enough, given sufficient time and position resolution.
The reason why it's hard to assume that the person moves his mouse straight downward is that it's not really true; the mouse tends to have some error in angle. Maybe do0om's control over his mouse is good enough to make this negligible, but I don't know.

spacediver wrote:Ok, so we're solely concerned with the kinematics of the movement, rather than the direction (i.e. a valid sweep could be a horizontal one).

It's true that everything I've described is rotationally invariant, so that it will work on horizontal sweeps. You shouldn't put any horizontal sweeps in your test data, since those will have some different properties because of different muscles. But since you and do0om will be making the same downwards vertical movement, your code won't have to worry about this difference.
Posts: 59
Joined: 18 Sep 2018, 00:29

Re: spacediver and ad8e public collaboration [reaction resea

Postby ad8e » 15 Jul 2019, 17:30

Maybe it'll be easier if I build it, and I already own the necessary mouse. I think in two weeks I might have some time.
Posts: 59
Joined: 18 Sep 2018, 00:29

Re: spacediver and ad8e public collaboration [reaction resea

Postby spacediver » 15 Jul 2019, 21:04

Cool, I can take a crack at a simpler approach. If anything, would be a good exercise to compare the performance. Might even be fun to use high speed video as a ground truth reference.

And thanks for the link to the flawless sensor page, very useful.
Posts: 505
Joined: 18 Dec 2013, 23:51


Return to Software Developers / Low-Lag Code / Game Programming

Who is online

Users browsing this forum: No registered users and 1 guest