Method & sources

What the calculators actually compute, where the constants come from, and where the model stops being valid.

The conversion formula

Each game engine defines a yaw: the number of degrees your view rotates per mouse count at an in-game sensitivity of 1. Because yaw differs per engine, the same sensitivity number produces different turn speeds in different games, and yaw is the only thing that makes conversion exact:

target sensitivity = source sensitivity × (source yaw / target yaw)
cm/360° = 360 / (DPI × sensitivity × yaw) × 2.54

When the mouse DPI also changes, the DPI ratio is folded in: target sensitivity = source sensitivity × (source yaw × source DPI) / (target yaw × target DPI). Only the product of sensitivity and DPI matters, which is why 1.0 at 1600 DPI and 2.0 at 800 DPI turn at exactly the same speed.

Where the yaw values come from

Developers rarely publish yaw. The values used here are taken from community references that agree with each other and with the engine's known scale — primarily the yaw tables published by mouse-sensitivity.com, SensLab, WinroGames and AimBetween, cross-checked against each other.

Each value on the converter is labelled:

The peeker's advantage model

We use the decomposition published by Riot's technical engineering lead for VALORANT. The peeker has already seen the defender (their own movement is predicted locally and drawn instantly); the defender's screen is still empty. The gap is the sum of five delays:

Riot quotes a network interpolation delay of 7.8125 ms and a server frame of 7.8125 ms on their 128 Hz servers, and states that peeker's advantage in VALORANT averages 40–70 ms. Our calculator reproduces that range for typical pings: for example 30 ms on both sides at 128 Hz and 144 fps gives 52.6 ms.

The estimate uses one full server tick, the same conservative convention Riot uses. Because the movement packet lands at a random point inside a tick interval, the real value ranges from estimate − one tick to estimate + one tick; both bounds are shown on the page.

Known limits of this model: it assumes a stationary, pre-aimed defender and no packet loss. Loss or jitter forces the client to grow its interpolation buffer, which the model cannot know. Run speed defaults are editable estimates — measure your own in-game if you want exact distances. Human reaction time, roughly 200–250 ms, is vastly larger than any of these terms and dominates the outcome of an actual duel.

Tick rates used in the presets: VALORANT 128 Hz, CS2 Premier 128 Hz and matchmaking 64 Hz with subtick, Overwatch 2 63 Hz, Rainbow Six Siege 60 Hz, Call of Duty 60 Hz, Fortnite 30 Hz, Apex Legends 20 Hz. Subtick timestamps input timing, so it removes tick quantisation from when you shot — not from when the defender sees you, which is still governed by the 64 Hz simulation and snapshot rate.

Known limitations

The model describes hipfire rotation only. It does not account for:

Because of these, treat the output as the mathematically correct hipfire equivalent and then confirm it with a ruler: one full turn from a fixed starting point, averaged over two or three measurements.

Corrections

Games patch their sensitivity scales. If a value here disagrees with what you measure in-game, send it through the contact page with how you measured it, and the table will be corrected with credit.