Fix cursor display on higher resolutions - #70
Open
JusticarProgramming wants to merge 3 commits into
Open
Conversation
|
Development builds of bb4b98b: The links work without a GitHub account. Artifacts expire after 90 days, and this comment follows the latest successful build. |
JusticarProgramming
force-pushed
the
fix/cursor-display
branch
from
August 29, 2026 15:12
bb4b98b to
f7e017b
Compare
Krisztiaan
suggested changes
Sep 5, 2026
| @@ -293,6 +293,9 @@ void WWMouseClass::Release_Mouse(void) | |||
| ClipCursor(NULL); | |||
| if (GetCapture() == Window) ReleaseCapture(); | |||
| while (ShowCursor(TRUE) < 0) {} | |||
|
|
|||
| SetCursor(LoadCursor(NULL, IDC_ARROW)); | |||
Contributor
There was a problem hiding this comment.
This restores the arrow for EVERY mouse release, like score and mission briefing paths too, that call Hide_Mouse(). Release_Mouse() increments the win display counter here and through Show_Mouse(), seems like one subsequent hide would leave the cursor visible. Scope arrow restoration to dialog handoff, or rebalance the counter, check the non-dialog callers too possibly.
Member
|
I think this PR might also just outright break cursor scaling. |
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
3 participants
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.
Summary
The in-game interface is laid out in fixed pixels, so at the higher render
resolutions OpenTS supports the sidebar, tab bar, dialogs, and readouts stay
the same on-screen size while only the tactical view grows. This adds a
configurable interface scale so the UI can be enlarged to match the resolution
without giving up the wider tactical view.
Add
[Video] UIScale(an integer multiplier, default 1) and scale the sidebar,tab bar, radar, dialogs, and their text by that factor. The tactical view keeps
the full render resolution and is shrunk only by the extra width the scaled
sidebar occupies.
Behavior and compatibility
Presentation-only. The UI layout is not part of the deterministic simulation,
the save format, or network packets. Confirm that the sidebar's serialized
state (
SidebarClass::SerializeandStripClass::Serialize) persists onlyslot indices and scroll positions in slot units, never scaled pixel values.
Validation
-A Win32(MSVC 19.44.35207).GameD.exe).Game.exe).logstress).Documentation
manual/changes/cursor-size-cap.mdmanual/changes/cursor-dialog-visibility.mdmanual/content/keys/cursorscale.md— notes the system-cursor size cap.Checklist