# Mouse mapping improvement

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.

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!

## 2 Replies to “Mouse mapping improvement”

1. 4659d900-34bb-11e0-b899-000bcdcb8a73 says:

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.

2. matlo says: