Sensitivity numbers do not share a universal scale. A value of 2.0 in one game engine may turn the camera by a different angle than 2.0 in another. Copying the number therefore does not preserve the physical mouse movement required for the same rotation.
AimCurve uses a narrow and testable target: preserve estimated hip-fire centimeters per 360-degree turn with documented horizontal yaw constants. This gives you a defensible starting point, not a promise that two games will feel identical.
Start with DPI and source sensitivity
Mouse DPI describes reported counts per inch of physical movement. In-game sensitivity scales how those counts affect view rotation. Record both values exactly. A profile label such as “medium” or a slider position is not enough if the game exposes a numeric value.
Open the Sensitivity Converter, choose the source and target game, enter the source sensitivity and DPI, then run the calculation. The current model supports default hip-fire scaling for CS2, VALORANT, Apex Legends and Overwatch 2.
The converter displays a target sensitivity, estimated cm/360, source eDPI and target eDPI. It also prints the constant-based formula so the result is not a black box.
Understand the angular model
For a supported game, the model treats mouse counts, the game’s horizontal yaw constant and sensitivity as an angular rate. The target sensitivity is calculated as:
source sensitivity × source yaw ÷ target yaw
Because DPI remains the same in a direct conversion, the result preserves the modeled counts required for a full turn. Estimated centimeters per 360 uses DPI to turn those counts into physical distance.
Rounding matters. Copy enough decimals to reproduce the output, then use the precision the target game accepts. Avoid rounding early in a chain of multiple conversions. Convert from the known source each time rather than repeatedly converting a rounded target into another game.
eDPI is game-specific
eDPI is commonly calculated as mouse DPI multiplied by in-game sensitivity. It is useful for comparing players inside the same game and scale. It is not a universal cross-game unit because the sensitivity number is interpreted through a different engine constant.
That is why source and target eDPI can differ even when cm/360 is preserved. Treat each as a within-game shorthand. Use physical distance or angular calculations for cross-game comparison.
Why equal cm/360 can feel different
Two mathematically matched hip-fire turns can still feel different because perception includes far more than rotation distance:
- Horizontal and vertical field of view
- Aspect ratio and display size
- Weapon animations and camera motion
- Frame rate, frame pacing and latency
- Mouse acceleration or raw-input behavior
- Zoom, scope and aim-down-sights multipliers
- Crosshair, target size and game movement speed
- Different response or input-processing pipelines
A matching cm/360 controls one variable. That is valuable precisely because it lets you evaluate the remaining differences without changing everything at once.
Validate with a physical turn
Enter the result in the target game and mark two points on a large mousepad or desk-safe reference. Place the mouse at the first point, aim at a recognizable in-game reference, then move smoothly until the view completes one full turn. Measure the distance.
This is not a laboratory calibration: hand angle, acceleration, frame presentation and identifying the exact final angle add error. Repeat several times in both directions and use the average. If the target differs consistently, confirm DPI, acceleration, game profile and whether the game accepted all entered decimals.
Do not change FOV, DPI and sensitivity during the same validation. One change at a time makes the discrepancy interpretable.
Treat scoped sensitivity separately
AimCurve does not claim to match scoped or aim-down-sights feel. Zoom systems may use separate multipliers, focal-length scaling, monitor-distance models or weapon-specific fields of view. A single hip-fire constant cannot describe all of them honestly.
Keep the converted value as your hip-fire baseline, then tune scopes inside the target game using its documented behavior and a task that reflects how you aim. Future AimCurve releases may add scoped models only when the constants and method can be versioned and explained per game.
Choose whether to keep the match
A converted value is a starting point. After validation, play a consistent warm-up or training routine. If the game demands more rapid turns or finer long-range control, make small deliberate changes. Record the final value separately from the mathematical match.
This distinction prevents a common trap: forcing every game into one sensitivity even when mechanics differ. Consistency can mean preserving a physical baseline, but expertise also includes adapting to the task.
Common conversion mistakes
Copying the sensitivity number directly. Values use different scales. Use the supported constant model.
Comparing eDPI across games. eDPI lacks the engine’s angular constant and is not universal.
Ignoring a DPI profile change. A target value is correct only for the DPI entered. Some mice switch profiles with a hardware button.
Rounding too early. Keep calculation precision and round only to the target game’s accepted input.
Matching hip-fire and assuming scopes match. Zoom behavior needs its own model.
Treating feel as proof of mathematical error. FOV, animation and latency can change perception even when physical rotation is close.
Reproducible setup record
Save the mouse model, active DPI, polling setting, source game/version, source sensitivity, target game/version, calculated target, measured cm/360 and final preferred value. If a game update changes its input scale, that record lets you identify and correct the change.
AimCurve constants are versioned in the Keymap Labs methodology. When a supported game’s behavior changes, the transparent model and update date matter as much as the number on the screen.