So I have been using the loststone prototype for about a month, I have only been using my store bought mouse when I screw something up ðŸ™‚
Aside from the occasional physical issue, mainly the buttons falling off, I have only been having one issue. Sensitivity. If I set the CPI high enough(ex 4500) for the courser to travel the full length of the monitor with a reasonable spin of the ball, It is next to impossible to move the courser over a specific character on the first try. Some times even the 4th or 5th try, VERY annoying. Setting the CPI low enough(ex 540) for really nice small movements and it takes multiple turns of the ball to move the full length of the screen.
I originally thought that some very complicated math would be required to solve this issue. So I figured I would start out small to get an idea of what I needed to do to accelerate the courser across the screen when moved fast enough and yet still allow small intricate movements. Much to my amazement the first equation I came up with did exactly what I needed it to do.
After some tweaking of the denominator and CPI values I came up with the CPI at 540 and the following equation.
f(x) = ( |x| / 40 + 1) * x
f(x) = x | |
f(x) = ( |x| / 60 + 1) * x | |
f(x) = ( |x| / 40 + 1) * x | |
f(x) = ( |x| / 20 + 1) * x |
The red plot is the raw sensor input(both x and y coordinates). The rest are different values for the denominator, I am currently using the blue one.
One of the reasons this works so well is the way that rounding is done when casting a float to an int in C++. Well actually there is no rounding. For example if we solve for x = 6 we end up with 1.15 * 6 = 6.9 which when cast to and int is simply 6. When x = 7 we end up with 1.175 * 7 = 8.225 which then becomes 8. So the 6 smallest movements are not actually changed. And when the values do start changing it is a smooth progression to larger numbers.