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.