The visible cursor in a game menu sits at one screen position while clicks register somewhere else because the pointer you see and the input hit-test the game reads are driven by separate coordinate systems that disagree. The rendered cursor is often a software sprite drawn at one scale or resolution, while selection uses the engine's internal coordinate or raycast space. When those two spaces diverge, the offset you see is the gap between them. This explainer covers why the mismatch happens at the mechanism level, how large offsets can get, which situations trigger it most, and what you can actually do about it.
The two-coordinate problem behind the offset
Every click a game menu handles is a coordinate conversion problem. The operating system delivers a pointer position in one space. The game engine then converts that position into its own space to decide what you selected. A game can fail to register a click exactly where you see the cursor when that conversion chain breaks at any link.
On a desktop, the layered path usually runs from hardware to OS to engine to renderer. The mouse or controller reports motion to the operating system, which composites it into a cursor position. The game window then reads that position as client-area pixels. The engine maps those pixels to its UI canvas, and the UI canvas maps them to widgets. Each step applies a transform.
The cursor mismatch appears when two of those transforms no longer invert each other. The two common cases are a scale mismatch and a coordinate-space mismatch.
A scale mismatch happens when the cursor is drawn in physical pixels but hit-tested in a virtual or logical resolution, or the reverse. A game running at 3840×2160 with a native UI canvas of 1920×1080 is a typical example. If the cursor is blitted to the framebuffer at native 4K coordinates while the UI hit-tests in virtual 1080p space, the visual pointer lands at one point and the selection lands at a scaled version of it. The visible cursor and the registered point stay within about half the scaling error of the true position. At 2× scaling that individual discrepancy is small, but it grows as you move farther from screen center.
A coordinate-space mismatch is different. This is when the visible cursor is drawn in one screen space and hits are cast in a world or raycast space, usually with a camera in between. Third-person games with a gamepad-driven cursor are the clearest example. The engine projects a ray from the camera through the cursor plane and resolves it against UI geometry. If the camera has its own interpolation, offset, or FOV, the projected ray and the drawn cursor can diverge. The divergence is largest at the screen edges and grows with FOV and camera distance.
A third mechanism sits underneath both: lag between the rendered cursor and the registered hit. Input is sampled at a fixed rate and drawn on a different cadence. A game at 60 frames per second has a fresh visual frame every ~16.7 milliseconds, but the cursor sprite can trail the hit-test by one or more frames. Hover selection and click registration sometimes read from different sample points, which is why a fast-moving pointer can click its trail rather than the item under the visible tip.
In plain terms, the cursor you see and the cursor the game checks are two different guesses at where the pointer is.
How large the offset gets
Offsets are not random. Their size follows the transform error that produced them.
Resolution scale is the dominant factor in the scale-mismatch case. If the UI canvas is half the render resolution and the mapped coordinates are not corrected, the error scales with distance from the canvas origin. At 1080p against a 4K render target, a click near the right edge of a menu can miss by roughly the width of a small icon, tens of pixels in a typical layout. Many engines correct this automatically, so the mismatch appears mainly in ports, emulators, or titles with custom UI code.
Aspect-ratio mismatch has a disproportionate effect because it breaks horizontal and vertical mapping separately. Ultrawide displays at 21:9 with a 16:9 UI layout can show horizontal compression. A 1.33× horizontal stretch relative to a 16:9 canvas can push a click outward by several percent of screen width near the edges.
Raycast or camera-projection error in third-person menus can be larger. A small camera offset of a few world units translates into a visible error at the edges of a large menu plane. At a 60-degree FOV the projected error is roughly proportional to the tangent of the angle between the cursor ray and the camera axis, so it can balloon near the corners.
Frame lag is usually the smallest offset in normal play but the fastest to grow with pointer speed. At 60 fps, a pointer moving at 1000 pixels per second can drift about 17 pixels per frame of lag. At 30 fps, the same movement drifts about 33 pixels per frame.
Controller pointer implementations can be the worst case. A gamepad-driven cursor has its own acceleration curve and its own deceleration. Many implementations draw the cursor at the filtered, smoothed position while hit-testing the raw, unfiltered position. The two can differ by tens of pixels during quick stick movements, and the mismatch vanishes once the stick is still.
The counterintuitive part is that a perfectly aligned cursor at screen center proves nothing. Scale and projection errors are often zero at the origin and grow outward, so center-screen menus can behave perfectly while edge-screen menus feel broken.
Timeline of a misplaced click
The sequence below shows where alignment breaks in a typical mis-mapped menu.
| Stage | What happens | Where offset can enter |
|---|---|---|
| 1. Input sampling | OS reads the pointer at a fixed report rate, often 125–1000 Hz | Report jitter, coalescing |
| 2. Cursor compositing | OS and game draw the cursor sprite | DPI scale, sprite/hit-point mismatch |
| 3. Hit coordinate read | Engine reads the pointer as logical pixels | Virtual resolution, letterboxing |
| 4. UI coordinate transform | Engine maps to canvas or world space | Scale factor, aspect correction |
| 5. Raycast or projection | Camera resolves the cursor against menu geometry | FOV, camera offset, near plane |
| 6. Hover and click use | UI chooses the selected widget | Different code paths for hover vs click |
| 7. Render | Frame displays selection state | Frame lag vs input sample |
The two places misalignment most often enters are stages 3–4 (scale mismatch) and stage 5 (projection mismatch). Stage 6 matters because hover and click can disagree even when the cursor is drawn correctly. A game can highlight the wrong item on hover and then click a different item, which tells you the hover and click code read different pointer values.
Edge cases that amplify the gap
Several conditions reliably make an offset worse. Each is worth checking when the problem looks intermittent.
Windowed and fullscreen exclusive modes handle coordinate scaling differently. Windowed mode adds a window offset, and some engines forget it in one code path. Fullscreen exclusive mode adds its own resolution switch that can leave the UI canvas at the old size.
Display scaling adds a layer. macOS with Retina and Windows with 125–200% DPI both separate physical and logical pixels. A game that reads physical pixels but draws logical cursors, or the reverse, will show a systematic offset.
HDR and variable refresh rate can add frame pacing variation. The cursor is composited by the OS in some modes, by the game in others, and the two can drift by a frame under VRR.
Controller-driven menus have the strongest projection effects. Mouse-driven menus mostly suffer scale mismatch, while gamepad-driven menus suffer camera projection and smoothing lag.
Emulation and compatibility layers introduce their own mapping. Translation and shader layers can change the render resolution without telling the UI. A cursor that is correct in the emulator's overlay can be wrong in the game's own hit-test.
Here are the red flags that point to an engine-side mapping defect rather than hardware:
The offset scales with distance from the menu's top-left corner. The offset changes when you resize the window or change resolution. Hover highlights one item while the click selects a neighbor. The cursor is centered correctly in one menu but off in a separate menu with its own canvas. The offset vanishes when the pointer stops moving for a second. Mouse and controller pointers behave differently in the same menu.
What the symptom is not
Several common explanations are incomplete or wrong. Clearing them avoids wasted troubleshooting.
The offset is not usually a broken mouse sensor. A sensor issue produces jitter, dropped tracking, or uneven acceleration, not a consistent displacement across a static menu or in one UI element. If the error is stable at a fixed pointer position, the sensor is fine.
It is not a website-style CSS problem, and no amount of clicking harder changes it. UI hit-testing in games uses engine coordinate math, not browser layout.
It is not always a driver bug. GPU drivers can introduce composition issues, but a driver-level cursor offset usually shows up system-wide, not only in one game menu. If the pointer is correct on the desktop and wrong only in one menu, the fault is in the game's coordinate path.
It is not fixed by DPI awareness alone. DPI-aware mode stops the OS from scaling the window, but the game can still hit-test in the wrong logical space. DPI awareness removes one layer of error rather than all of them.
Finally, a shared overlay or streaming layer can be the wrong suspect. Some overlays draw their own cursor and hide the game's, which makes diagnosis harder because the visible pointer belongs to a different process. The solution is to test by hitting a mark at a known position, not by watching the visible cursor.
Practical steps to test and reduce the offset
Work from the largest error source down. The goal is to separate a mapping bug from lag, and the best test is to compare the visible cursor location to the reported click position at a fixed contact point.
Test at three fixed targets: top-left menu item, center item, and bottom-right edge item. Top-left is usually the numeric anchor, and center-item accuracy tells you whether the error is projection-related. If the top-left target registers correctly and the bottom-right does not, the bug is a scale factor. Toggle between fullscreen exclusive and windowed mode at the same resolution. A mode change that alters the offset points to resolution switching or canvas-size handling. Change the game's render resolution without changing the display resolution. If the offset changes, the UI canvas is not tracking the render target. If it stays constant, suspect a projection or DPI layer. Set the OS display scale to 100% if you run at 125–200%. If the offset disappears, the game is mixing physical and logical pixels. Compare mouse and controller pointers in the same menu. If only the controller is off, the cursor's smoothing is decoupled from hit-testing. That points to input-path sampling rather than a scale bug. Check frame pacing. If a fast pointer misclicks but a slow pointer does not, the hover code path has more lag than the click code path.
Handling tips that reduce the symptom in games without a patch: slow the pointer for menu navigation, aim for the anchor edge of a button, prefer keyboard or controller selection where available, and run at native display resolution with 100% scaling. Keep the game's internal resolution matched to the windowed size when testing; mismatching them reintroduces the scale error. If the menu offset scales with camera FOV, reach the menu from a neutral camera position if the game allows it. None of these fix the underlying mismatch, but they reduce the perceived severity.
For the developer side, the corrective steps are to hit-test in the same coordinate space the cursor is drawn in, to apply the same scale and aspect transform to hover and click, and to validate the cursor position against instrumented hit-test coordinates at the corners and center of every canvas.
Limits: what you cannot fix from the store page
Diagnosis without source access has a ceiling. You can identify a scale mismatch or a projection bug, but the patch lives in the game. A consistent, reproducible offset that follows resize and resolution changes is an engine-level mapping defect, and the practical fix is the developer's.
Some platforms hide the pointer so they can draw their own cursor. When a launch wrapper or compatibility layer adds its own cursor, the visible pointer is correct for the wrapper and wrong for the game's hit-test, which makes the offset look worse than the game's actual mapping error.
Streaming and remote play add latency that produces a different error. A pointer sampled at the client is applied to the video frame the server has already rendered, so the visible location and the registered location are separated by network latency and client-side prediction. This is not the same as a coordinate mapping bug, and no local setting resolves it.
If you are using a title where the pointer is off in only one menu and the steps above pin it to a fixed scale or projection error, contact the developer with the resolution, scaling, and window mode. That is more useful than any local setting.
This article is general educational information about how game input and UI coordinate systems behave, not a diagnosis of a specific game or device, and not a repair or configuration service. It does not promise that any setting will correct a bug in software you do not control. For hardware or software you own, consult the game's manufacturer or platform support if the behavior is severe enough to block use.