Repository navigation
Conversation
lockApps (and the lock tells) put DOOM: The Dark Ages menus on the locked path: the view pans from raw mickeys and the weld re-parks the real pointer once per tick. The sprite hid that; the native cursor is the real pointer, drawn by DWM wherever the hand moved it between ticks, so it wandered around the centre and snapped back (4.7x: 22 px spread slow, 74 px medium, jumps to 118 px; free with DWM centring: 0 px). Games show the pointer in menus and hide it for mouselook, so in a native-cursor session the lock applies only while GetCursorInfo reports the pointer hidden (LockApplies). Every gate reads the tick's result (t.lockEff). The sprite path keeps the old rule. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011zPmivSAQeivGUdBjTsaMu
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #378.
What happened
Field video: with the native cursor, the zoomed view tracked the pointer perfectly on the desktop, but in DOOM: The Dark Ages menus the cursor was laggy and unstable. Old Wind (sprite) and Windows Magnifier did not do this.
Cause
lockApps=DOOMTheDarkAges.exeforces the locked path: the view pans from raw mickeys, DWM centring is off, and the weld re-parks the real pointer once per tick. The sprite hid this because it is drawn at the re-parked point. The native cursor IS the real pointer, and DWM draws it wherever the hand moved it between ticks. The result is a cursor that wanders around the centre and snaps back. Doom's gold arrow is a real Windows cursor shape, so DWM composes it like any other pointer.Fix
Games show the pointer in menus and hide it for mouselook (the case the locked path exists for). So in a native-cursor session the lock applies only while
GetCursorInforeports the pointer hidden. This isLockAppliesinsrc/native_cursor.h, and every gate reads the tick's result,t.lockEff. A shown pointer gets DWM centring, which is what Windows Magnifier does there. The sprite path keeps the old rule. The new log line islock pointer shown: free (native cursor).Verification
Unit suite: 593/593 (new
LockAppliescase).build.bat checkis clean.Desktop reproduction (
C:\REharnesslocked_cursor_test.py): black backdrop, forced lock (lockForce=1), relative sweeps at ~4.7x, pointer tip tracked per captured frame.2 px is the detector's resolution.
In DOOM: The Dark Ages, main menu with your
lockApps: the log showspointer shown: free. Across seven captured frames of a sweep, the gold cursor stays on one screen point while the menu pans underneath.Deployed (signed UIAccess) on the dev PC.
Not tested: Doom gameplay (mouselook). There the pointer is hidden, so the lock applies exactly as before. Please check that the view still pans with mouselook in-game.
🤖 Generated with Claude Code
https://claude.ai/code/session_011zPmivSAQeivGUdBjTsaMu