From df26bc2e9778cdc717aab362af2b876ba1a9b6a8 Mon Sep 17 00:00:00 2001 From: Jacob Palecki Date: Sat, 11 Sep 2021 14:59:32 -0700 Subject: Add lp norm new info to doc --- doc/Guide.md | 1 + 1 file changed, 1 insertion(+) (limited to 'doc') diff --git a/doc/Guide.md b/doc/Guide.md index a0bc1ca..b5f4786 100644 --- a/doc/Guide.md +++ b/doc/Guide.md @@ -58,6 +58,7 @@ There are anisotropic settings for whole mode. - **Lp Norm**. The distance calculation can be generalized to ((in_x)^p + (in_y)^p)^(1/p)), bringing the calculation into [Lp space](https://en.wikipedia.org/wiki/Lp_space). - p = 2 is then the "real world" value, yielding the pythagorean theorem as the distance calculation. - Increasing p makes distances for diagonal movements (where in_x and in_y are close) smaller, and increases the dominance of the larger of the two in determining the distance. + - As p gets large, the above calculation approaches max(inx, iny). Raw Accel uses this formula when given any p > 64. - We recommend almost everyone leave this at 2. ![AnisotropyExample](images/anisotropy_example.png) -- cgit v1.2.3 From fdab3cf830e1bf87bc0bd3b72339be14265c7338 Mon Sep 17 00:00:00 2001 From: Jacob Palecki Date: Mon, 20 Sep 2021 23:41:36 -0700 Subject: Change disable button to reset, update doc text --- doc/Guide.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/Guide.md b/doc/Guide.md index b5f4786..0e52721 100644 --- a/doc/Guide.md +++ b/doc/Guide.md @@ -92,6 +92,8 @@ An offset, sometimes called a threshold, is a speed in counts before acceleratio ### Caps A cap is a point after which acceleration is not applied. The legacy way of applying an offset is simply applying the minimum of the cap sensitivity and the calculated sensitivity for any acceleration calculation. Thus, for the legacy "sensitivity cap" the value given is a sensitivity. This cap style is still available but causes a large discontinuity at the point of offset, leading to a non-smooth feeling at cap cross. The new default "gain cap" effectively caps the gain, but for internal calculation reasons, does so for a given speed rather than a given gain value. This feels much smoother but might have a large effect on sensitivity as gain generally raises faster than sensitivity. We recommend that users use a gain cap and simply adjust it to hit at the gain equivalent to the sensitivity they'd like to cap at. The theory behind "gain caps" is developed in [this document](https://docs.google.com/document/d/1FCpkqRxUaCP7J258SupbxNxvdPfljb16AKMs56yDucA). +Caps are only applicable to the Classic, Linear, and Power modes. The capping point can be defined in terms of an input speed, an output ratio, or both (which will then set other acceleration parameters for the mode.) + ### Anisotropy See "Horizontal and Vertical" in the philosophy section to understand what these options do. @@ -113,7 +115,9 @@ This is the style found in Quake 3, Quake Live, and countless inspired followers ![ClassicExample](images/classic_example.png) ### Power -This is the style found in CS:GO and Source Engine games (m_customaccel 3). The user can set a rate by which the speed is multiplied, and then an exponent to which the product is raised, which is then the final multiplier (no adding to 1). In the aforementioned games the default m_customaccel_exponent value of 1.05 would be a value of 0.05 in Raw Accel, leading to a concave slowly rising curve. CS:GO and Source Engine games apply acceleration in an fps-dependent manner, so Raw Accel can only simulate acceleration from these games at a given fps. To do so, set scale to 1000/(in-game fps). +This is the style found in CS:GO and Source Engine games (m_customaccel 3). The user can set a rate by which the speed is multiplied, and then an exponent to which the product is raised, which is then the final multiplier (no adding to 1). The formula for this curve starts at 0 for an input of 0, so the user can also set a ratio of the sens multiplier for the curve to start at, effectively an output offset. + +In the aforementioned games the default m_customaccel_exponent value of 1.05 would be a value of 0.05 in Raw Accel, leading to a concave slowly rising curve. CS:GO and Source Engine games apply acceleration in an fps-dependent manner, so Raw Accel can only simulate acceleration from these games at a given fps. To do so, set scale to 1000/(in-game fps) and the output offset to 1. ![PowerExample](images/power_example.png) ### Natural -- cgit v1.2.3 From 3287619c110c5f1abcdddf700d24b31431155993 Mon Sep 17 00:00:00 2001 From: Jacob Palecki Date: Tue, 21 Sep 2021 00:04:14 -0700 Subject: Add updated guide pics --- doc/Guide.md | 5 +++++ doc/images/LUT_example.png | Bin 55969 -> 65568 bytes doc/images/accel_readme_example.png | Bin 50019 -> 65975 bytes doc/images/anisotropy_example.png | Bin 62022 -> 55900 bytes doc/images/classic_example.png | Bin 54866 -> 65169 bytes doc/images/jump_example.png | Bin 47816 -> 59152 bytes doc/images/linear_example.png | Bin 50547 -> 65667 bytes doc/images/motivity_example.png | Bin 50916 -> 63762 bytes doc/images/natural_gain_example.png | Bin 50679 -> 62130 bytes doc/images/power_example.png | Bin 50340 -> 64430 bytes 10 files changed, 5 insertions(+) (limited to 'doc') diff --git a/doc/Guide.md b/doc/Guide.md index 0e52721..a06dc91 100644 --- a/doc/Guide.md +++ b/doc/Guide.md @@ -83,12 +83,17 @@ The authors of this program feel that Whole is the best style for most users, bu ## Features +### Sensitivity Multiplier +As described above, the "sensitivity multiplier" parameter is a multiplier used on the post-calculation output vector. The "Y/X Ratio" parameter is then only applied to the Y component of the output, so that it defines the ratio of vertical to horizontal output sensitivity without acceleration. + ### Gain Switch The acceleration curve styles below (see "Acceleration Styles") each describe a certain shape mathematically. The gain switch determines whether that shape is applied in the sensitivity graph or the gain graph. For styles Linear, Classic, and Power, this setting does not change the possible shapes of the velocity curve - that is, for any particular settings with the gain switch set to Sensitivity, there is a different set of settings that will replicate the exact same velocity curve (output for a given hand motion) with the switch set to Gain. For styles Natural, Jump, and Motivity, this is not true, and the gain switch allows new velocity curves for each style. ### Offsets An offset, sometimes called a threshold, is a speed in counts before acceleration "kicks in". The legacy way of applying an offset is having a multiplier of 1 below and at the offset, and applying the sensitivity of (speed-offset) above. This legacy "sensitivity offset" is not available because it causes a discontinuity in gain at the point of offset, leading to non-smooth feeling at offset cross. The new "gain offset" does a little extra math to simply shift the gain graph by the offset amount without any discontinuity. This feels smoother and has almost no effect on sensitivity. The theory behind "gain offsets" is developed in [this document](https://docs.google.com/document/d/1P6LygpeEazyHfjVmaEygCsyBjwwW2A-eMBl81ZfxXZk). +Offsets are only applicable to the Classic, Linear, and Natural modes, where they are defined in terms of an input speed. Power mode has a special "output offset", where the curve "starts from" some ratio of the sens multiplier, described in its section. + ### Caps A cap is a point after which acceleration is not applied. The legacy way of applying an offset is simply applying the minimum of the cap sensitivity and the calculated sensitivity for any acceleration calculation. Thus, for the legacy "sensitivity cap" the value given is a sensitivity. This cap style is still available but causes a large discontinuity at the point of offset, leading to a non-smooth feeling at cap cross. The new default "gain cap" effectively caps the gain, but for internal calculation reasons, does so for a given speed rather than a given gain value. This feels much smoother but might have a large effect on sensitivity as gain generally raises faster than sensitivity. We recommend that users use a gain cap and simply adjust it to hit at the gain equivalent to the sensitivity they'd like to cap at. The theory behind "gain caps" is developed in [this document](https://docs.google.com/document/d/1FCpkqRxUaCP7J258SupbxNxvdPfljb16AKMs56yDucA). diff --git a/doc/images/LUT_example.png b/doc/images/LUT_example.png index 71f9ce3..96567d1 100644 Binary files a/doc/images/LUT_example.png and b/doc/images/LUT_example.png differ diff --git a/doc/images/accel_readme_example.png b/doc/images/accel_readme_example.png index 1622011..a23f9e4 100644 Binary files a/doc/images/accel_readme_example.png and b/doc/images/accel_readme_example.png differ diff --git a/doc/images/anisotropy_example.png b/doc/images/anisotropy_example.png index 6425e68..f8dd09c 100644 Binary files a/doc/images/anisotropy_example.png and b/doc/images/anisotropy_example.png differ diff --git a/doc/images/classic_example.png b/doc/images/classic_example.png index 58ca915..d51f693 100644 Binary files a/doc/images/classic_example.png and b/doc/images/classic_example.png differ diff --git a/doc/images/jump_example.png b/doc/images/jump_example.png index 770bab2..1d59134 100644 Binary files a/doc/images/jump_example.png and b/doc/images/jump_example.png differ diff --git a/doc/images/linear_example.png b/doc/images/linear_example.png index be1410e..29345d1 100644 Binary files a/doc/images/linear_example.png and b/doc/images/linear_example.png differ diff --git a/doc/images/motivity_example.png b/doc/images/motivity_example.png index 6041ec6..0c2441b 100644 Binary files a/doc/images/motivity_example.png and b/doc/images/motivity_example.png differ diff --git a/doc/images/natural_gain_example.png b/doc/images/natural_gain_example.png index 3b66dbe..49784e6 100644 Binary files a/doc/images/natural_gain_example.png and b/doc/images/natural_gain_example.png differ diff --git a/doc/images/power_example.png b/doc/images/power_example.png index 414a252..d41ad52 100644 Binary files a/doc/images/power_example.png and b/doc/images/power_example.png differ -- cgit v1.2.3 From fc8b97efee3c9d9f80d40b7ee154c96e4e4db0c0 Mon Sep 17 00:00:00 2001 From: Jacob Palecki Date: Tue, 21 Sep 2021 00:06:55 -0700 Subject: Small tweaks --- doc/Guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/Guide.md b/doc/Guide.md index a06dc91..9b2af44 100644 --- a/doc/Guide.md +++ b/doc/Guide.md @@ -130,7 +130,7 @@ Natural features a concave curve which starts at 1 and approaches some maximum s ![NaturalGainExample](images/natural_gain_example.png) ### Jump - This style applies one sensitivity below a certain threshold, and another above it. It can be useful for those who want one constant sensitivity and gain for slow hand motions and a different constant sensitivity or gain for fast hand motions. Users can set a "smooth" parameter which dictates whether the jump happens instaneously (at smooth 0) or with a slight tailing in and out (smooth 1) leading to a small sigmoid shape (s-shape). (Note that this "smooth" parameter has nothing to do with averaging over mouse counts like in sensor smoothing on mice or mouse smoothing in games.) + This style applies one sensitivity or gain below a certain threshold, and another above it. It can be useful for those who want one constant sensitivity and gain for slow hand motions and a different constant sensitivity or gain for fast hand motions. Users can set a "smooth" parameter which dictates whether the jump happens instaneously (at smooth 0) or with a slight tailing in and out (smooth 1) leading to a small sigmoid shape (s-shape). (Note that this "smooth" parameter has nothing to do with averaging over mouse counts like in sensor smoothing on mice or mouse smoothing in games.) ![NaturalGainExample](images/jump_example.png) ### Motivity -- cgit v1.2.3 From 9175f0a172285321f740e62f80494ddfba303fcf Mon Sep 17 00:00:00 2001 From: a1xd <68629610+a1xd@users.noreply.github.com> Date: Wed, 22 Sep 2021 21:06:23 -0400 Subject: docs - add win10 as prereq --- doc/Guide.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/Guide.md b/doc/Guide.md index 9b2af44..1bed260 100644 --- a/doc/Guide.md +++ b/doc/Guide.md @@ -5,9 +5,9 @@ Visit the [Releases page](https://github.com/a1xd/rawaccel/releases) and navigat ## Installation - **Prerequisites** + * Windows 10 * Visual C++ 2019 runtime, [download here](https://aka.ms/vs/16/release/vc_redist.x64.exe) * .NET Framework 4.7.2+ runtime, [download here](https://dotnet.microsoft.com/download/dotnet-framework/net48) - * **For Windows 7 users only** — SHA-2 code signing support (download through Windows Update) - Run `installer.exe` in the release directory to install the Raw Accel driver. Restart your computer for the installation to take effect. @@ -69,7 +69,7 @@ With all anisotropic settings considered, the full formula looks like: This can be more easily understood as - (out_x, out_y) = (in_x\*sens_x, in_y\*sens_y) \* ((f( domain-weighted lp-space speed) - 1) \* (directional weight) + 1), where f(v) is our sensitivity function -This formula gaurantees the smooth transition from the horizontal to vertical curve and vice versa as the user moves their hand diagonally. +This formula guarantees the smooth transition from the horizontal to vertical curve and vice versa as the user moves their hand diagonally. #### ***By Component*** In this case, the horizontal components are separated and each is given as input to the sensitivity calculation to multiplied by itself before being recombined at output. -- cgit v1.2.3 From 867c16cf8fcd4009066d1fff2c8f90f85d14c67f Mon Sep 17 00:00:00 2001 From: a1xd <68629610+a1xd@users.noreply.github.com> Date: Fri, 24 Sep 2021 01:48:34 -0400 Subject: update docs with notes on dpi norm --- doc/Guide.md | 14 +++++++++++--- doc/images/motivity_example.png | Bin 63762 -> 89155 bytes 2 files changed, 11 insertions(+), 3 deletions(-) (limited to 'doc') diff --git a/doc/Guide.md b/doc/Guide.md index 1bed260..29e2ec0 100644 --- a/doc/Guide.md +++ b/doc/Guide.md @@ -105,11 +105,19 @@ See "Horizontal and Vertical" in the philosophy section to understand what these ### Last Mouse Move The Raw Accel GUI reads the output of the raw input stream, and thus the output of the Raw Accel Driver, and displays on the graphs red points corresponding to the last mouse movements. These calulations should be fast and your graph responsive, but it comes at the cost of higher CPU usage due to needing to refresh the graph often. This feature can be turned off in the "Charts" menu. -### Scale by DPI and Poll Rate -This option does not scale your acceleration curve in any way. Rather, DPI scales the set of points used to graph your curve, and shows you a window of input speed relevant for your chosen DPI. The poll rate is used as a safeguard for the Last Mouse Move points and therefore should be set for accuracy in that measurement. +### Menu Options + +#### Charts >> Scale by DPI and Poll Rate +These options does not scale your acceleration curve in any way. Rather, DPI scales the set of points used to graph your curve, and shows you a window of input speed relevant for your chosen DPI. The poll rate is used as a safeguard for the Last Mouse Move points and therefore should be set for accuracy in that measurement. + +#### Advanced >> Device Menu +This menu provides options for individually disabling devices, and normalizing device DPI (see next section). Here you will also find an option for setting polling rate, which signals the driver to forgo the standard automatic rate adjustment. Leave this at 0 unless you are experiencing cursor stutters that only occur with acceleration enabled. + +#### DPI Normalization +Setting the DPI option for a device to its actual DPI will scale its input so that the sensitivity and acceleration feels as if it were set to 1000 dpi. For example, with a sens multiplier of 0.8, mice with their DPI set in the device menu will have the equivalent sensitivity of an 800 DPI mouse with a sens multiplier of 1. Ignoring device-specific factors like weight, friction, and sensor position, normalization provides an easy method to synchronize settings across different setups. ## Acceleration Styles -The examples of various types below show some typical settings, without a cap or offset, for a mouse at 1600 DPI and 1000 hz. +The examples of various types below show some typical settings for a mouse at, or normalized to, 1000 DPI. ### Linear This is simplest style used by most; it is simply a line rising at a given rate. This is a good choice for new users. diff --git a/doc/images/motivity_example.png b/doc/images/motivity_example.png index 0c2441b..e9f719e 100644 Binary files a/doc/images/motivity_example.png and b/doc/images/motivity_example.png differ -- cgit v1.2.3 From 0156677fbbf05f884a0baaddfd5f4821dcf73ebb Mon Sep 17 00:00:00 2001 From: Jacob Palecki Date: Thu, 23 Sep 2021 23:01:24 -0700 Subject: Add note about normalization --- doc/Guide.md | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc') diff --git a/doc/Guide.md b/doc/Guide.md index 29e2ec0..695e336 100644 --- a/doc/Guide.md +++ b/doc/Guide.md @@ -116,6 +116,8 @@ This menu provides options for individually disabling devices, and normalizing d #### DPI Normalization Setting the DPI option for a device to its actual DPI will scale its input so that the sensitivity and acceleration feels as if it were set to 1000 dpi. For example, with a sens multiplier of 0.8, mice with their DPI set in the device menu will have the equivalent sensitivity of an 800 DPI mouse with a sens multiplier of 1. Ignoring device-specific factors like weight, friction, and sensor position, normalization provides an easy method to synchronize settings across different setups. +This is still an experimental setting, which perhaps will be more clearly presented in the future. For now, users with DPI less than 1000 should set their sensitivity multiplier to no greater than their DPI divided by 1000 to avoid pixel skipping on desktop (with 6/11 window sensitivity.) + ## Acceleration Styles The examples of various types below show some typical settings for a mouse at, or normalized to, 1000 DPI. -- cgit v1.2.3 From e9705ec68e4672b6819fc74b78716dcf32297ea8 Mon Sep 17 00:00:00 2001 From: Jacob Palecki Date: Thu, 23 Sep 2021 23:02:39 -0700 Subject: make note clearer --- doc/Guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/Guide.md b/doc/Guide.md index 695e336..2569af8 100644 --- a/doc/Guide.md +++ b/doc/Guide.md @@ -116,7 +116,7 @@ This menu provides options for individually disabling devices, and normalizing d #### DPI Normalization Setting the DPI option for a device to its actual DPI will scale its input so that the sensitivity and acceleration feels as if it were set to 1000 dpi. For example, with a sens multiplier of 0.8, mice with their DPI set in the device menu will have the equivalent sensitivity of an 800 DPI mouse with a sens multiplier of 1. Ignoring device-specific factors like weight, friction, and sensor position, normalization provides an easy method to synchronize settings across different setups. -This is still an experimental setting, which perhaps will be more clearly presented in the future. For now, users with DPI less than 1000 should set their sensitivity multiplier to no greater than their DPI divided by 1000 to avoid pixel skipping on desktop (with 6/11 window sensitivity.) +This is still an experimental setting, which perhaps will be more clearly presented in the future. For now, users should set their sensitivity multiplier to no greater than their DPI divided by 1000 to avoid pixel skipping on desktop (with 6/11 window sensitivity.) ## Acceleration Styles The examples of various types below show some typical settings for a mouse at, or normalized to, 1000 DPI. -- cgit v1.2.3