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 🙁
so how will this translate to movement on screen?
Forget what I said, the accumulation + division is enough.
any new news on this?
I don't have enough time to code and test all the stuffs I wanted for the next version.
I will try to build a new package tonight.