Mouse Acceleration is framerate dependent

[wareya]

Desc:

High framerates cause mouse acceleration to affect view movement less than low framerates. Applies to m_customaccel 1, 2, and 3, in first person source engine games.

When mouse acceleration is calculated, it's "stronger" on input which happened during high frame times (low framerates) than it is on input which happened during low frame times. Most people in the competitive TF2 community that are aware of this bug believe that it happens because raw input samples per frame are being operated on with their original sizes, where half the framerate would cause twice the distance on a linear mouse movement, resulting in a higher mouse acceleration factor when using that longer-time input sample and a positive exponent.(*) This post is written with the assumption that this is the technical cause of the framerate dependency. Graph example: http://i.imgur.com/nSsyi6I.png

It's not mathematically possible to scale mouse acceleration between framerates absolutely perfectly, without subsampling input (causing more inaccuracies) or causing some form of smoothing (causing more inaccuracies). The simple solution of scaling, operating on, and unscaling input samples is the most common and most favorite way to scale input samples from varying sample timewindows for mouse acceleration.

Repro:

Set a high mouse acceleration exponent. (eg 1.6 with m_customaccel 3) Set the framerate cap to a very high value (eg 500fps -- note this requires a mouse with at least 500hz polling to work, otherwise use lower FPS values) and make sure it's maintained (I do by running a very basic hammer test map). Move the mouse from a point A to a point B at a sufficient and certain speed. Measure how far the view moved. Set the framerate cap to a very low value (eg 60fps) and do the same with the same distance and speed. Measure how far the view moved.

Notes:

(*) This is inherent, expected, and desired behavior when this specific type of mouse acceleration is applied to individual samples. However, when samples consist of different sizes of windows of time, it doesn't behave consistently. The further the exponent is from 1, and the further the samples' "sizes" vary (both value and time), the more extreme the discrepancy is (past the variance between sample value and time in the first place).

Other:

Many players that use mouse acceleration cap their framerate at a value which they can maintain 100% of the time, so that the acceleration settings they have are consistent. If mouse acceleration is "fixed" to be framerate independent, there should be a way to configure what level it's scaled to. That is to say: If mouse acceleration inconsistency is "fixed" by scaling raw mouse delta to frametime before acceleration, and scaling it back after applying mouse acceleration [ie: unscale(accelerate(scale(delta)))], then the "standard" frametime which raw delta is scaled to should be user configurable for all mouse acceleration forms (m_customaccel 1/2 vs 3), just as mouse acceleration already is.

This bug should be present in Portal, HL2, etc. It is definitely present in TF2 and CSS.

This bug should be platform and system independent.