CS2 sensitivity in motion: 10 cm, matched eDPI and flick corrections
At 800 DPI, sensitivity 0.865 and m_yaw 0.022, 10 cm of mouse travel gives about 59.94° of rotation. A full turn takes about 60.06 cm in this model.
This is the animated companion to our three sensitivity diagrams:
- 0:00: mouse travel and camera rotation increase together.
- 0:16: 400 × 1.73, 800 × 0.865 and 1600 × 0.4325 keep the same turn distance, while the angle per count changes.
- 0:32: three first stops, followed by corrections from before and beyond the target.
The angular bars compare positions, not frames or polling intervals. A mouse report can contain several counts. The final example keeps the first stopping points visible so you can follow the correction.
Scope: the camera diagrams use nominal DPI and linear, unscoped horizontal input without acceleration or extra multipliers; the paths are illustrations, not player recordings or evidence that a setting improves aim.
What's your current DPI and sensitivity?
Sources: CS2 extracted convar data, Valve Source SDK 2013 scaling reference (Source 1, not CS2 client source).
1 point
CS2 sensitivity in three diagrams: mouse travel, DPI and camera rotation
These three diagrams explain the nominal relationship between mouse travel and camera rotation in CS2. The examples use horizontal, unscoped, linear input with m_yaw = 0.022 and no extra scaling or acceleration. Check your own settings before comparing.
1. From mouse travel to camera rotation
The model is:
counts ≈ distance_cm / 2.54 × DPI
angle_deg ≈ counts × sensitivity × |m_yaw|
cm/360 ≈ 914.4 / (DPI × sensitivity × |m_yaw|)
At 800 DPI and sensitivity 0.865, 10 cm of travel gives about 59.94 degrees of rotation. A full turn needs about 60.06 cm. Fractional counts in the calculation are a continuous approximation; mouse reports contain integer counts. Configured DPI is nominal CPI, not a calibration measurement.
2. Matching the turn distance while changing DPI
400 DPI × 1.73, 800 DPI × 0.865 and 1600 DPI × 0.4325 all give 692 eDPI. With the same yaw factor, their nominal cm/360 is the same. The angle per count changes from 0.038060 to 0.019030 to 0.009515 degrees.
That is a change in angular granularity. Whether it improves your performance requires testing. The tick marks on slide 2 represent angular positions, not frames or polling intervals. One mouse report can contain several counts.
3. Why degrees are not pixels
With a fixed centre crosshair, rotating the camera changes where the world projects onto the image. Slide 3 calculates the displacement of a point initially at the centre for two explicitly chosen horizontal FOVs at a 1920-pixel image width. These are projection examples, not screenshots or measurements of your game. The resulting subpixel coordinates do not mean the desktop cursor moves by a fraction of a pixel.
FOV and image stretching affect the appearance of motion. They do not enter this unscoped rotation-distance formula when the input mapping stays unchanged. Zoom needs a separate model. Matching cm/360 also does not guarantee matching perceived speed across games or FOVs; eDPI comparisons require the same game and multipliers.
You can inspect sensitivity and m_yaw by entering their names without a value in the developer console. To check the physical result, use a fixed world reference in local practice and measure mouse travel for a slow full turn, without lifting the mouse. Repeat the measurement. Pad measurements and actual CPI have uncertainty.
Sources and scope
CS2 game-extracted convar data, maintained by SteamDatabase, lists m_yaw as 0.022. It is extracted data, not an official Valve explanatory article:
github.com/SteamDatabase/GameTracking-CS2/blob/ma…
Valve's Source SDK 2013 shows the linear sensitivity and yaw operations used as the code reference for this calculation. It is Source 1 code, not the CS2 client source:
github.com/ValveSoftware/source-sdk-2013/blob/mas…
The equations, projection examples and diagrams are calculated illustrations. They do not measure sensor accuracy, system latency, rendering behaviour, recoil or match performance.
For papers, proposed tests and questions about the interpretation, use our Aim science discussion:
reddit.com
1 point
Mentions
CS2 sensitivity in motion: 10 cm, matched eDPI and flick corrections At 800 DPI, sensitivity 0.865 and m_yaw 0.022, 10 cm of mouse travel gives about 59.94° of rotation. A full turn takes about 60.06 cm in this model. This is the animated companion to our three sensitivity diagrams: - 0:00: mouse travel and camera rotation increase together. - 0:16: 400 × 1.73, 800 × 0.865 and 1600 × 0.4325 keep the same turn distance, while the angle per count changes. - 0:32: three first stops, followed by corrections from before and beyond the target. The angular bars compare positions, not frames or polling intervals. A mouse report can contain several counts. The final example keeps the first stopping points visible so you can follow the correction. Scope: the camera diagrams use nominal DPI and linear, unscoped horizontal input without acceleration or extra multipliers; the paths are illustrations, not player recordings or evidence that a setting improves aim. What's your current DPI and sensitivity? Sources: CS2 extracted convar data, Valve Source SDK 2013 scaling reference (Source 1, not CS2 client source).
CS2 sensitivity in three diagrams: mouse travel, DPI and camera rotation These three diagrams explain the nominal relationship between mouse travel and camera rotation in CS2. The examples use horizontal, unscoped, linear input with m_yaw = 0.022 and no extra scaling or acceleration. Check your own settings before comparing. 1. From mouse travel to camera rotation The model is: counts ≈ distance_cm / 2.54 × DPI angle_deg ≈ counts × sensitivity × |m_yaw| cm/360 ≈ 914.4 / (DPI × sensitivity × |m_yaw|) At 800 DPI and sensitivity 0.865, 10 cm of travel gives about 59.94 degrees of rotation. A full turn needs about 60.06 cm. Fractional counts in the calculation are a continuous approximation; mouse reports contain integer counts. Configured DPI is nominal CPI, not a calibration measurement. 2. Matching the turn distance while changing DPI 400 DPI × 1.73, 800 DPI × 0.865 and 1600 DPI × 0.4325 all give 692 eDPI. With the same yaw factor, their nominal cm/360 is the same. The angle per count changes from 0.038060 to 0.019030 to 0.009515 degrees. That is a change in angular granularity. Whether it improves your performance requires testing. The tick marks on slide 2 represent angular positions, not frames or polling intervals. One mouse report can contain several counts. 3. Why degrees are not pixels With a fixed centre crosshair, rotating the camera changes where the world projects onto the image. Slide 3 calculates the displacement of a point initially at the centre for two explicitly chosen horizontal FOVs at a 1920-pixel image width. These are projection examples, not screenshots or measurements of your game. The resulting subpixel coordinates do not mean the desktop cursor moves by a fraction of a pixel. FOV and image stretching affect the appearance of motion. They do not enter this unscoped rotation-distance formula when the input mapping stays unchanged. Zoom needs a separate model. Matching cm/360 also does not guarantee matching perceived speed across games or FOVs; eDPI comparisons require the same game and multipliers. You can inspect sensitivity and m_yaw by entering their names without a value in the developer console. To check the physical result, use a fixed world reference in local practice and measure mouse travel for a slow full turn, without lifting the mouse. Repeat the measurement. Pad measurements and actual CPI have uncertainty. Sources and scope CS2 game-extracted convar data, maintained by SteamDatabase, lists m_yaw as 0.022. It is extracted data, not an official Valve explanatory article: github.com/SteamDatabase/GameTracking-CS2/blob/ma… Valve's Source SDK 2013 shows the linear sensitivity and yaw operations used as the code reference for this calculation. It is Source 1 code, not the CS2 client source: github.com/ValveSoftware/source-sdk-2013/blob/mas… The equations, projection examples and diagrams are calculated illustrations. They do not measure sensor accuracy, system latency, rendering behaviour, recoil or match performance. For papers, proposed tests and questions about the interpretation, use our Aim science discussion: reddit.com