Fix: Mouse Lag and Input Delay in CS 1.6

Mouse lag in CS 1.6 is rarely the mouse. It is usually the display or network pipeline adding delay between your hand moving and the shot registering: a frame cap, v-sync, an interpolation setting, or Windows mouse smoothing sitting on top of raw movement. This works through the causes from most to least common so you can find yours quickly instead of changing ten things at once.

1. Lift the frame cap and disable v-sync

The biggest source of felt lag is a low or v-synced frame rate. Every frame you are not rendering is input you are not seeing. Raise the cap well above your refresh rate and turn v-sync off in the engine:

fps_max 300
gl_vsync 0

V-sync in particular adds a full frame or more of latency by holding rendered frames back to match the monitor. Disable it in the driver as well — the NVIDIA settings guide shows where. If frames are low regardless of the cap, that is a performance problem; see the FPS boost guide first, because you cannot fix input lag on top of 40 FPS.

2. Turn on raw input

Raw input reads the mouse directly and bypasses the Windows pointer pipeline, including acceleration and smoothing:

m_rawinput 1

With raw input on, the game ignores the Windows "Enhance pointer precision" acceleration entirely, so your aim is 1:1. This alone fixes the "my aim feels floaty" complaint for most players. Full detail is in the raw input and acceleration guide.

3. Fix the rate and interpolation settings

Network settings can masquerade as mouse lag because your shots feel like they land late. Set sane rates so the server updates you frequently:

cl_cmdrate 101
cl_updaterate 101
rate 100000

Then set interpolation to the smallest value the server allows. A high ex_interp deliberately delays what you see to smooth other players' movement, which feels like lag:

ex_interp 0.01

On a good connection 0.01 (10 ms) is standard; the engine clamps it to the server's minimum anyway. See the client rates guide for the values matched to your ping, and the server-side rate caps that limit what you can request.

4. Disable Windows pointer acceleration

Even with raw input, it is worth turning off Windows acceleration globally so every game behaves. In Settings > Bluetooth & devices > Mouse > Additional mouse settings > Pointer Options, uncheck Enhance pointer precision. Set the pointer speed slider to the middle (the 6th notch), which is 1:1 with no scaling. The legacy launch options that force this off still work as a belt-and-braces measure:

-noforcemparms -noforcemaccel -noforcemspd

5. Rule out the hardware path

If lag persists after all of the above, test the mouse itself. Set the polling rate to 1000 Hz in the mouse's own software, plug it directly into a rear USB port rather than a hub or front-panel port, and disable any driver-level "angle snapping" or smoothing. A worn USB cable or a dying switch produces intermittent lag that no cvar can fix.

Common errors

• Aim feels floaty and delayed — Windows acceleration is active. Enable m_rawinput 1 and uncheck Enhance pointer precision.
• Smooth in menus, laggy in a firefight — frame rate drops under load. This is a performance issue, not input; raise FPS first.
• Shots register late despite good FPS — high ex_interp or low cl_updaterate. Lower interp and raise the rates.
• Lag only with v-sync-like smoothness — v-sync is on in the driver even though gl_vsync 0. Turn it off in the control panel too.
• Intermittent stutter unrelated to settings — USB hub, low polling rate, or a failing cable. Move to a rear port and set 1000 Hz.

Verification

Enable the net graph and watch it while you move:

net_graph 3

FPS should be high and stable, and the choke/loss figures near zero — if choke spikes when you move, the problem is network, not mouse. Then do a slow flick across a fixed point on the wall: the crosshair should track your hand exactly with no drift or catch-up, which is the signature of raw input working. If it still drifts, acceleration is sneaking in from Windows or the mouse driver. Once movement is 1:1, dial in sensitivity knowing the input path underneath it is clean. A last sanity check: quit every background overlay (recording software, RGB utilities, browser hardware acceleration) and retest, because an overlay hooking the render path can add a frame of latency that survives every in-game fix. Input lag is cumulative, so removing one cause at a time and re-testing with the net graph is the only reliable way to find which layer is responsible.