Scale the GUI with resolution and user preference - #53
Open
Rokk001 wants to merge 9 commits into
Open
Conversation
Rokk001
marked this pull request as ready for review
September 5, 2026 23:15
Owner
|
This sounds really promising will try it ASAP. |
Owner
|
Also it never pour but it rains : I Have now access to laptop with only 4 cores during next 7 days ... so building and checking every PR takes time . |
Author
|
The commits repeat because my branches build on each other while targeting the same upstream branch. I need to separate the contributions properly, and there is no rush on testing given your limited hardware. |
Embed per-monitor DPI awareness and maintain the verified OGRE 13.6.5 renderer patch required for context-safe window replacement, runtime GL options and correct fullscreen client geometry. Validation: clean Release build, DPI and 3440x1440 fullscreen probes, three GL3Plus variants and the patch reverse check passed; version 0.7.1 remains unchanged because this is unreleased work and the project has no changelog.
Apply display, input, audio, gameplay, minimap, shadow and negotiated nickname changes to the running session while preserving rollback for failed window or input transitions and keeping the 3440x1440 navigation visible. Validation: clean Release and Debug builds, packet tests, DPI, layout and GL3Plus probes passed; the user confirmed the reported resolution, fullscreen, cursor, flicker and navigation failures are fixed. Version 0.7.1 remains unchanged because this is unreleased work and the project has no changelog.
The spells tab put its ten buttons in a single row of 60 pixel squares running out to x=700. The pane they live in is the window width minus the 200 pixels of minimap, so at the 800 wide minimum window it is 600 pixels across, and the last two spells, Weakness and the Eye of Evil, hung past its right edge where they could be neither seen nor clicked. Only a window at least 900 wide showed the whole row, and nothing said so. The rooms tab solved the same problem long ago: two rows of 40 pixel buttons. The spells tab now uses the same shape, five spells to a row, ending at x=300 with room to spare at any size the game accepts. The cooldown bar inside each button now covers exactly its button too, instead of overhanging 20 pixels on both sides, which with narrower buttons would have bled half way across the neighbours. The rooms tab had the tail of the same bug: the temple and portal buttons the editor uses sat at x=570 to 690, past the same edge. They join the end of the second row instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> (cherry picked from commit 10db1cb)
Rokk001
force-pushed
the
feature/gui-scaling
branch
from
September 6, 2026 23:12
e21d08e to
508e59d
Compare
This was referenced Sep 6, 2026
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.
The interface used fixed pixel geometry, which caused clipped or misaligned controls and pointer targets at different resolutions and scale preferences.
Change
Coordination
Depends on #47, #49, #50 and #51. This addresses scaling and pointer-alignment portions of issue #6 without closing its broader interface report.
Verification
Static layout checks covered representative window sizes and scale values during development. The reconstructed branch completed a clean Windows x64 Release build, and the user accepted live scaling, settings layout and aligned pointer input. Other platforms remain unverified.
Review only the GUI-scaling changes