The MarkC Windows 10 + 8.1 + 8 + 7 + Vista + XP Mouse Acceleration Fix Builder

The 'MarkC Windows 10 + 8.1 + 8 + 7 + Vista + XP Mouse Acceleration Fix Builder' is available for download from this link:
MarkC_Windows_10+8.x+7+Vista+XP_MouseFix_Builder_2.6.zip @ onedrive
(... then click the OneDrive Download button when it appears. Note this is NOT a direct download link.)

What is it?

It is a VBS script program that creates a registry .REG file that removes Windows' mouse acceleration, or emulates Windows 2000 or Windows 98/95 acceleration.

Fix Builder can build .REG files for Windows 10 or 8.1 or 8 or 7 or Vista or XP.

The registry fix created works like the CPL and Cheese and MarkC fixes, but is customized for your specific desktop display text size (DPI), your specific mouse pointer speed slider setting, your specific refresh rate and has any in-game pointer scaling/sensitivity factor you want (see note).

Fix Builder can create a fix that emulates Windows 2000 or Windows 98/95 acceleration.

WARNING:
On Windows 10 x64, when using fixes that emulate Windows 2000 or Windows 9X acceleration, only fixes with a single threshold can be used.
Using a 2 threshold emulation fix will cause BugChecks / Blue Screen of Death (BSOD)!

For older games that turn acceleration on, it gives the same response as position 6/11 does (1-to-1), without having to move the pointer speed slider to 6/11.
(Yeah, I know : "Whoop-de-do...")

Exactly 1-to-1 means no discarded or delayed mouse input while game playing.

Other Registry fixes need the pointer speed slider set to 6/11 (middle) to get exactly 1-to-1 in-game mouse to pointer response, but this script can create a registry fix that gives exact 1-to-1 in-game response for non-6/11 settings.

Other registry fixes only provide files for some pre-defined display DPI values: 100%, 125%..., but this script can create a fix for any DPI setting.

The Cheese registry fixes only provides files for some pre-defined monitor refresh rate values: 60Hz, 70Hz, but this script can create a fix for any refresh rate setting.

Fix Builder can create a fix with any in-game mouse-to-pointer scaling factor you want (see note).

NOTE: ALL registry based mouse fixes, INCLUDING this one, ONLY work when the
Control Panel > Mouse > 'Enhance pointer precision' option is ON (OR when an older game forces 'Enhance pointer precision' to ON), AND your game does not use DirectInput and does not use Raw Input for mouse input.

Eh? What is it again?

A mostly pointless sledgehammer solution to the problem of having to change your Control Panel > Mouse > pointer speed slider to 6/11 before you play an older game that needs a registry fix so you can avoid at most a single pixel of discarded or delayed mouse input while game playing...

A way to emulate Windows 2000 or Windows 98/95 acceleration.

An interesting programming exercise!

How do you use it?

• In Windows Explorer, double-click MarkC_Windows_10+8+7+Vista+XP_MouseFix_Builder.vbs,
  or double-click MarkC_Windows_10+8+7+Vista+XP_MouseFix_Builder.CMD.
  
  
• Verify or edit the suggested settings, clicking OK as you go.
  
  
• Add/Merge the created fix to the registry.
  (See below for non-Administrator account use.)
  
  
• Reboot or Log off to apply the fix (you have to reboot or Log off).
  
  
• If you don't use the mouse pointer speed slider set to 6/11, and you do want exact 1-to-1 in-game, then configure your game so that it enables control panel 'Enhance pointer precision'.
  If you want Windows 2000+98+95 acceleration in-game, then configure your game so that it enables control panel 'Enhance pointer precision'.
  (For example, in Counter-Strike: Source and other Source games, do use -useforcedmparms and don't use -noforcemspd. In Half-Life, CounterStrike 1.6, don't use -noforcemspd or -noforcemparms.)
  
  
• Enjoy exactly 1-to-1 mouse to pointer response for your custom desktop settings!
  (Or enjoy Windows 2000-like or Windows 98/95-like acceleration!)
  (If you applied one of the Windows 2000 or Windows 98/95 Acceleration fixes, then 'Enhance pointer precision' must be checked ON to enable it.)

Why do you need a fix?

Some older games turn Windows mouse acceleration on when you don't want them to. See here for more details.

You prefer the mouse acceleration that Windows 2000 or Windows 98/95 had.

How does the fix work?

The current system is queried, and you can change the values and tune the registry fix file created.
The result is saved to a file and can optionally be imported into the registry.

The script asks for:

• Operating system that the fix will be used for.
• The desktop Control Panel, Display, text size (DPI) that will be used.
• The in-game monitor refresh rate that will be used (XP and Vista only).
• The Control Panel, Mouse, pointer speed slider position that will be used.
• Windows-2000+98+95-style acceleration thresholds (optional).
• The pointer speed scaling (sensitivity) factor for that pointer speed setting.
• Where you want to save the fix to and what name.

It creates a registry .reg file with the settings entered, and optionally lets you merge / apply it into the registry.

How do you know the fix is working?

You can test if it is working by temporarily turning on the 'Enhance pointer precision' feature and see how the mouse responds.
(NOTE: Unless you applied one of the Windows 2000 or Windows 98/95 Acceleration fixes, only turn 'Enhance pointer precision' on for testing: it should normally be set OFF.)

If you have 'Enhance pointer precision' OFF, then the fix will not be active (but it will be waiting to be activated when needed).
Just as some games turn it on when you don't want them to, we can turn it on manually to test that the fix is working properly.

• Go to Control Panel, and select Hardware and Sound, then click Mouse. Select 'Pointer options' and check-ON/enable the 'Enhance pointer precision' option.
  
  
• See how the mouse responds.
  
  
• If you want, you can run the MouseMovementRecorder.exe program that is included in the ZIP file to see that the mouse and pointer movements are 1-to-1 and always the same (or are whatever custom scaling you entered).
  (The numbers in the MOUSE MOVEMENT column should be the same as the numbers in the POINTER MOVEMENT column. Any differences will appear in green or red.
  If you do see differences, also test with 'Enhance pointer precision' OFF, in case the problem is with Windows or MouseMovementRecorder.exe rather than a problem with the fix:
  - Press the A key on the keyboard while MouseMovementRecorder is running until EnPtPr Accel is Off.
  - When EnPtPr Accel is OFF, if there is a lot of red and green, press the '+' key on the keyboard and move the mouse.
  - Repeat '+' and move the mouse until most of the red and green disappears.
  - Press the A key on the keyboard to toggle EnPtPr Accel and move the mouse.
  - If the amount of red and green is roughly the same when EnPtPr Accel is ON as when EnPtPr Accel is Off, then the fix is working.)
  (NOTE: If you use Windows 10, & scaling of items is not 100%, see below.)
  (NOTE: If you use Windows 8.1 and have too much green and red, see below.)
  (NOTE: While running a game, you may see many red and green lines.
  Games that need a fix usually frequently re-position the pointer and this confuses MouseMovementRecorder.exe but DOES NOT mean acceleration.
  See http://www.esreality.com/?a=post&id=1846538#pid1927879 - scroll to 'Comment #271'.)
  
  
• If you have built a Windows 2000 or Windows 9X fix, you should see that acceleration varies depending upon how fast the mouse is, compared to the thresholds, but is linear (a constant sensitivity) between thresholds.
  (NOTE: See file !Threshold_Acceleration_ReadMe.txt in the ZIP file for more info.)
  
  
• Turn the 'Enhance pointer precision' option OFF when you have finished testing.
  (If you applied one of the Windows 2000 or Windows 98/95 Acceleration fixes, then leave 'Enhance pointer precision' checked ON to enable it.)

How do you know the fix is giving exact 1-to-1 when playing your game?

If you don't use the mouse pointer speed slider set to 6/11, and you do want exact 1-to-1 in-game, then you must configure your game so that it enables control panel 'Enhance pointer precision'.

You can test your game to see if it turns 'Enhance pointer precision' ON, and gets exact 1-to-1.

• Turn the 'Enhance pointer precision' option OFF,
• Run Mouse Movement Recorder (included in the ZIP file),
• Run your game (aim at something!) and look at the 'EnPtPr' column footer at the bottom of the Mouse Movement Recorder window.
  If it is displayed with a red background then the game has turned acceleration ON and will have exact 1-to-1.

How do you remove it?

• Open the ZIP file at the link above.
• If you use Windows 7 or Vista or XP:
  Select 'Windows_7+Vista+XP_Default.reg' and Double-click it.
• If you use Windows 8 or Windows 8.1 or Windows 10:
  Select 'Windows_10+8.x_Default.reg' and Double-click it.
• Answer Yes, OK to the prompts that appear.
• Reboot or Log off.

I use Windows 10 and scaling of text, apps and other items is not 100%

In later versions of Windows 10, Microsoft changed how the mouse pointer is moved in response to mouse input, when scaling of text, apps and other items is not 100%, and Enhance pointer precision is OFF.

Mouse pointer movements when Enhance pointer precision is OFF, are now scaled according to the per-monitor scaling of items setting.

When Enhance pointer precision is OFF, and the Control Panel pointer speed slider is set to 6/11, MouseMovementRecorder will not show all-black, exact 1-to-1, but instead Pointer Movement will be multiplied by the same scaling factor applied to text, apps and other items.

Games may also see this difference, or not, depending on their "DPI Awareness".

I use Windows 8.1 and see too much green and/or red in MouseMovementRecorder

Windows 8.1 introduced changes to mouse input processing to reduce power used and improve battery life:
Windows 8.1 delays and coalesces (merges) mouse input for programs, causing the effective mouse polling rate to be as low as 62 Hz in some cases (even for gaming mice with a higher polling rate).

This new processing can affect some games (games that don't use Raw Input and don't use DirectInput). Microsoft have a December 2013 Windows Update Rollup that includes a fix for those games, which will be automatically installed when you have Windows Update set to install updates automatically.
(See here: KB2908279 Mouse pointer stutters or freezes when you play certain games in Windows 8.1.)

The new processing can also affect MouseMovementRecorder and cause it to show red and green (with the mouse delays, MouseMovementRecorder sees a mouse movement from DirectInput, but doesn't see the pointer move until MUCH MUCH later and can't figure out what's going on and displays red and green).

If the KB2908279 update fix is installed, MouseMovementRecorder will activate it
to give more responsive mouse pointer movement and stop the red and green.

Otherwise, while running MouseMovementRecorder, select it and press the '+' key
on the keyboard a until the red and green stops.

If Control Panel, Appearance and Personalization, Display shows a 'Smaller...Larger' slider, high DPI monitors might need a custom size and/or a fix-builder fix to get exact 1-to-1.
See this blog article:
Windows 8.1 DPI Scaling Enhancements @ Extreme Windows Blog
The new multi-monitor DPI scaling in Windows 8.1 is a good thing if you have multiple monitors with different pixels-per-inch values, BUT it might make it harder to find the correct Item Size percentage when choosing which MarkC fix to use to get exact 1-to-1.
Try clicking the 'Let me choose one scaling level for all my displays' checkbox and then find the percentage needed so that your main (gaming) monitor looks the same as it did when using the 'Smaller...Larger' slider (this may require some reboots).
When you have the right percentage value, click '...one scaling level...' OFF (so that you get the benefit of the new Multi-monitor DPI scaling - if you need it) and use the percentage value to choose which fix you need, or to create a Fix-Builder fix.

Loading the fix with a non-administrator account

When adding the mouse acceleration fix to the registry, you may get one of these error messages:

"Cannot import (filename).reg: Not all data was successfully written to the registry."

"Part of the mouse acceleration fix can't be applied, because you are not logged in as an Administrator."

This error happens because part of the fix turns off acceleration for the Welcome screen (the log on screen).
If you use the Welcome screen (or the Windows Log in dialog) and acceleration is NOT turned off for the Welcome screen, then the MarkC fixes have a 1 pixel /1 mouse count error when the mouse changes direction left/right or up/down.

You can remove this 1 mouse count error by any of these methods:

• Run Disable_WelcomeScreen+Login_Accel.CMD as Administrator (Right-click > Run as administrator).
• Run MarkC_Windows_10+8+7+Vista+XP_MouseFix_Builder.CMD as Administrator.
• Add/Merge Disable_WelcomeScreen+Login_Accel.reg to the registry while logged in as an administrator.
• Run RegEdit.exe and edit 'HKEY_USERS\.DEFAULT\Control Panel\Mouse\MouseSpeed' to 0 (zero), while logged in as an administrator.
• Not moving or touching the mouse while using the Welcome screen (use arrow keys to select the user and Enter key to log in).
• Ignoring the 1 mouse count error! It's only a single count: You won't notice it.

The MarkC Windows 10 + 8.1 + 8 + 7 Mouse Acceleration Fix

The 'MarkC Windows 10 + 8.1 + 8 + 7 Mouse Acceleration Fix' is available for download from this link:
DO NOT USE THIS: MarkC_Windows_10+8.x+7_MouseFix.zip @ google drive (version 2.9).
Use this: MarkC_Windows_10+8.x+7_MouseFix.zip @ onedrive.com (version 2.9)
(... then click the OneDrive Download button when it appears. Note this is NOT a direct download link.)

For help for the fix, visit the ESReality MarkC Windows 7 Mouse Acceleration Fix page:
http://www.esreality.com/?a=post&id=1846538

What is it?

It is a registry file that removes Windows 7 or 8 or 8.1 or 10 mouse pointer acceleration.

It is like the CPL Mouse Fix and Cheese Mouse Fix, but gives exactly 1-to-1 mouse to pointer response for Windows 7 or Windows 8.x or Windows 10.

Exactly 1-to-1 means no discarded or delayed mouse input while game playing.

How do you use it?

• Find the display DPI that you currently use:
  Click Start, click Control Panel, select Appearance and Personalization, select Display.
  See if you have 100% or 125% or 150% selected.
  (On Windows 8.1 or 10, if you see a 'Smaller...Larger' slider, then:
  - the 1st slider position will be 100%,
  - the 2nd slider position will be 125%,
  - the 3rd slider position (might not be shown) will be 150%.)
  
  
• Open the ZIP file at the link above.
  
  
• Select the folder that matches the Windows version you use and Double-click it.
  
  
• Select the REG file that matches the DPI% you use and Double-click it.
  
  
• Answer Yes, OK to the prompts that appear.
  (See below for non-Administrator account use.)
  
  
• Reboot or Log off to apply the fix (you have to reboot or Log off).
  
  
• Enjoy exactly 1-to-1 mouse to pointer response!
  (If you applied one of the Windows 2000 or Windows 98/95 Acceleration fixes, then 'Enhance pointer precision' must be checked ON to enable it.)

Why do you need the fix?

If you don't know you need it, then you don't need it!

Some older games, such as Half-Life 1, Counter-Strike 1.x, Quake, Quake 2, Unreal and others, while they are active and running, call a Windows function intending to disable variable mouse acceleration by forcing ALL movement to be accelerated by the same amount (doubled).
On Windows 2000 and earlier, that removed all variable acceleration.
Pointing and aiming in those games was OK, because the mouse response was then linear (all movement was accelerated by the same amount; it was doubled).

In XP, and later Windows versions, Microsoft changed how mouse pointer acceleration worked.
Now when those games call the function (asking that all movement be accelerated), Windows enables the mouse 'Enhance pointer precision' feature, which adds mouse acceleration using a varying curve to control the mouse response. (It enables it even if you have it turned off in the Control Panel Mouse settings.)

With 'Enhance pointer precision' enabled, slower mouse movements make the pointer go extra slow and faster mouse movements make the pointer go extra fast. It is not linear and not straightline.

This is annoying, because where you are aiming at depends on how far you move your mouse, and also on how fast you moved the mouse to aim.

How does the fix work?

It redefines the curve used by the 'Enhance pointer precision' feature to be a completely straight line. The slope of the line is tuned so that every on-mouse-pad mouse movement is turned into exactly the same amount of on-screen pointer movement.

How do you know the fix is working?

You can test if it is working by temporarily turning on the 'Enhance pointer precision' feature and see how the mouse responds.
(NOTE: Unless you applied one of the Windows 2000 or Windows 98/95 Acceleration fixes, only turn 'Enhance pointer precision' on for testing: it should normally be set OFF.)

If you have 'Enhance pointer precision' OFF, then the fix will not be active (but it will be waiting to be activated when needed).
Just as some games turn it on when you don't want them to, we can turn it on manually to test that the fix is working properly.

• Go to Control Panel, and select Hardware and Sound, then click Mouse. Select 'Pointer options' and check-ON/enable the 'Enhance pointer precision' option.
  
  
• See how the mouse responds.
  
  
• If you want, you can set the Control Panel 'pointer speed' slider set to the 6th, middle position and run the MouseMovementRecorder.exe program that is included in the ZIP file to see that the mouse and pointer movements are 1-to-1 and always the same.
  (The numbers in the MOUSE MOVEMENT column should be the same as the numbers in the POINTER MOVEMENT column. Any differences will appear in green or red.
  If you do see differences, also test with 'Enhance pointer precision' OFF, in case the problem is with Windows or MouseMovementRecorder.exe rather than a problem with the fix:
  - Press the A key on the keyboard while MouseMovementRecorder is running until EnPtPr Accel is Off. Press A TWICE if EnPtPr is already Off!
  - When EnPtPr Accel is OFF, if there is a lot of red and green, press the '+' key on the keyboard and move the mouse.
  - Repeat '+' and move the mouse until most of the red and green disappears.
  - Press the A key on the keyboard to toggle EnPtPr Accel and move the mouse.
  - If the amount of red and green is roughly the same when EnPtPr Accel is ON as when EnPtPr Accel is Off, then the fix is working.)
  (NOTE: If you use Windows 10, & scaling of items is not 100%, see below.)
  (NOTE: If you use Windows 8.1 and have too much green and red, see below.)
  (NOTE: While running a game, you may see many red and green lines.
  Games that need a fix usually frequently re-position the pointer and this confuses MouseMovementRecorder.exe but DOES NOT mean acceleration.
  See http://www.esreality.com/?a=post&id=1846538#pid1927879 - scroll to 'Comment #271'.)
  
  
• Turn the 'Enhance pointer precision' option OFF when you have finished testing.
  (Unless you applied one of the Windows 2000 or Windows 98/95 Acceleration fixes, then leave 'Enhance pointer precision' checked ON to enable it.)

Does my game need a mouse fix?

You can test your game to see if it turns 'Enhance pointer precision' ON, and needs a mouse fix.

• Turn the 'Enhance pointer precision' option OFF,
• Run Mouse Movement Recorder (included in the ZIP file),
• Run your game (aim at something!) and look at the 'EnPtPr' column footer at the bottom of the Mouse Movement Recorder window.
  If it is displayed with a red background then the game has turned acceleration ON and needs a mouse fix.

Is this fix different from the Cheese Mouse Fix?

The 'Enhance pointer precision' option works slightly differently in Windows 7 than it does in XP and Vista, and slightly differently again in Windows 8.x and 10.

The Cheese Mouse Fix gives exactly 1-to-1 mouse response for Windows XP and Windows Vista.

The MarkC Mouse Fixes give exactly 1-to-1 mouse response for Windows 7 & 8.x & 10.

(Note: Both fixes need the Control Panel 'pointer speed' slider set to the 6th, middle position to give exact 1-to-1.)

But I don't use the middle 6/11 pointer speed setting?

If you want exact 1-to-1 in-game response when the pointer speed slider is not in the 6/11 position, or you have a custom display DPI, see the MarkC Mouse Fix Builder, which works for Windows 10, 8.x, 7, Vista and XP.
For those older games that turn acceleration on, it gives the same response as position 6/11 does (1-to-1), without having to move the pointer speed slider to 6/11.
The MarkC Windows 10 + 8.1 + 8 + 7 + Vista + XP Mouse Acceleration Fix Builder

The MarkC Mouse Fix Builder can also create a fix that emulates Windows 2000 or Windows 98 or Windows 95 acceleration.

How do you remove it?

• Open the ZIP file at the link above.
• If you use Windows 7 or Vista or XP:
  Select 'Windows_7+Vista+XP_Default.reg' and Double-click it.
• If you use Windows 8 or Windows 8.1 or Windows 10:
  Select 'Windows_10+8.x_Default.reg' and Double-click it.
• Answer Yes, OK to the prompts that appear.
• Reboot or Log off.

I use Windows 10 and scaling of text, apps and other items is not 100%

In later versions of Windows 10, Microsoft changed how the mouse pointer is moved in response to mouse input, when scaling of text, apps and other items is not 100%, and Enhance pointer precision is OFF.

Mouse pointer movements when Enhance pointer precision is OFF, are now scaled according to the per-monitor scaling of items setting.

When Enhance pointer precision is OFF, and the Control Panel pointer speed slider is set to 6/11, MouseMovementRecorder will not show all-black, exact 1-to-1, but instead Pointer Movement will be multiplied by the same scaling factor applied to text, apps and other items.

Games may also see this difference, or not, depending on their "DPI Awareness".

I use Windows 8.1 and see too much green and red in MouseMovementRecorder

Windows 8.1 introduced changes to mouse input processing to reduce power used and improve battery life:
Windows 8.1 delays and coalesces (merges) mouse input for programs, causing the effective mouse polling rate to be as low as 62 Hz in some cases (even for gaming mice with a higher polling rate).

This new processing can affect some games (games that don't use Raw Input and don't use DirectInput). Microsoft have a December 2013 Windows Update Rollup that includes a fix for those games, which will be automatically installed when you have Windows Update set to install updates automatically.
(See here: KB2908279 Mouse pointer stutters or freezes when you play certain games in Windows 8.1.)

The new processing can also affect MouseMovementRecorder and cause it to show red and green (with the mouse delays, MouseMovementRecorder sees a mouse movement from DirectInput, but doesn't see the pointer move until MUCH MUCH later and can't figure out what's going on and displays red and green).

If the KB2908279 update fix is installed, MouseMovementRecorder will activate it
to give more responsive mouse pointer movement and stop the red and green.

Otherwise, while running MouseMovementRecorder, select it and press the '+' key
on the keyboard a until the red and green stops.

If Control Panel, Appearance and Personalization, Display shows a 'Smaller...Larger' slider, high DPI monitors might need a custom size and/or a fix-builder fix to get exact 1-to-1.
See this blog article:
Windows 8.1 DPI Scaling Enhancements @ Extreme Windows Blog
The new multi-monitor DPI scaling in Windows 8.1 is a good thing if you have multiple monitors with different pixels-per-inch values, BUT it might make it harder to find the correct Item Size percentage when choosing which MarkC fix to use to get exact 1-to-1.
Try clicking the 'Let me choose one scaling level for all my displays' checkbox and then find the percentage needed so that your main (gaming) monitor looks the same as it did when using the 'Smaller...Larger' slider (this may require some reboots).
When you have the right percentage value, click '...one scaling level...' OFF (so that you get the benefit of the new Multi-monitor DPI scaling - if you need it) and use the percentage value to choose which fix you need, or to create a Fix-Builder fix.

Loading the fix with a non-Administrator account

When adding the mouse acceleration fix to the registry, you may get this error message:

"Cannot import (filename).reg: Not all data was successfully written to the registry."

This error happens because part of the fix turns off acceleration for the Welcome screen (the log on screen).
If you use the Welcome screen (or the Windows Log in dialog) and acceleration is NOT turned off for the Welcome screen, then the MarkC fixes have a 1 pixel / 1 mouse count error when the mouse changes direction left/right or up/down.

You can remove this 1 mouse count error by any of these methods:

• Run Disable_WelcomeScreen+Login_Accel.CMD as Administrator (Right-click > Run as administrator).
• Add/Merge Disable_WelcomeScreen+Login_Accel.reg to the registry while logged in as an administrator.
• Run RegEdit.exe and edit 'HKEY_USERS\.DEFAULT\Control Panel\Mouse\MouseSpeed' to 0 (zero), while logged in as an administrator.
• Not moving or touching the mouse while using the Welcome screen (use arrow keys to select the user and Enter key to log in).
• Ignoring the 1 mouse count error! It's only a single count: You won't notice it.

Windows mouse pointer acceleration (Enhance pointer precision) is partially broken - Part zero

Until Windows 7, mouse handling in Windows has been subtly broken in some ways, and it has taken Microsoft 8 years to fix those problems.

You can fairly easily see these problems (in Vista and XP).
They appear when the Mouse Properties 'Enhance pointer precision' option is turned on (* Note).

In a previous blog I wrote about one of the problems: mouse pointer DPI scaling is wrong in Vista and XP. I'll summarise that problem and also describe another problem.

Rounding of Fractional Intermediate Results Causes Pointer Jitter and Drift

The various internal acceleration and scaling calculations result in a fractional mouse-pointer movement.
This fractional movement is turned into an integer actual number of pixels moved and a fractional remainder.
The fractional remainder is saved internally and applied to the next mouse input.

Such calculations have been done for some while for the 'Mouse Speed' slider, at least since Windows 98.
Typically the fractional result is truncated towards zero, leaving a remainder that has the same sign as the integer part.
(For example, +2.7 is truncated to +2 with remainder +0.7; -3.3 is truncated to -3 with remainder -0.3)

• Windows 7 adds in the previous remainder, then truncates the fractional result towards zero, and stores the new remainder.
  This is desirable and good.
  
  If you record how the Windows 7 pointer responds to mouse input, you can create a picture like this (* Note):
  (The small red dot is on-mouse-pad mouse movement, moving slowly in a circle of diameter 20 'dots' or Mickeys.
  The pointer is how the Windows 7 pointer moves on the screen in response.
  Note that the red dot moves in a larger circle than the pointer does: This is what the 'Enhance pointer precision' option does: If you move the mouse slowly, the pointer moves even slower to allow you fine control over objects selected.)
  
  
• Vista sometimes adds in the previous remainder and sometimes discards the previous remainder, then truncates towards -infinity, and stores the new remainder.
  
  Truncating towards -infinity means that the remainders are always +ve numbers. Sometimes discarding the +ve remainder can cause the mouse pointer to drift up and left over time relative to the actual on-mouse-pad mouse position.
  
  (You can see the drift if you move your on-mouse-pad mouse in a slow circle, making sure to keep the physical mouse near the same point on the mouse pad. Over time the mouse pointer drifts up and left.)
  
  
• XP sometimes adds in the previous remainder and sometimes discards the previous remainder, then truncates towards -infinity, and stores the new remainder.
  It discards the remainder more frequently than Vista.
  
  Truncating towards -infinity means that the remainders are always +ve numbers. Sometimes discarding the +ve remainder can cause the mouse pointer to drift up and left over time relative to the actual on-mouse-pad mouse position, and may cause gently curved near-horizontal or gently curved near-vertical mouse input to result in the mouse pointer 'snapping' to exactly-horizontal or exactly-vertical lines.
  These effects are far more pronounced in XP than they are in Vista.
  
  (You can see the drift the same as for Vista. Also, slow movement at 45 degrees down and right is grossly slowed down and slow movement 45 degrees up and left is sped up.)
  
  If you record how the Windows XP pointer responds to mouse input, you can create a picture like this (* Note):
  (The small red dot is on-mouse-pad mouse movement, moving slowly in a circle of diameter 20 'dots' or Mickeys.
  The pointer is how the Windows XP pointer moves on the screen in response.
  Note that the pointer slowly moves up and left even though the mouse is circling in place.)

Mouse Pointer DPI Scaling is Completely Wrong in Vista and XP

For a long while (Win9x+), Windows has scaled user interface (UI) elements according to the monitor DPI Setting.
Larger DPI settings cause UI elements to be drawn larger on-screen.

Starting in XP, Microsoft attempted to apply DPI scaling to mouse pointer movement.

• In Windows 7, mouse pointer movement is scaled according to DPI. For a given on-mouse-pad mouse movement, larger DPI settings cause larger on-screen pointer movement.
  An internal calculation includes a factor '* DPI'.
  
  
• In XP and Vista, Microsoft got the internal scaling calculation wrong. For a given on-mouse-pad mouse movement, larger DPI settings cause smaller on-screen pointer movement.
  An internal calculation includes a divisor '/ DPI'.

Mouse Pointer Monitor Refresh Rate Scaling Occurs in Vista and XP When It Should Not

• Windows 7 does not scale mouse pointer movement according to the monitor refresh rate.
  
  
• XP and Vista do scale mouse pointer movement according to monitor refresh rate.
  This is incorrect (see my previous post for details).
  An internal calculation includes a factor '* RefreshRate'.

* Note. To see these effects requires the Mouse Properties 'Enhance pointer precision' checkbox to be ON, and might be masked by mouse drivers specific to a particular mouse, for example: Logitech SetPoint mouse drivers with the 'Game Mode > Speed and Acceleration > SetPoint implemention' option selected do not exhibit the above behaviours. The animations were created with the Control Panel Mouse Speed slider set to the middle, 6th position.

Out of sync and upside down: Windows mouse pointer acceleration (Enhance pointer precision) is partially broken

Windows mouse handling ("Enhance pointer precision" option) has always been partially broken in Vista and XP due to a simple design error which is only now fixed in Windows 7.

The "Enhance pointer precision" code uses a calculation that should have included:
× ScreenResolution(DPI) ÷ MouseBusUpdateRate.
The (incorrect) calculation actually used is:
× ScreenRefreshRate ÷ ScreenResolution(DPI).
"Out of sync and upside down."

The Enhance pointer precision checkbox

Windows has long provided a "mouse pointer acceleration" feature that determines how fast the on-screen mouse pointer (cursor) moves in response to movements of the mouse.
(In Windows XP and Windows Vista, mouse pointer acceleration is turned on using the Control Panel>Mouse>Pointer Options>"Enhance pointer precision" checkbox.)

If acceleration is enabled, when the mouse moves slowly, the pointer is moved at a lower ratio, for example 1 count ('dot') of mouse movement might correspond to 1 pixel or less of pointer movement. But if the mouse moves faster, the system responds by accelerating the movement of the pointer, using a higher ratio, for example 1 count of mouse movement then might correspond to 2 or more pixels of pointer movement.

Starting with Windows XP and continuing through Windows Vista and onto Windows 7 RC1, Windows implements mouse pointer acceleration in a different way than in previous versions of Windows.

The new implementation made important improvements in how acceleration works, and in most cases works well enough.
Some (including myself) consider it essential to enable mouse pointer acceleration [link to Coding Horror blog].

HOWEVER, there is a simple conceptual error in its design, which has been carried into the implementation.

There is a large possibility that the effects of the error were found during testing and an attempt was made to fix it.
BUT that fix did not correct the error, and instead merely masked its effects AND INVERTED and UNDID the intended behaviour.

RIGHT NOW, for millions of people, movement of the mouse pointer on their screens is being controlled by an algorithm which includes that conceptual error and "fix error".

The broken behaviour affects users running Windows XP or Windows Vista.
It was present in the first release of Windows XP in October 2001 and continues through Windows Vista SP2.
The conceptual error and the "fix error" have finally been fixed in Windows 7.

What is the broken behaviour?

The broken behaviour can be very very subtle, which may explain why it has not been more widely recognized as a problem and why it has taken so long for it to be fixed. The behaviour is:

• How far the on-screen mouse pointer moves in response to on-mouse-pad mouse movement depends on the monitor refresh rate (higher refresh rates cause larger pointer movements). But the monitor refresh rate should have no effect.
  
• Increasing the display DPI setting (Large size vs. Normal size in the Control Panel) causes the mouse pointer to move fewer on-screen pixels in response to on-mouse-pad mouse movement. But an increased DPI setting should cause the pointer to move a larger number of on-screen pixels, not fewer.

How should it work?

By reading what Microsoft have written about Windows XP mouse acceleration, and some investigation, we can explain how the acceleration should have worked.

Microsoft intended that the velocity (speed) of the on-screen pointer (measured in inches per second) would depend upon the velocity of the on-mouse-pad mouse (also measured in inches per second).

They defined an acceleration formula that translates the velocity of the on-mouse-pad mouse to the corresponding velocity of the on-screen pointer.

The algorithm works like so:

1. During a time period, measure the count of mouse movements (also known as 'dots' or Mickeys).
2. Convert the mouse movement count into a mouse velocity.
3. Using the acceleration formula, calculate the corresponding pointer velocity.
4. Convert the pointer velocity into a number of pixels of pointer movement.

Step 4 is where the conceptual error was made and also the "fix error".

To turn the calculated pointer velocity into a number of pixels of mouse movement involves some simple formulae.

Velocity =

Distance Time

If the "Time" term corresponds to a regular periodic interval, such as the time period between mouse updates, or the time period between each screen refresh, then we can also use this:

Rate =

1 Time

For example, a regular time period of 0.2 seconds corresponds to a rate of 5 times a second (5 Hz).

Combining the two formulae, we get:

Velocity = Distance × Rate

If something is moving 2 inches every 0.2 seconds (5 Hz) we can use the Velocity = Distance/Time formula to calculate Velocity=10 inch/s, OR we can use the Velocity=Distance×Rate formula to also calculate 10 inch/s.

In the case of moving the mouse pointer, what is the appropriate "Time" and "Rate" to use?

This is a key question, and where the conceptual error occured.
The correct time interval is the interval that occurs between successive pointer position updates and (identically) the correct rate is the rate at which the pointer position is updated.
In Windows, the mouse position is updated every time mouse movement counts are sent from the mouse to the PC.
The correct rate to use is the Mouse Bus Update Rate.
A moving mouse connected via a PS/2 bus typically sends movement counts 100 times each second (100 Hz).
A moving mouse connected via a USB bus typically sends movement counts 125 times each second (125 Hz).

How to measure "Distance" for the on-screen pointer?

Windows stores and uses an assumed screen resolution, in Dots Per Inch (DPI) in the Control Panel>Display Properties>Settings>Advanced dialog.
That Screen Resolution (DPI) can be used like so:

DistancePointer =

PixelsPointer ScreenResolution

Putting all of the formula together, we get this formula for pointer velocity:

VPointer = PixelsMouseBusUpdate ×

MouseBusUpdateRate ScreenResolution

The formula above is the formula that SHOULD have been used.
At this point, the team within Microsoft designing and implementing the mouse acceleration got confused.
This confusion is documented in Microsoft's website here:
Pointer Ballistics for Windows XP

The section titled "Relating to Physical Units" indicates that an incorrect formula for Vpointer was used:

VPointer = PixelsMouseBusUpdate ×

ScreenUpdateRate ScreenResolution

Compared to the correct formula, note that ScreenUpdateRate is used where MouseBusUpdateRate should have been used instead.

Using ScreenUpdateRate in the formula would have been appropriate IF the pointer position was updated every screen refresh.
HOWEVER, the pointer position IS NOT updated every screen refresh; it is updated on every mouse bus update.

Of course, it could have been that the Microsoft team had only been imprecise with their formula.
HOWEVER, the example in that section also shows that they have used their incorrect formula: a correct examination of their example gives a physical to virtual gain of 5, NOT the 3 that they calculate.

Of course, it could have been that the Microsoft team had only been imprecise with their formula, AND also clumsy with their example.
HOWEVER, examination of the actual mouse behaviour in Windows XP and Windows Vista shows that they DO have the incorrect ScreenUpdateRate term in their algorithm, AND WORSE!

Considering again the correct formula for Vpointer and rearranging and solving for Pixels:

PixelsMouseBusUpdate = VPointer ×

ScreenResolution MouseBusUpdateRate

Let's examine this formula.
Suppose a monitor having a high resolution (a high DPI, in other words, a small pixel size/pitch).
In order to move the mouse pointer a given physical distance on this high resolution monitor (measured in inches), we would have to move the pointer a LARGER number of pixels, because each pixel is smaller. Note that the formula above MULTIPLIES by ScreenResolution, which will have the desired effect of calculating a LARGER number of SMALLER pixels.

What formula is used by Windows XP and Windows Vista?

Despite the confused formula and example on the Microsoft Pointer Ballistics webpage, one would hope that the correct Pixels_{MouseBusUpdate} formula is used, as above.
One might suspect that a formula that had ScreenUpdateRate instead of MouseBusUpdateRate is used.
However, the formula used is:

PixelsMouseBusUpdate = VPointer ×

ScreenUpdateRate ScreenResolution

Note: rather than multiplying by ScreenResolution, the formula divides by ScreenResolution.
Rather than divide by ScreenUpdateRate (or MouseBusUpdateRate) the formula instead multiplies by ScreenUpdateRate.

Consider again the monitor having a high resolution (a small pixel size/pitch).
Rather than compensating for the small pixel size, the formula used amplifies the effect of a small pixel size: For a high resolution monitor, Windows XP and Windows Vista move the mouse pointer a SMALLER number of SMALLER pixels which is undesirable.

Also undesirable is that how far and how fast Windows XP and Windows Vista move the mouse pointer, depends upon the screen refresh rate.
(The Microsoft team put screen refresh rate in their formula because they wanted to REMOVE any possible effect that screen refresh rate might have had on mouse pointer movement, but instead they ADDED an undesirable effect.)

How could this problem have remained unfixed for so long?

Consider a typical monitor with a refresh rate of 75 Hz and 96 DPI, and a typical mouse with a USB bus update rate of 125 Hz.
The correct Pixels_{MouseBusUpdate} formula calculates ScreenResolution/MouseBusUpdateRate = 96/125 = 0.768.
The "out of sync and upside down" formula that Windows XP and Windows Vista use calculates ScreenUpdateRate/ScreenResolution = 75/96 = 0.78125.
These two numbers differ by less than 2%.

Might the Microsoft team have jumped directly to the incorrect ScreenUpdateRate ÷ ScreenResolution calculation and then not realised the mistake?

Might they have started with ScreenResolution ÷ ScreenUpdateRate and realised something was wrong and then "fixed" it by inverting the numerator and divisor?

We may never know.

A silly flash toy...

The real reason why mouse acceleration is broken? [link]