eDPI has no physical unit
eDPI means "effective DPI" and is just the mouse DPI multiplied by the in-game sensitivity. It exists to collapse two adjustment knobs into a single number: 800 DPI at sensitivity 1.5 gives 1200 eDPI, the same as 400 DPI at sensitivity 3.0. Within one game that is honest, both setups turn the camera by exactly the same amount. The mistake starts when you compare eDPI across different games, because each game applies its own internal factor before moving the crosshair. That factor is the yaw, and it is precisely what eDPI ignores. Comparing eDPI across games is like comparing speeds without stating the unit: a bigger number is not necessarily faster.
- DPI (or CPI)
- Counts the sensor reports per inch of mouse movement. A property of the hardware.
- Sensitivity
- Multiplier the game applies to each count before turning the camera.
- eDPI
- DPI × sensitivity. A unitless shortcut, comparable only within the same game.
- yaw
- Degrees the camera turns per mouse count, at sensitivity 1. The constant that differs between games.
- cm/360
- Centimeters of mouse to complete a 360° turn. The real physical quantity of your aim.
Yaw and the cm/360 derivation
Yaw is the missing piece. It states how many degrees the camera turns for each mouse count when sensitivity is 1. In Source-family engines, CS:GO, CS2, Team Fortress 2, Apex Legends, the variable is called m_yaw and the default is 0.022 degrees per count, confirmed in the sensitivity-matching community documentation and locked in CS2 competitive mode. From that single constant, the rest is arithmetic. With sensitivity applied, each count turns (yaw × sens) degrees. To complete 360°, you need counts_360 = 360 ÷ (yaw × sens) counts. Dividing that total by DPI gives the distance in inches, and multiplying by 2.54 converts to centimeters, the same inch-to-centimeter constant from the unit conversion guide.
cm/360 = (360 / (yaw × sens)) / DPI × 2,54- cm/360
- centimeters of mouse to turn 360°
- yaw
- degrees per count at sens 1 (m_yaw = 0.022 in CS2/Source)
- sens
- the sensitivity set in the game
- DPI
- counts the sensor reports per inch
- 2,54
- centimeters per inch (unit constant)
Worked example 1, CS2, 800 DPI, sensitivity 1.5. Each count turns 0.022 × 1.5 = 0.033°. For 360°: counts_360 = 360 ÷ 0.033 ≈ 10,909 counts. In inches: 10,909 ÷ 800 = 13.64 in. In centimeters: 13.64 × 2.54 ≈ 34.6 cm. That player drags the mouse almost 35 cm for a full half-turn, that distance is what the hand memorizes, not the eDPI of 1200.
Converting between constant-yaw games
If cm/360 has to stay equal in two games and DPI does not change, the product (yaw × sens) must stay constant. Solving for the new sensitivity yields a clean rule: sensB = sensA × yawA ÷ yawB. Notice DPI cancels out, the sensitivity conversion does not depend on DPI, only on the ratio between the yaws. That is why the sensitivity converter keeps a table of verified per-game yaws: with the source and target yaw, the conversion is exact. Valorant, for example, uses yaw 0.07; its ratio to Source is 0.07 ÷ 0.022 ≈ 3.18, the number behind every CS↔Valorant conversion.
Worked example 2, take the setup from example 1 (CS2, 800 DPI, sens 1.5) into Valorant, keeping the same 34.6 cm/360. sens_Valorant = 1.5 × 0.022 ÷ 0.07 ≈ 0.47. Check it: at 800 DPI and sens 0.47, Valorant cm/360 comes back to 34.6 cm, identical aim. Now look at the eDPI: in CS2 it was 1200; in Valorant it became 800 × 0.47 ≈ 377. The same physical movement, the same cm/360, and two eDPIs that look nothing alike. That is the numerical proof that eDPI does not cross the border between games.
eDPI
- DPI × sensitivity; an easy number to trade.
- No physical unit; ignores the game yaw.
- Comparable only within the same game.
- Same eDPI in different games = different aim.
cm/360
- Real centimeters of mouse to turn 360°.
- Physical quantity; comparable across any game.
- Derives from yaw; it is what the conversion preserves.
- It is what your muscle memory actually learns.
The curve: why low sens is touchy to changes
Because cm/360 is inversely proportional to sensitivity, its graph is a hyperbola, not a straight line. In practice this means the same step in sensitivity shifts cm/360 far more at the low end than at the high end. Going from sens 0.5 to 1.0 halves the cm/360, a huge difference of tens of centimeters. Going from 3.0 to 3.5 barely moves the result. That is why low-sensitivity players should tune in small steps: an "innocent rounding" of 0.1 in the value has a big effect on the arm. The chart below plots cm/360 as a function of CS2 sensitivity for two DPIs.
View the data
| x | 400 DPI | 800 DPI |
|---|---|---|
| 0.5 | 207.8 cm | 103.9 cm |
| 1 | 103.9 cm | 52 cm |
| 1.5 | 69.3 cm | 34.6 cm |
| 2 | 52 cm | 26 cm |
| 3 | 34.6 cm | 17.3 cm |
| 4 | 26 cm | 13 cm |
| cm/360 range | Style | Note |
|---|---|---|
| Under 20 cm | Very high | Wrist flicks; little desk space, more erratic. |
| 20–35 cm | High | Fast reaction, mostly wrist aiming. |
| 35–50 cm | Medium / balanced | A very common band in competitive CS. |
| 50–80 cm | Low | Arm aiming; favors tracking and stability. |
| Over 80 cm | Very low | Heavy arm; needs a large mousepad. |
Windows and hardware: what not to break
The conversion is only exact if nothing between the sensor and the game touches the counts. Two Windows settings do exactly that. The first is "Enhance pointer precision", Windows built-in acceleration: with it on, the faster you move the mouse, the more the crosshair travels per count, which destroys any fixed cm/360. Leave it off. The second is the "pointer speed" slider: of its eleven steps, only the middle one (6/11) applies a 1.0 multiplier. Below it, Windows discards counts irregularly; above it, it multiplies them and "skips" pixels. The multiplier table (with acceleration off) is documented on Liquipedia.
| Slider position | Multiplier (acceleration off) |
|---|---|
| 1/11 | 0.03125 |
| 2/11 | 0.125 |
| 3/11 | 0.375 |
| 4/11 | 0.625 |
| 5/11 | 0.875 |
| 6/11 (middle) | 1.0 |
| 7/11 | 1.5 |
| 8/11 | 2.0 |
| 9/11 | 2.75 |
| 10/11 | 3.0 |
| 11/11 | 3.5 |
DPI and polling rate are different things and do not trade off. DPI sets the granularity, how many counts the sensor emits per inch, and therefore your sensitivity. Polling rate (in Hz) sets only how often the mouse reports its position to the computer, that is, latency and smoothness, not sensitivity. You can run 800 DPI at 1000 Hz or 1600 DPI at 500 Hz; they are independent axes. The real place DPI matters for aim is "pixel skipping": with very low DPI and very high sensitivity, each count moves the crosshair several pixels at once, and the camera "jumps" over small targets instead of gliding. The fix is not absurd DPI, it is enough DPI that one count is worth at most one pixel at your sensitivity and resolution.
If I use raw input, does the Windows slider still matter?
Raw input reads the mouse directly, before the Windows layers, so in theory it ignores the slider and pointer acceleration. Even so, keep 6/11 and acceleration off: not every piece of software honors raw input all the time, and the desktop (menus, alt-tab) still goes through the Windows layer.
cm/360 or in/360, which to report?
They are the same measure in different units: in/360 × 2.54 = cm/360. The FPS community uses cm/360 as it maps better to mousepad size; some internal math stays in inches because DPI is already "per inch". Use whichever you prefer, as long as you stay consistent.
Games with no constant yaw: R6 and Fortnite
All the math above assumes a constant yaw: one count always turns the same amount, regardless of movement speed. Not every game works that way. Fortnite exposes configurable mouse acceleration and separate aiming/scope multipliers; with acceleration on, degrees per count start to depend on how fast you move the mouse, so there is no single yaw, and therefore no single cm/360. Rainbow Six Siege uses its own model, with aim-down-sights (ADS) sensitivity tied to FOV and the optic multiplier in a way that differs from Source games. In these cases, "converting" only nails one point: you match cm/360 at the hip (hipfire) and the scoped aim is off, or vice versa.
- Turn off "Enhance pointer precision" in Windows and acceleration in the mouse software.
- Leave the Windows slider at 6/11 (multiplier 1.0).
- Record your cm/360, not your eDPI, that is what you carry to any game.
- For R6/Fortnite, treat the conversion as a starting point and tune by eye.
Frequently asked questions
Which is better, high DPI with low sens or low DPI with high sens?
Why is my eDPI equal to a pro but the aim feels different?
What is the m_yaw of CS2?
How do I convert CS2 sensitivity to Valorant?
Can I convert sensitivity to Rainbow Six Siege or Fortnite?
Stop comparing eDPI across games: it has no unit and evaporates when the yaw changes. Keep your cm/360, the physical distance of a full turn, and derive everything from it: between constant-yaw games, sensB = sensA × yawA ÷ yawB at the same DPI. Turn off pointer acceleration, keep Windows at 6/11, and remember that R6 and Fortnite, lacking a constant yaw, only accept an approximation at one point on the curve.