Category: Mouse translation

This post explains a mechanism for the mouse to stick translation, that allows to reach a better precision and that is required to perform a 1:1 translation.

If you don’t want to read some math, then skip this post 🙂

All values are considered positive so as to simplify the explanation.

Each 10 ms, the sixaxis emulator processes all pending events.
All mouse motion events are merged and as a result, a single mouse event is processed.
This mouse event contains cumulated x and y deltas: (dx1, dy1).

This motion vector is then translated into a stick position according to the following formula:
  (1) pos1 = dz1 + mul * pow(mv1, exp)
pos1 = desired stick position (real)
dz1 = deadzone (real, function of dx1, dy1 and the deadzone shape)
mv1 = mouse value (integer), dx1 or dy1
mul = multiplier (real, constant)
exp = exponent (real, constant)

The result pos1 is a real. But the final stick position has to be an integer.
What emuclient was doing previously is rounding pos1 to the nearest integer.
This obviously results into a lower or higher speed than the desired one.
A much more precise solution to tackle this real to integer conversion is to truncate pos1, and compute a mouse vector remainder to be added next iteration.

The mouse event that corresponds to the applied stick position is: (dx2, dy2).
dx2 and dy2 are reals.
  (2) pos2 = dz1 + mul * pow(mv2, exp)
pos2 = applied stick position (truncate(pos1), integer)
dz1 = deadzone (same value, the angle is considered to be the same)
mv2 = mouse value (real), dx2 or dy2
mul = multiplier (real, constant)
exp = exponent (real, constant)

Note: norm(mv1) >= norm(mv2)
  (3) vrem = mv1 - mv2
vrem = mouse vector remainder
mv1 is known.
mv2 is computed from (2):
  (4) mv2 = pow[(pos2 - dz1)/mul, 1/exp]
mv2 can be replaced in (3):
  (5) vrem = mv1 - pow[(pos2 - dz1)/mul, 1/exp]
Conclusion:

• (5) gives the mouse vector remainder that has to be added the next iteration
• this emulates a subposition precision

Notes:

• this is useful with 8-bit precision for stick axes as the speed difference between two neighbor stick positions is high
• this is useless with 16-bit precision for stick axes

Last mouse mapping improvement was about tweaking the dead zone shape, and was proposed by a reader of this blog. Another reader suggested me to change the way the mouse motion is processed.

The sixaxis emulator currently approximates the velocity from the mouse report average over 10ms (=the sixaxis report period). For ex, if it receives N mouse reports, it assumes a constant 10/N ms period.

Example 1:

t0-1ms report x = some value
t0 all mouse report processed, a report is sent to the ps3, x = 0
t0 report x = +10
t0+1ms report x = +8
t0+2ms report x = +6
t0+3ms report x = +4
t0+4ms report x = +2
... no other report
t0+10ms all mouse report processed, a report is sent to the ps3

5 reports, report period is approximated to 2ms.
Mouse report average: (10+8+6+4+2)/5 = 6 units/ms

Well, this is overestimated.

With a simple accumulation + division:
Mouse report average: (10+8+6+4+2)/10 = 3 units/ms

For this example, the computed velocity is 2x the real one o_O

This is not harmful if the computed velocity is always 2x the real one.
But let’s take another example.

Example 2:

t0-1ms  report x = some value
t0      all mouse report processed, a report is sent to the ps3, x = 0
t0      report x = +10
t0+1ms  report x = +8
t0+2ms  report x = +6
...     no other report
t0+10ms all mouse report processed, a report is sent to the ps3

3 reports, report period is approximated to 3/10ms.
Mouse report average: (10+8+6)/3 = 8 units/ms

With a simple accumulation + division:
Mouse report average: (10+8+6)/10 = 2.4 units/ms

For this example, the computed velocity is 3.33x the real one…

The previous computation was introducing a non constant multiplier 🙁

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!