settings
 mouse resolution (dpi)
windows sensitivity multiplier
in-game sensitivity
m_yaw (0.022 default)
in-game resolution width
field of view (fov)
cl_mouseaccel (m_accel)
frames per second (fps)
 To see where a specific setting is located in any of the following equations, mouse over it.

windows sensitivity multipliers
sensitivity
real sensitivity (cm/360) =

By combining your mouse dpi, windows sensitivity, in-game sensitivity, m_yaw values, and dividing them by 360, you can calculate how many centimeters it takes for you to complete a 360 degree turn. This is called your real sensitivity.

 (360 / (y * d * w * s)) * 2.54

m_yaw
mouse resolution (dpi)
windows sensitivity multiplier
in-game sensitivity
real sensitivity (inches/360) =

For those of you who don't use the metric system, the above is how many inches it takes to complete a 360 degree turn.

Note: If you are using accel, then the real sensitivity calculation will give you a "base" sensitivity, which is the sensitivity you would get if you disabled accel. 		360 / (y * d * w * s)

m_yaw
mouse resolution (dpi)
windows sensitivity multiplier
in-game sensitivity
dpi
estimated useful dpi =

The mouse resolution determines the smallest angle you can rotate your view by in game, for a given sensitivity. If you want this smallest angle to be small enough so that you can turn your view by 1 pixel (to the pixel next to where your crosshair is), you need to know what angle that distance of 1 pixel represents on your screen. The projection of the 3D world onto the 2D plane of your screen means the pixels located near the crosshair represent much larger angles than those pixels located at the edges of your screen. If the mouse resolution calculated above is bigger than your current dpi, then your smallest rotation will be larger than 1-pixel's worth of rotation.

Please note that this is an estimation of useful dpi. We do not recommend adjusting your setup just to satisfy this value; however, if your current dpi is significantly lower, this may suggest your current setup would benefit from a higher dpi. 		(pi * g) / (i * tan(f / 2))

in-game resolution width
real sensitivity (inches/360)
field of view (fov)
accel
real accel =

The interpretation of real accel can be thought of as the extra sensitivity given per speed of mouse movement. The real accel value calculated above is the number of extra degrees per cm gained by moving the mouse at 1 cm/s.

Note: This is defined for quake 3 style accel (or quake live with cl_mouseAccelStyle 0). Trying to use this for another game engine (i.e. source engine) will not work. 		(((d *w) / 2.54)^2 * y * a) / 1000)

mouse resolution (dpi)
windows sensitivity multiplier
m_yaw
cl_mouseaccel
neg accel
maximum speed (meters/second) =

If you move your mouse faster than the above speed you will get negative acceleration. This only will occur in games that use mouse pointer input (WM_MOUSEMOVE/GetCursorPos). In order to tell if your game does this, you need to know what type of input your game uses.

If you find yourself moving your mouse faster than the speed above and getting negative acceleration, make sure to look at what elements of the equation could be causing this issue. If possible, lower your dpi or raise your resolution and see what that does for your new max speed calculation. If your fps drops below the value you have in the settings section, your maximum speed before reaching negative acceleration will also decrease, which makes it easier to reach the point of negative acceleration.

Games that use mouse pointer input are not the only cause of negative acceleration. The sensor in your mouse can also effect whether or not you get neg accel past a certain speed. For example, my neg accel value calculated from above is 2.54m/s. However, since I use the wheel mouse optical 1.1a, my sensor will cause me to have neg accel past 1m/s (1.55m/s overclocked).

Some information on other mice and the speed they can handle can be found in ESReality's MouseScore from 2007. There was also a test done specifically on the deathadder at a later date. 		(g * fps) / (2 * ((d * w) / 0.0254))

in-game resolution
frames per second (fps)
mouse resolution (dpi)
windows sensitivity multiplier
mousefix
What is a mousefix? Why do I 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).

In XP, Vista and Windows 7, 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.)
Does my game need a mousefix?

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
Run your game 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

If it is not displayed with a red background, you do not need a mousefix. All you need to do is disable the enhance pointer precision option and keep your windows sensitivity at the 6/11 slider.

What if I don't use the 6/11 windows sensitivity setting?

If you use a setting lower or higher than the default windows setting, you will not get 1 to 1 windows mouse movement.

For example, say you are using 3/11. Your windows multiplier is 0.25. If you move the mouse by one pixel constantly for 3 counts, 3 * 0.25 = 0.75, and the pointer is not moved at all. You then move another 2 counts, and 2 * 0.25 = 0.5 + the 0.75 from last time = 1.25. Now the pointer moves by 1. This happens because when Windows applies the scaling factor, it can only pass through to the game a whole (integer) number of mouse movement and it holds back or delays a remainder which is added into the next movement.

If you are not in a position where you can comfortably change your windows sensitivity back to 6/11 while on your desktop, you'll have to change it to 6/11 every time you open a game. If your game requires a mousefix (turns Enhance pointer precision ON), you can use the MarkC Mousefix Builder, which will automatically force your windows sensitivity to 6/11 when your game is opened.

Unfortnuately, if your game does not turn on enhance pointer precision, the mousefix builder will not work, and you'll need to change the windows sensitivity manually. However, some games (like Counter-Strike: Source) have the option of enabling enhance pointer precision on launch through launch options. If you use this launch option (-useforcedmparms), the game will turn on enhance pointer precision, which will then be negated by the mousefix builder, as well as automatically set your windows sensitivity to 6/11. Once the game is closed, the enhance pointer precision option will go back to the way it was set on your desktop (off), as will your windows sensitivity (no longer forced to 6/11)
I need a mousefix.

Windows XP or Vista (6/11 windows sensitivity) - Cheese Mousefix
Windows XP, Vista, or 7 (NOT 6/11 windows sensitivity) - MarkC Mousefix Builder
Windows 7 (6/11 windows sensitivity) - MarkC Windows 7 Mousefix
Note: When using the mousefix builder, it will adjust your sensitivity slider to the 6/11 position when you open your game (unless your game does not turn enhance pointer precision on, read above). This will make your sensitivity faster/slower depending on what windows sensitivity you were using previously. In order to find the right sensitivity again, multiply your in-game sensitivity by your previous windows sensitivity multiplier. This value is your new in-game sensitivity.
What about CPL Mousefix?

The CPL Mouse Fix has problems, WHEN the 'Enhance pointer precision' checkbox is ON (or your game forces it on), which include:
Not an exact 1:1 mapping of mouse movement to pointer movement.
At refresh rates < 80 Hz, it moves the mouse pointer < 1 pixel for each mouse count sent, which causes bizzare wobbling and slowdown if moving the mouse slowly right and down.
At refresh rates > 80 Hz, it moves the mouse pointer > 1 pixel for each mouse count sent, which causes bizzare wobbling and speedup if moving the mouse slowly left and up.
At any refresh rate, moving the mouse slowly in small circles causes the pointer to move up and left slowly.

The Cheese Mousefix (XP and Vista) and MarkC Mousefix (Windows 7) do not have these problems.
polling rate
Your mouse's polling rate determines how often it sends data to your operating system. All mouse movements (counts) and button presses must wait in the mouse until windows polls for them. By default, windows will poll a usb mouse every 8 milliseconds (125hz).

You can increase the frequency of polling with a number of programs/drivers/registry fixes. All this does is reduce the delay of sending the mouse data to the operating system. This has no effect on your sensitivity, but it will increase cpu usage.

For example, say you are using a polling rate of 500hz (2ms). Over a period of 8ms, you move your mouse 40 pixels (constant movement, no acceleration). Every 2ms your mouse sends a count of 10 pixels. Now you increase your polling rate to 1000hz (1ms) and make the same movement. Instead of 10 pixels every 2ms, your mouse now sends 5 every 1ms. Either way, 10x4=40, and 5x8=40. same distance, one is just polled more frequently.

check your polling rate:

mouse movement recorder
mouserate checker
direct input mouse rate

change your polling rate:

hidusbf - windows xp
hidusbf - windows vista/7 (requires slightly more effort)

If you decide to increase your polling rate, make sure your mouse can consistently provide updates at the increased frequency. If it cannot, the delay of your input will change.

Your mouse may not be able to report consistently for any number of reasons, including your operating system, cpu, motherboard, or the mouse itself.

For example, I have two screenshots taken of mouse movement recorder with two different mice overclocked to 1000hz. Both screenshots are the end of a short movement of each mouse. The first screenshot is of the wheel mouse optical 1.1a. You can see that every time windows polls (1ms), the mouse has data to send, so the rate sticks to 1000hz (or very close to it). As my movement begins to slow down, and eventually stop, the mouse rate goes down. This is because windows is polling every 1ms, but as the mouse moves slower, sometimes there is no movement at that poll. Then another 1ms later, windows polls the mouse and there is movement, so the period of that movement was 2ms long instead of 1. Frequency = 1/time, so 1/(2ms) = 500Hz. Because windows polls every 1ms, the periods can only be 1ms, or 2ms, or 3ms, etc, and then the hz can only be 1000/1, 1000/2, 1000/3, 1000/4, 1000/5, etc (1000, 500, 333, 250, 200). This explains why the mouse eventually hits 333/200hz before the movement comes to an end.

In the second screenshot of the mx518 @ 1000hz, we don't see as good of a performance. More than 5 times the mouse reports at more than 1ms before it is slowed down. Using mouserate checker, I put together a screenshot comparing the 518 at 500 and 1000hz. You can see at constant movement that the 518 reports correctly every 2ms, but sometimes even lower when set to report every 1ms. Looking again at mouse movement recorder at 500hz this time, you can see the report rate looks as expected as the mouse movement comes to an end.

If you overclock your mouse and it doesn't behave as expected, try stepping it down to the next polling rate to find something stable.
prediction
Mouse prediction (angle snapping, drift control) is a type of path correction in mouse sensors that assists you in drawing horizontal or vertical lines (useful for graphical applications). If your mouse has prediction, the sensor will predict when you attempt to draw a straight line and correct any movement that drifts away from that line. This is not an accurate representation of your movement, so most people prefer to play without prediction.

If you want to see the level of prediction that your mouse has, open mspaint and attempt to draw a straight line.

Here is a screenshot showing the difference in prediction between a wheel mouse optical 1.1a and a logitech mx518.

In most cases you cannot change the level of prediction your mouse has. However, some mice like the razer deathadder come with firmware updates that can enable/disable prediction.
input
There are three main types of mouse input; WM_MOUSEMOVE (or GetCursorPos), WM_INPUT, and DirectInput. The first method, WM_MOUSEMOVE/GetCursorPos, is mouse pointer input that goes through windows. The second, WM_INPUT (aka raw input), is raw data taken directly from the mouse at the lowest level possible. DirectInput is very similar to raw input, but it is only useful if you need to support joysticks/controllers.

WM_INPUT is preferred over WM_MOUSEMOVE/GetCursorPos, as it gives you exact 1 to 1 sensitivity, and removes one of the major causes of negative acceleration. WM_MOUSEMOVE/GetCursorPos uses changes in the mouse pointer position to calculate mouse movement. The game locks the mouse pointer to the middle of the screen. When you move the mouse, the (hidden) pointer moves and the game calculates movement from the middle and then resets the pointer back to the middle. It does this every frame. If the game is busy and doesn't reset the pointer to the middle fast enough, a quick mouse movement can move the pointer right to the screen edge and it gets stuck at the edge. Any further movement past the edge is thrown away and you get negative acceleration.

Here is simple way to test if your game uses WM_MOUSEMOVE/GetCursorPos for input:

Set your windows sensitivity value to one much lower than normal (i.e. from 6/11 to 3/11)
Open your game of choice
If mouse movement is much slower than normal, your game is using WM_MOUSEMOVE/GetCursorPos
If mouse movement is normal, your game is not using WM_MOUSEMOVE/GetCursorPos
about
This website has content that is nearly copied word for word from the following smart people:

ALL formulas by injx
MarkC Mousefix created and cleverly named by MarkC

If you have any corrections to make, content to add, or questions to ask, you can contact me via ESreality, ESEA, or YouTube