The game runs in its window — but the mouse is wrong. It freezes in the middle of the screen, slides out of the window onto your desktop, clicks land a centimetre away from where the cursor appears, or the pointer works but is trapped in an invisible box much smaller than the window. Mouse problems are the second most common DxWnd complaint after hooking failures, and they have a clear root cause: the games DxWnd serves were written for a world where the game owned the entire screen and the mouse with it. This guide sorts the symptoms, explains why each happens, and gives the fixes in a sensible order.
Know Your Symptom
- Frozen or immovable cursor — the pointer will not move at all, or only twitches in the centre of the window.
- Escaping cursor — the pointer drifts out of the game window onto the desktop, and clicks land on whatever is behind.
- Offset cursor — the pointer moves, but clicks register displaced from where it is drawn; menus highlight in the wrong place.
- Clipped cursor — the pointer moves freely but only inside a region smaller than the window, as if an invisible wall surrounded part of the screen.
Each symptom points somewhere different: frozen is usually focus or capture, offset is usually scaling, clipped is usually a mismatch between the game’s assumed screen size and the actual window.
Why Windowed Games Fight the Mouse
A fullscreen game of the DirectDraw era captured the mouse exclusively: it received raw movement, hid the Windows pointer, and drew its own cursor wherever the game logic said it was. In a window, that model collides with reality — there is a desktop, a Windows cursor, and a window frame, and the game, DxWnd and Windows must agree on which coordinate system is in use. Most mouse bugs are really coordinate disagreements: the game thinks the screen is 640×480, the window is 1280×960, Windows is scaling one into the other, and nobody told the cursor. Keep that picture in mind; it explains why the fixes below are what they are.
Fix 1: Give the Window Focus First
It sounds too trivial to list, and it resolves a surprising share of “frozen mouse” reports: click once inside the game window after it opens. A game that has not received focus may never take mouse input, and Windows will happily route your movements elsewhere. If the cursor wakes up after a click, your problem was focus, not configuration. Relatedly, avoid Alt+Tabbing away and back during play when a game holds the mouse — capture is often lost or half-reacquired on the round trip, and restarting the launch through DxWnd is cleaner than fighting a confused capture state.
Fix 2: Match the Window to the Game’s Resolution
For offset and clipped cursors, align the geometry. Set the DxWnd window size to the game’s own rendering resolution — the size it would use fullscreen, typically 640×480 or 800×600 for the era — so that one game pixel equals one window pixel and no scaling layer sits between the game’s coordinates and yours. You can enlarge later once the mouse is truthful; scaling a working setup is a separate experiment, and our main tutorial covers the window size settings. If the game itself has a resolution option, set game and window to the same value.
Fix 3: Override Windows DPI Scaling for the Game
On high-resolution displays, Windows often scales older programs so they are not microscopic — and that scaling quietly rewrites mouse coordinates, the classic cause of the offset cursor. The Windows-side fix: right-click the game’s .exe > Properties > Compatibility > Change high DPI settings, tick the override option, and set scaling to be performed by Application. This tells Windows to stop translating the game’s coordinates and let the game (via DxWnd) present them honestly. It is a per-game setting; your other programs are unaffected. Windows 11 players will find the companion setting — disabling fullscreen optimizations — in our DxWnd on Windows 11 guide.
Fix 4: Adjust the Profile’s Mouse Settings
DxWnd’s profile dialogs include mouse- and input-related settings that control how the cursor is handled inside the window — how it is captured, clipped and shown. If the steps above narrow the problem but do not cure it, this is where per-game tuning happens: open the profile, look through the Input/mouse settings, and change one behaviour at a time, testing between changes. There is no universal right answer here, because games implemented their cursors in genuinely different ways; a title that draws its own cursor needs different treatment from one that uses the Windows pointer, and DxWnd exposes these options precisely because both exist.
Work through these settings the way you would debug anything: one change, one launch, one verdict. Mouse fixes are especially prone to false conclusions, because a game can behave differently between its menus and actual gameplay — test the mouse where you actually play, not only on the title screen, and only call a setting “the fix” once it has survived a few minutes of real play. When you find the combination that works, save the profile; the result is stored per game, so the evening you spend tuning one title does not have to be repeated for the next.
Honest Limits
Most DxWnd mouse problems yield to focus, geometry and DPI fixes. A minority of games have genuinely idiosyncratic input code and need a community profile or a per-game fix in a new build — if your title is one of them, the project’s SourceForge forum is where those solutions accumulate, and describing your exact symptom (frozen, escaping, offset or clipped) will get you a useful answer much faster than “mouse broken.” The troubleshooting hub collects the related guides, including the general not-working checklist if the mouse is only one of several things going wrong.