validation rollup: safe compat splits from PR 169 - #192
Draft
mstan wants to merge 4 commits into
Draft
Conversation
[hotkeys] rewind_pad / save_state_menu_pad accept the recomp-ui pad encoding, where 1000 + a button bitmask is a CHORD. The parse guarded on `n < 256`, which admits single buttons and rejects every chord there is — including the two values this same file writes back out (1272 = select+r3, 2040 = select+r1). A saved chord was silently dropped on load and the defaults quietly reinstated, so the pad hotkeys were never actually configurable. The bound predates the chord encoding; the runtime's own normalize_hotkey_pad_binding has handled combos correctly all along. Replaced with pad_bind_value_ok(), sharing one documented bound with the encoding it validates. Verified against a live boot with rewind_pad = 1017 (select+cross): parsed has=0 value=1272 before, has=1 value=1017 after. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit 165fae0)
mstan
changed the title
Without it Windows virtualises everything the process sees. On a 7680x4320 panel at 400% scaling SDL_GetDisplayUsableBounds reports 1920x1032, so clamp_window_aspect fits the window to roughly 1376 LOGICAL pixels and it opens as a small box that the desktop compositor then upscales. The internal render resolution is unaffected, which is what makes this expensive rather than cosmetic: the game renders at supersampling 16 and the result is thrown away scaling a 1376-wide window up to an 8K display. Choosing a high internal resolution and getting a small blurry window is the exact opposite of the intent. permonitorv2 makes SDL report physical pixels, so the window sizes against the real panel and the drawable matches it 1:1. Set before both SDL_Init call sites, guarded on the hints existing so it builds against older SDL. Also changes g_video_win_w's default from a hardcoded 1280 to 0, meaning "fit the display", clamped to the usable bounds and the configured aspect. An explicit width still wins. 1280 was a reasonable default when a window was a window; it is not one on a 4K or 8K panel. Diagnosed after reporting the display as 1920x1080 from a non-DPI-aware query and telling the user their panel could not be larger. It is 7680x4320; the measurement was virtualised, not the display. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> (cherry picked from commit 236778e)
clamp_window_aspect fits the CLIENT area to the usable bounds, but a window is client plus title bar and borders. On a display whose usable height it exactly matched, the result was a window taller than the screen: client 5504x4128, window 5550x4263, positioned at y = -112 and hanging off the top. Deriving the decoration size first does not work either. SDL_GetWindowBordersSize reports nothing useful before the window has been shown, so a post-creation correction based on it silently did not apply -- the window stayed exactly as wrong, which is worse than not trying. The window manager already solves this exactly, so ask it: SDL_MaximizeWindow fits the work area with decorations and taskbar included. Measured on a 7680x4320 panel, client area is now 7680x4039 against 5504x4128 before. Only when the width was not explicitly chosen -- an explicit window_width is a deliberate decision and is left alone. Suggested by the user after two failed attempts at doing the arithmetic here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> (cherry picked from commit d6d0946)
(cherry picked from commit c7a3d59)
mstan
force-pushed
the
validation/pr169-input-window-rollup
branch
from
August 23, 2026 23:58
b4bc498 to
3a5939a
Compare
Owner
Author
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.
Draft validation rollup for user suite testing. Split from original PR #169 by tetrisgm; original PR intentionally left open.
Includes these already-open split PRs:
Explicitly removed:
Intent:
Validation:
Notes: