Sensitivity, frame rate and resolution: the numbers that matter

Four settings decide how a shooter feels: how far your hand moves for a full turn, how often the screen updates, how many pixels it has to draw, and how those trade against each other. All four are simple arithmetic, and all four are routinely discussed using numbers that do not mean what people think they mean.

Your in-game sensitivity number is not portable

Sensitivity sliders are scaled per engine. Valorant turns 0.07 degrees per mouse count at a sensitivity of 1; Counter-Strike 2 turns 0.022. So "0.6 sensitivity" describes two completely different speeds in the two games, and comparing the numbers directly is meaningless.

What is portable is eDPI — in-game sensitivity multiplied by mouse DPI. At 0.6 sensitivity and 800 DPI that is 0.6 × 800 = 480 eDPI. Two players with the same eDPI in the same game are moving at the same speed regardless of how they split it between the slider and the mouse. Across different games, eDPI still does not transfer, because the engine scaling has not gone away.

cm/360 is the number that actually transfers

The measurement that survives every game and every mouse is how far your hand travels for one full rotation. Our 0.6 at 800 DPI in Valorant works out to 27.21 cm/360 — a little over a hand-span of mousepad per complete turn.

To keep that muscle memory in CS2 you scale by the ratio of the yaw values: 0.6 × 0.07 ÷ 0.022 = 1.909. Set that, and CS2 also gives 27.21 cm/360. The sensitivity numbers look nothing alike; the movement is identical. This is why converting is worth doing properly rather than eyeballing a number that "feels about right" — every hour spent on a mismatched setting is aim training you have to undo.

One practical rule: convert first and keep the DPI you already had. Change the speed later, deliberately, if you actually want it different. Changing both at once means you cannot tell which change caused what.

Frame time, not frame rate, tells you what you will feel

Frames per second is a rate, and rates flatten differences at the top end. Convert to frame time — milliseconds per frame — and the picture changes completely.

60 fps is 16.67 ms per frame. 144 fps is 6.94 ms. 240 fps is 4.17 ms. So going from 60 to 144 removes 9.72 ms of latency, while going from 144 to 240 — a bigger jump in fps — removes only 2.78 ms. The first upgrade is transformative and the second is subtle, and the frame-time figures say so plainly while the fps figures actively mislead.

Frame time is also the right unit for judging stability. An average of 144 fps with occasional 40 ms frames feels far worse than a locked 100 fps, because what you notice is the inconsistency rather than the mean. Averages hide exactly the thing that ruins a flick.

Resolution costs pixels, and pixels scale with the square

1080p is 1920 × 1080 = 2,073,600 pixels. 1440p is 2560 × 1440 = 3,686,400 — 1.78× as many, not 1.33× as the "1080 to 1440" naming suggests. 4K is 8,294,400 pixels, 2.25× 1440p and four times 1080p.

Render scaling works the same way in reverse, which is where people get caught out. Setting 75% scale at 1440p does not remove 25% of the work — it renders at 1920 × 1080, which is 56% of the pixels. If you want to halve the rendering load, the scale you need is about 71%, because 0.71² ≈ 0.5. Every percentage point of scale is worth roughly two points of pixel count.

Putting them together

These four numbers interact. Dropping resolution or render scale buys frame time, and frame time is what latency is made of. But changing resolution can change your field of view or your HUD scale, and changing field of view changes how far a given hand movement traverses the screen — so a resolution change can quietly undo a sensitivity setting you spent weeks learning.

Set the sensitivity in cm/360 and record it. Then tune resolution and settings for stable frame time rather than a high average. Then leave the sensitivity alone.