Each polling period (=10ms=sixaxis refresh rate), emuclient processes all queued events.
This means that depending on the mouse refresh rate, emuclient may process one or several mouse motion events.
Examples:
- (rate=100Hz) => 1 event max
- (rate=500Hz) => 5 events max
- (rate=1000Hz) => 10 events max
In a single polling period, emuclient may receive several events, but only performs a single sixaxis status refresh. Therefore, mouse motion events have to be merged into a single one that is the average mouse motion event. This allows to reach a better precision since no event is ignored.
The average mouse motion event is translated to a sixaxis axis thanks to the following formula:
res=sign(val)*mul*pow(abs(val),exp)
I usually use exp=1 so that the simplified formula is:
res=mul*val
The dead zone has also to be removed:
if res>0: res=res+dz
if res<0: res=res-dz
Different multipliers, exponent and dead zones may be set for x and y mouse motions.
This calculation supposes the dead zone is rectangular.
Following to the suggestion of a reader, I decided to test a different dead zone shape.
With a circular dead zone:
if x!=0 and y!=0:
dz_x=dz*cos(atan(abs(y/x)))
dz_y=dz*sin(atan(abs(y/x)))
else:
dz_x=dz
dz_y=dz
I also improved the result precision by storing each intermediate result as a double (and not an integer). Only the final result is converted to an integer.
I built a test package for people that want to try these new things.
Just remember to set the same value for both x and y dead zones.
Let me know the results of your tests!
I only barely got to test the new package before my mouse broke (new one will be here next week). From what I could tell, however, the circle dead zone worked well. The only thing that was still odd was a slowing down at 90° and 270°. I'll take a closer look (using the new package you have posted), as soon as my new G500 mouse comes in.
Thanks for the adjustment!
I also observed that the speed of the circular movement (generated with ctrl+p) is not completely constant.
x and y are truncated to an integer, so that the applied speed can't be perfectly constant. But it still should be pi/2-periodic.