Repository navigation
feat(menu): the Aspect ratio and Output resolution from the screen's display modes - #2566
Conversation
|
Tested on a real 21:9 screen: Windows 11, RTX 5090, primary monitor 5120x2160 at 125% scaling, plus a 1440x2560 portrait secondary. Build of this branch at a8f7f9d, headless runs ( The screen's modes ( Works as described
Not as described: 21:9 is the monitor's own shape here, and its list is the 16:9 sizes widened With the Aspect ratio at 21:9 (monitor's), the Output resolution offers, narrowest first: 1704x720 · 2120x896 · 2560x1080 · 2048x1152 (game's) · 3416x1440 · 4264x1800 · 5120x2160 (native) Each of these is a 16:9 size at the monitor's shape: 1280x720, 1600x900, 1920x1080, 2560x1440, 3200x1800 (a common 16:9 size, not a mode here) and 3840x2160, widened at their height. The file confirms it: after stepping to 1704x720,
My guess is that the monitor's shape still goes through the old Ultrawide rule ( Windowed, on the same PC (picture 3416x1440, the first-start default):
Not tested yet: F11 and Alt+Enter, the game alone on the portrait monitor, and DLSS / DLSS-G at 21:9. Two suggestions from playing it
|
…ape its size, the game's own as drawn From a test on a 5120x2160 primary (NotRexed#2566's comment): - Stepping the Aspect ratio away from the shape the game started with and back took that shape's own pick (5120x2160) and asked to restart, though nothing differed from the start. Back at the start's shape it is now the size the game started with (output_for_aspect, output_started). - The game's own size showed its 16:9 2048x1152 in the 21:9 list, though ultrawide=1 draws it at the host's shape: it now shows that picture (2728x1152 at a 5120x2160 screen's 21:9), as the game draws it. - The sizes log said "no other" where no size of the player's own was read, which read as no common sizes: it now says what the list holds. test_output_resolution: that screen's 21:9 modes, a first start at 21:9 (monitor's) with the game's own size: the arrows walk the 21:9 modes up to 5120x2160 (native), and 16:9 then back keeps the game's own. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@pmwork-personal Thanks, this is exactly the screen I couldn't test. Your build ( The 21:9 (monitor's) list was 16:9 sizes widened. You were right: the arrows walked the 16:9 sizes from a 16:9
On your screen, Right from the first start's game's own size now goes 2560x1080 → 3408x1440 → 3440x1440 → 3936x1656 → 4352x1832 → 5120x2160 (native). "2048x1152 (game's)" with its 16:9 numbers. 14320fa: it now shows what the game draws at the monitor's shape. That's 2728x1152 on your 5120x2160, the same figure you worked out. Back at 21:9 gave 5120x2160 and "Restart needed". 14320fa: going back to the shape the game started with now gives back the size it started with, so there's nothing to restart for. "no other" in the log. That meant "no size of your own", not "no common sizes". Your list did get 16:9's common sizes: 3200x1800 is the 4264x1800 you saw. The line now says Also new since your build:
On your setup, the window on the 1440x2560 portrait screen should now show the separate Monitor's shape value. It's still a shape the game can't draw. Suggestion 2, rendering at the window's size live: I agree it'd be nicer, but it's a different mechanism. The picture's shape is fixed at boot: If you have time, a retest at the head on the same screen would cover what changed. Thanks again for the detailed run. |
14320fa to
0f1a272
Compare
…ape its size, the game's own as drawn From a test on a 5120x2160 primary (NotRexed#2566's comment): - Stepping the Aspect ratio away from the shape the game started with and back took that shape's own pick (5120x2160) and asked to restart, though nothing differed from the start. Back at the start's shape it is now the size the game started with (output_for_aspect, output_started). - The game's own size showed its 16:9 2048x1152 in the 21:9 list, though ultrawide=1 draws it at the host's shape: it now shows that picture (2728x1152 at a 5120x2160 screen's 21:9), as the game draws it. - The sizes log said "no other" where no size of the player's own was read, which read as no common sizes: it now says what the list holds. test_output_resolution: that screen's 21:9 modes, a first start at 21:9 (monitor's) with the game's own size: the arrows walk the 21:9 modes up to 5120x2160 (native), and 16:9 then back keeps the game's own. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
0f1a272 to
bd8fd68
Compare
…ape its size, the game's own as drawn From a test on a 5120x2160 primary (NotRexed#2566's comment): - Stepping the Aspect ratio away from the shape the game started with and back took that shape's own pick (5120x2160) and asked to restart, though nothing differed from the start. Back at the start's shape it is now the size the game started with (output_for_aspect, output_started). - The game's own size showed its 16:9 2048x1152 in the 21:9 list, though ultrawide=1 draws it at the host's shape: it now shows that picture (2728x1152 at a 5120x2160 screen's 21:9), as the game draws it. - The sizes log said "no other" where no size of the player's own was read, which read as no common sizes: it now says what the list holds. test_output_resolution: that screen's 21:9 modes, a first start at 21:9 (monitor's) with the game's own size: the arrows walk the 21:9 modes up to 5120x2160 (native), and 16:9 then back keeps the game's own. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Tested on Linux: Arch, Hyprland 0.56.2 (Wayland), i9-13900K, RTX 4090 with NVIDIA 615.78.08, one 1920x1080 monitor at 60 Hz and scale 1.25, SDL 3.4.18. The runs are on A windowless start crashes on Linux. With The cause, as far as the evidence goes: the new host screen callback calls With a real window on Wayland it works. 142 s, no crash, no device loss, no driver lines. Stepping both rows by script, the menu offered:
The log: Checks: the eight tests this adds or changes pass with GCC 16.2.1 and Clang 23.1.3 ( Overlap with #2594 (a typed Custom output size, mine): the two conflict in six places in four files, among them the host callbacks both add ( Not tested: fullscreen (my test harness does not allow it), X11 and other compositors, a second monitor, Windows, and the restart that applies the saved 2048x1152. The windowed run's evidence is the log and the menu's own state, not pictures of the menu. |
|
Retest at All three fixes work on this screen
Two small notes on the list. Neither looks wrong to me:
Merging main. GitHub shows the branch conflicting with main. To build it I merged main (up to
With that:
Not tested yet (these need a real window): the window moved to the portrait screen (the |
bd8fd68 to
93dd255
Compare
…ape its size, the game's own as drawn From a test on a 5120x2160 primary (NotRexed#2566's comment): - Stepping the Aspect ratio away from the shape the game started with and back took that shape's own pick (5120x2160) and asked to restart, though nothing differed from the start. Back at the start's shape it is now the size the game started with (output_for_aspect, output_started). - The game's own size showed its 16:9 2048x1152 in the 21:9 list, though ultrawide=1 draws it at the host's shape: it now shows that picture (2728x1152 at a 5120x2160 screen's 21:9), as the game draws it. - The sizes log said "no other" where no size of the player's own was read, which read as no common sizes: it now says what the list holds. test_output_resolution: that screen's 21:9 modes, a first start at 21:9 (monitor's) with the game's own size: the arrows walk the 21:9 modes up to 5120x2160 (native), and 16:9 then back keeps the game's own. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…without SDL, not a call through an empty slot The Insert menu asks the host for the main screen's size at startup and while the game runs (MkwVkHost.screen_size, this PR's), which on Linux is hos_sdl_desktop_size. A windowless start (HOS_HEADLESS) loads no SDL, so version is 0 and the function went on to SDL2's branch and called GetDesktopDisplayMode's empty slot: exit 139 before the first frame (reported on NotRexed#2566 by mooki000, Arch, Hyprland). With no SDL loaded it now says the screen is unknown, and the menu lists the sizes it does without one. Windows takes GetSystemMetrics and was not affected. tests/test_sdl_desktop_size.py cuts the function from hos_sdl.c and runs it against stand-ins: no SDL (unknown, which faulted at address 0 before), SDL3's mode in pixels (1536x864 at a density of 1.25 is 1920x1080), SDL3 with no mode, and SDL2's mode as given or failed. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…them, rounded and with 21:9's common sizes The 5120x2160 case filled the list with six sizes directly. NotRexed#2566's retest on that screen walked eight: 3008x1264 (its 3012x1271 mode rounded down to 8) and 3840x1600 (21:9's common size) as well. The case now takes the screen's modes through display_modes.h offered and with_common, as the list does, and walks the same eight sizes the retest saw. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Thanks to both of you. The branch is now rebased on main through #1864 and #2637, and the head has two new commits for your points. @mooki000 The headless crash on Linux is fixed in 86aa3c4, as you suggested. With no SDL loaded, On Linux the list is the desktop's size plus the common sizes of its shapes, as you saw. SDL gives the menu the desktop mode only, not the monitor's whole mode list. #2594: agreed, the typed size belongs beside this list. Whichever lands second takes the rebase, and thanks for offering to do it on yours. @pmwork-personal Your merge matches the rebase now on the PR: the same five spots in The two sizes the test didn't cover are in 2e14130. The 21:9 case now takes the screen's modes as Windows lists them, including your 3012x1271, through the same rounding and common-size steps as the list. It walks your eight sizes: 2560x1080 → 3008x1264 → 3408x1440 → 3440x1440 → 3840x1600 → 3936x1656 → 4352x1832 → 5120x2160. "(game's)" before 2560x1080: that's its place in the list. The game's own size is choice 0, so older saves keep their
|
… shows At a shape the host widens 16:9 sizes to, the game's own choice shows what the game draws (2728x1152 at a 5120x2160 screen's 21:9) but was walked at its stored 2048x1152, so it came before 2560x1080 and the first Right went down a size (NotRexed#2566's retest). step_output_choice now orders a shape's choices by picture_for, the size each row shows, and the game's own is in the walk of the shape it is drawn at, reached from either side: 2560x1080, 2728x1152 (game's), 3008x1264, ... At 32:9 a kept 1920x1080 (drawn 3840x1080) and the game's own (4096x1152) come before 5120x1440 the same way. What is saved is the choice, as before (output_res=0 for the game's own); handheld draws nothing wider and keeps the old order. test_output_resolution walks the 21:9 screen's nine choices up and back down, and the 32:9 one; test_menu_setting_walk's stand-ins gain picture_for (each choice's own size there). Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@pmwork-personal I made the "(game's)" change in e4caac7. The Output resolution's arrows now go by the size each choice shows. On your screen at 21:9 the order is 2560x1080 → 2728x1152 (game's) → 3008x1264 → …, the same both ways. At 32:9, a kept 1920x1080 (drawn 3840x1080) and the game's own (4096x1152) now come before 5120x1440 as well. Saves don't change: the game's own is still |
e4caac7 to
e0cedba
Compare
…ape its size, the game's own as drawn From a test on a 5120x2160 primary (NotRexed#2566's comment): - Stepping the Aspect ratio away from the shape the game started with and back took that shape's own pick (5120x2160) and asked to restart, though nothing differed from the start. Back at the start's shape it is now the size the game started with (output_for_aspect, output_started). - The game's own size showed its 16:9 2048x1152 in the 21:9 list, though ultrawide=1 draws it at the host's shape: it now shows that picture (2728x1152 at a 5120x2160 screen's 21:9), as the game draws it. - The sizes log said "no other" where no size of the player's own was read, which read as no common sizes: it now says what the list holds. test_output_resolution: that screen's 21:9 modes, a first start at 21:9 (monitor's) with the game's own size: the arrows walk the 21:9 modes up to 5120x2160 (native), and 16:9 then back keeps the game's own. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…without SDL, not a call through an empty slot The Insert menu asks the host for the main screen's size at startup and while the game runs (MkwVkHost.screen_size, this PR's), which on Linux is hos_sdl_desktop_size. A windowless start (HOS_HEADLESS) loads no SDL, so version is 0 and the function went on to SDL2's branch and called GetDesktopDisplayMode's empty slot: exit 139 before the first frame (reported on NotRexed#2566 by mooki000, Arch, Hyprland). With no SDL loaded it now says the screen is unknown, and the menu lists the sizes it does without one. Windows takes GetSystemMetrics and was not affected. tests/test_sdl_desktop_size.py cuts the function from hos_sdl.c and runs it against stand-ins: no SDL (unknown, which faulted at address 0 before), SDL3's mode in pixels (1536x864 at a density of 1.25 is 1920x1080), SDL3 with no mode, and SDL2's mode as given or failed. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…them, rounded and with 21:9's common sizes The 5120x2160 case filled the list with six sizes directly. NotRexed#2566's retest on that screen walked eight: 3008x1264 (its 3012x1271 mode rounded down to 8) and 3840x1600 (21:9's common size) as well. The case now takes the screen's modes through display_modes.h offered and with_common, as the list does, and walks the same eight sizes the retest saw. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… shows At a shape the host widens 16:9 sizes to, the game's own choice shows what the game draws (2728x1152 at a 5120x2160 screen's 21:9) but was walked at its stored 2048x1152, so it came before 2560x1080 and the first Right went down a size (NotRexed#2566's retest). step_output_choice now orders a shape's choices by picture_for, the size each row shows, and the game's own is in the walk of the shape it is drawn at, reached from either side: 2560x1080, 2728x1152 (game's), 3008x1264, ... At 32:9 a kept 1920x1080 (drawn 3840x1080) and the game's own (4096x1152) come before 5120x1440 the same way. What is saved is the choice, as before (output_res=0 for the game's own); handheld draws nothing wider and keeps the old order. test_output_resolution walks the 21:9 screen's nine choices up and back down, and the 32:9 one; test_menu_setting_walk's stand-ins gain picture_for (each choice's own size there). Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ape its size, the game's own as drawn From a test on a 5120x2160 primary (NotRexed#2566's comment): - Stepping the Aspect ratio away from the shape the game started with and back took that shape's own pick (5120x2160) and asked to restart, though nothing differed from the start. Back at the start's shape it is now the size the game started with (output_for_aspect, output_started). - The game's own size showed its 16:9 2048x1152 in the 21:9 list, though ultrawide=1 draws it at the host's shape: it now shows that picture (2728x1152 at a 5120x2160 screen's 21:9), as the game draws it. - The sizes log said "no other" where no size of the player's own was read, which read as no common sizes: it now says what the list holds. test_output_resolution: that screen's 21:9 modes, a first start at 21:9 (monitor's) with the game's own size: the arrows walk the 21:9 modes up to 5120x2160 (native), and 16:9 then back keeps the game's own. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…without SDL, not a call through an empty slot The Insert menu asks the host for the main screen's size at startup and while the game runs (MkwVkHost.screen_size, this PR's), which on Linux is hos_sdl_desktop_size. A windowless start (HOS_HEADLESS) loads no SDL, so version is 0 and the function went on to SDL2's branch and called GetDesktopDisplayMode's empty slot: exit 139 before the first frame (reported on NotRexed#2566 by mooki000, Arch, Hyprland). With no SDL loaded it now says the screen is unknown, and the menu lists the sizes it does without one. Windows takes GetSystemMetrics and was not affected. tests/test_sdl_desktop_size.py cuts the function from hos_sdl.c and runs it against stand-ins: no SDL (unknown, which faulted at address 0 before), SDL3's mode in pixels (1536x864 at a density of 1.25 is 1920x1080), SDL3 with no mode, and SDL2's mode as given or failed. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…them, rounded and with 21:9's common sizes The 5120x2160 case filled the list with six sizes directly. NotRexed#2566's retest on that screen walked eight: 3008x1264 (its 3012x1271 mode rounded down to 8) and 3840x1600 (21:9's common size) as well. The case now takes the screen's modes through display_modes.h offered and with_common, as the list does, and walks the same eight sizes the retest saw. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
e0cedba to
c677723
Compare
…ape its size, the game's own as drawn From a test on a 5120x2160 primary (NotRexed#2566's comment): - Stepping the Aspect ratio away from the shape the game started with and back took that shape's own pick (5120x2160) and asked to restart, though nothing differed from the start. Back at the start's shape it is now the size the game started with (output_for_aspect, output_started). - The game's own size showed its 16:9 2048x1152 in the 21:9 list, though ultrawide=1 draws it at the host's shape: it now shows that picture (2728x1152 at a 5120x2160 screen's 21:9), as the game draws it. - The sizes log said "no other" where no size of the player's own was read, which read as no common sizes: it now says what the list holds. test_output_resolution: that screen's 21:9 modes, a first start at 21:9 (monitor's) with the game's own size: the arrows walk the 21:9 modes up to 5120x2160 (native), and 16:9 then back keeps the game's own. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…without SDL, not a call through an empty slot The Insert menu asks the host for the main screen's size at startup and while the game runs (MkwVkHost.screen_size, this PR's), which on Linux is hos_sdl_desktop_size. A windowless start (HOS_HEADLESS) loads no SDL, so version is 0 and the function went on to SDL2's branch and called GetDesktopDisplayMode's empty slot: exit 139 before the first frame (reported on NotRexed#2566 by mooki000, Arch, Hyprland). With no SDL loaded it now says the screen is unknown, and the menu lists the sizes it does without one. Windows takes GetSystemMetrics and was not affected. tests/test_sdl_desktop_size.py cuts the function from hos_sdl.c and runs it against stand-ins: no SDL (unknown, which faulted at address 0 before), SDL3's mode in pixels (1536x864 at a density of 1.25 is 1920x1080), SDL3 with no mode, and SDL2's mode as given or failed. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…them, rounded and with 21:9's common sizes The 5120x2160 case filled the list with six sizes directly. NotRexed#2566's retest on that screen walked eight: 3008x1264 (its 3012x1271 mode rounded down to 8) and 3840x1600 (21:9's common size) as well. The case now takes the screen's modes through display_modes.h offered and with_common, as the list does, and walks the same eight sizes the retest saw. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… shows At a shape the host widens 16:9 sizes to, the game's own choice shows what the game draws (2728x1152 at a 5120x2160 screen's 21:9) but was walked at its stored 2048x1152, so it came before 2560x1080 and the first Right went down a size (NotRexed#2566's retest). step_output_choice now orders a shape's choices by picture_for, the size each row shows, and the game's own is in the walk of the shape it is drawn at, reached from either side: 2560x1080, 2728x1152 (game's), 3008x1264, ... At 32:9 a kept 1920x1080 (drawn 3840x1080) and the game's own (4096x1152) come before 5120x1440 the same way. What is saved is the choice, as before (output_res=0 for the game's own); handheld draws nothing wider and keeps the old order. test_output_resolution walks the 21:9 screen's nine choices up and back down, and the 32:9 one; test_menu_setting_walk's stand-ins gain picture_for (each choice's own size there). Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ea30380 to
d550ea5
Compare
|
Linux re-test of the fixed head, as promised above. Hardware: RTX 4090 24 GB, NVIDIA 615.78.08, i9-13900K, Arch Linux 7.2.15-1-omarchy. The Linux windowless startup crash is gone. Nine starts on this head reached the copied Kokiri Forest save without a crash, fatal error, device loss or kernel driver fault. I captured the title, the loaded save and the Graphics rows. The first start logs: That last size is the fixed offscreen extent, not a detected monitor or the chosen output. SDL3 loads later for controller support; there is still no video desktop here. With the screen unknown, Aspect ratio offers 16:9, 32:9 and Monitor's shape. The outputs are:
I selected all six sizes and started a new process at each, checking the output log and same-sized captures. Returning to the starting shape restored the starting size. A menu-selected 1920x1080 survived the next start, with that size in the log and menu and no pending restart notice. The 32:9 start logged Authored mode lists:
The 21:9 start logged An existing custom setting: main Pictures (windowless captures from this PC, labelled):
Evidence limits: neither authored list supplies a monitor's size, so neither produces a Checks: all eight changed/new tests pass with GCC 16.2.1 and Clang 23.1.3. Against main, two stand-in updates pass; six fail: the SDL fixture actually faults without the guard, the section check detects the old layout, and four fixtures stop at the absent new header/extraction anchors. Seven C/C++ fixtures pass Windows-target syntax checking, not Windows execution. No full-suite rerun. One virtual-core escape occurred in the heavily loaded first start; these runs make no performance claim. Not tested: a real window on this head, real ultrawide or other monitor shapes, native marks from a real desktop, multi-monitor/DPI/hotplug changes, fullscreen/window resizing, Windows runtime, handheld mode, or other upscaler/frame-generation combinations. |
|
Follow-up: one run in a real window, for the mark the windowless test could not show. The real-window follow-up also passes on this monitor: Arch Linux, Hyprland/Wayland, RTX 4090 24 GB, NVIDIA 615.78.08, i9-13900K; 1920x1080 at scale 1.25. Same build One process, 118.2 seconds total. The Graphics menu's own state reports 16:9 (monitor's) and 1920x1080 (native). I stepped the 16:9 outputs through 1280x720, 1920x1080, 2048x1152, 2560x1440, 3200x1800, 3840x2160 and 5120x2880, then selected 32:9 / 3840x1080 and returned to the marked 16:9 / 1920x1080 pair. The larger choices were pending settings, not applied during this process; I did not walk every 32:9 size. The window was 1536x864 logical pixels; the source picture, content and swapchain were all 1920x1080. Thus the native mark uses the physical size, not the scaled logical window size. No crash, device loss or driver fault; the window did not take focus. No performance claim. I inspected two 1920x1080 captures made by the game itself. They show the title picture, not the Insert overlay: the marked labels above come from the real menu's state and log, not a desktop screenshot. The first capture has the title over the ranch; the later one has the title over a black background. Still not tested: other physical monitor shapes, multiple monitors, monitor/DPI/resolution changes, moving or resizing the window, fullscreen transitions, or Windows. |
|
Thanks, mooki000, for both Linux runs: windowless on the fixed head, and the real window with the "(monitor's)" and "(native)" marks at 125% scaling. Thanks too, Joey-Magnus, for the merge check and the review. On the two notes for the maintainers:
|
…display modes The Output resolution row offered six fixed sizes, and the Aspect ratio row (NotRexed#2119) only 16:9 or the monitor's shape, so a 21:9, 16:10 or 4:3 size the screen has needed a hand-written output_res. The two rows now list what the screen offers: - Aspect ratio: 16:9, Monitor's shape (the default, its shape named), then the other shapes of the screen's display modes (5:4, 4:3, 16:10, 21:9, 32:9...). It sits right above the Output resolution, whose sizes it chooses. - Output resolution: the sizes of that shape (each side rounded down to 8, those the game accepts), the screen's own marked native, and the game's own 2048x1152 at 16:9. Choosing a shape takes the screen's own size when it has it, else the largest no taller than the screen. - A size more than 1 % off 16:9 sets the picture's shape (cameras, the HUD in the middle 16:9), over HOS_ASPECT and ultrawide=, in host/hos_main.c and the menu alike (hos_output_own_shape); ultrawide= shapes a 16:9 size, as before. - ultrawide= stays 0 or 1 with main's default and its move for older files; another shape is output_res's own. Old saved output numbers still load (kOutputs). Where the modes are not known (Linux), the sizes offered before. HOS_DISPLAY_MODES=<w>x<h>,... stands in for the screen's modes. - The control bridge's option_set output_res still reaches every size: one of another shape moves the Aspect ratio first, as the arrows keep to one shape. gpu/vk/display_modes.h holds the rules as plain code; tests/test_display_modes.py checks them. The menu's tests that cut out the output code follow the new numbering, test_menu_sections has the Aspect ratio above the Output resolution, and test_menu_setting_walk walks to a size of another shape through the Aspect ratio. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ked; common sizes for each The Aspect ratio listed 16:9 and Monitor's shape as two values even where they were the same shape (16:9 and "Monitor's shape (16:9)" on a 16:9 screen). It is now one list of the shapes offered, narrowest first, the one that is the monitor's own marked "(monitor's)": 16:9 on a 1080p screen, 21:9 on a 3440x1440 one, 16:10 on a 1280x800 one. ultrawide= is still saved: 1 for the monitor's own shape, else 0, so main's default, its move for older files and the launcher's setting keep working; where the monitor's shape is not known or not offered (Linux, a portrait screen) it is saved as read. Each shape the screen has also gets the common sizes the screen does not list (display_modes.h common_sizes): 1440p, 4K and 5K at 16:9 on a 1080p screen, 16:10's, 4:3's, 3:2's, 21:9's and 32:9's. The screen's own size is always among the modes, and one past the game's size limit (a 7680x2160 32:9 screen) adds its shape at the most pixels a picture of another shape takes. "(native)" compares the screen's size rounded to 8 as the game takes it (1366x768: 1360x768). Choosing a shape takes the screen's own size when it has it, else the one whose height is nearest the screen's (3:2 on a 1080p screen: 1920x1280, not 720x480). Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…tions (_CRT_SECURE_NO_WARNINGS) CI's windows-2022 runner stopped on getenv and sscanf marked deprecated, an error under -Werror, as the other fixtures that include host/hos_wide_size.h define it. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The command line defines it too: redefined under -Werror. Guarded, so either is enough. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…nown, the bridge to 16:9, HOS_OUTPUT_RES kept out - Where the monitor's shape is not known (Linux: the menu has no screen size) or not offered (a portrait screen), the row has Monitor's shape as a value of its own after the shapes, as on main, and saves ultrawide= from it. Before, ultrawide= was saved as read there, so 16:9 could not be chosen on Linux or the Steam Deck. - The control bridge's option_set output_res to a 16:9 size from the monitor's 21:9 (or any other shape) moves the row to 16:9 first (aspect_for_choice), not back to the monitor's shape, which left the walk inside 21:9 and refused (-2). - A run whose Output resolution HOS_OUTPUT_RES holds saves the player's ultrawide= as read while the row is as it started, not the shape of the environment's size. - A 16:9 size kept from before at the monitor's shape (ultrawide=1) steps into the monitor's own sizes (step_shape), the list the row names, instead of the 16:9 list under the monitor's label. - The shape list is made once per player's size, not at each call; last_output() (custom_index()) and the unused hos_output_is_surround are gone. test_output_resolution checks Monitor's shape as a value, the bridge's way to 16:9 (aspect_for_choice) and the steps of a 16:9 size at the monitor's shape; test_menu_setting_walk checks menu_setting_set calls aspect_for_choice. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…d a resolution changed while playing The Aspect ratio's "(monitor's)" and the Output resolution's "(native)" were the primary monitor's, read once, and Linux had no screen size, so the row there showed Monitor's shape as a value of its own. - The marks, "(native)" and the sizes listed are the monitor the game's window is on (MonitorFromWindow; its own display modes, EnumDisplaySettingsW with its device), the primary's before there is a window. - Followed while playing (every 30 presents): the window moved to another monitor, or the desktop's resolution changed, that screen's sizes not offered yet join the Output resolution's choices after the player's own, so the choices' numbers keep their sizes; the Aspect ratio row, the run's start value and the restart question's keep their shapes. - ultrawide= is saved against the host's screen (the primary, whose shape host/hos_main.c gives a 16:9 size at the start): 1 for its shape, so the next start draws the shape picked even when the window is on another monitor. The host's screen and its shape are always among the sizes, so a 16:9 size kept at ultrawide=1 shows the shape it is drawn at. - Linux: MkwVkHost.screen_size (MKWVK_API_VERSION 20, main took 19 for the ocarina notes), SDL's primary desktop size, as the host shapes the picture from; with it the sizes offered before, the screen's own and the common sizes of their shapes. A portrait screen still has Monitor's shape as a value: no shape the game draws is its. test_output_resolution: the window on a 16:9 monitor with a 32:9 primary (marked 16:9, saved for 32:9, a 16:9 size widened to it), and a size found while running (after the player's own, picked and marked native at its screen). Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ape its size, the game's own as drawn From a test on a 5120x2160 primary (NotRexed#2566's comment): - Stepping the Aspect ratio away from the shape the game started with and back took that shape's own pick (5120x2160) and asked to restart, though nothing differed from the start. Back at the start's shape it is now the size the game started with (output_for_aspect, output_started). - The game's own size showed its 16:9 2048x1152 in the 21:9 list, though ultrawide=1 draws it at the host's shape: it now shows that picture (2728x1152 at a 5120x2160 screen's 21:9), as the game draws it. - The sizes log said "no other" where no size of the player's own was read, which read as no common sizes: it now says what the list holds. test_output_resolution: that screen's 21:9 modes, a first start at 21:9 (monitor's) with the game's own size: the arrows walk the 21:9 modes up to 5120x2160 (native), and 16:9 then back keeps the game's own. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…u's 13 languages NotRexed#1864's tables had this branch's earlier texts (the Aspect ratio's help, the Output resolution's "The sharpest on a ... screen" lines), which the rows no longer show. Those seven are gone from each table; the rows' texts now are there: the Aspect ratio's help and its four shapes' lines, the Output resolution's own-size, larger and smaller lines, and "%s (monitor's)". tx_ultrawide prints the mark from that format, so vk_menu_i18n.cpp's match_format translates "21:9 (monitor's)" with the shape kept as it is. Machine-made like the rest of the tables, with each table's own words for the Output resolution, the HUD and the render targets. test_menu_i18n still fails on main's three texts the menu no longer has (the Controls page's gamepad line, the mesh shader line, the button prompts' line); this branch adds none. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…without SDL, not a call through an empty slot The Insert menu asks the host for the main screen's size at startup and while the game runs (MkwVkHost.screen_size, this PR's), which on Linux is hos_sdl_desktop_size. A windowless start (HOS_HEADLESS) loads no SDL, so version is 0 and the function went on to SDL2's branch and called GetDesktopDisplayMode's empty slot: exit 139 before the first frame (reported on NotRexed#2566 by mooki000, Arch, Hyprland). With no SDL loaded it now says the screen is unknown, and the menu lists the sizes it does without one. Windows takes GetSystemMetrics and was not affected. tests/test_sdl_desktop_size.py cuts the function from hos_sdl.c and runs it against stand-ins: no SDL (unknown, which faulted at address 0 before), SDL3's mode in pixels (1536x864 at a density of 1.25 is 1920x1080), SDL3 with no mode, and SDL2's mode as given or failed. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…them, rounded and with 21:9's common sizes The 5120x2160 case filled the list with six sizes directly. NotRexed#2566's retest on that screen walked eight: 3008x1264 (its 3012x1271 mode rounded down to 8) and 3840x1600 (21:9's common size) as well. The case now takes the screen's modes through display_modes.h offered and with_common, as the list does, and walks the same eight sizes the retest saw. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… shows At a shape the host widens 16:9 sizes to, the game's own choice shows what the game draws (2728x1152 at a 5120x2160 screen's 21:9) but was walked at its stored 2048x1152, so it came before 2560x1080 and the first Right went down a size (NotRexed#2566's retest). step_output_choice now orders a shape's choices by picture_for, the size each row shows, and the game's own is in the walk of the shape it is drawn at, reached from either side: 2560x1080, 2728x1152 (game's), 3008x1264, ... At 32:9 a kept 1920x1080 (drawn 3840x1080) and the game's own (4096x1152) come before 5120x1440 the same way. What is saved is the choice, as before (output_res=0 for the game's own); handheld draws nothing wider and keeps the old order. test_output_resolution walks the 21:9 screen's nine choices up and back down, and the 32:9 one; test_menu_setting_walk's stand-ins gain picture_for (each choice's own size there). Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
d550ea5 to
d49f163
Compare
|
Windows, real window: passes. RTX 5080, Windows 11 (NVIDIA 621.24), one 1920x1080 screen. Built from head
A crash in the build's shader step (not reproduced). When this head was built, the build's Not covered: two screens or moving the window to another one, display scaling other than this screen's, a desktop resolution change while running, starting with a new size after a restart (Restart now wasn't pressed), and HDR. |
…rface, not that its version is 19 The check pinned MKWVK_API_VERSION to 19, so any later interface change (this branch's screen_size, version 20) failed it. Skip opening is an option id; what the check means is that it added nothing to MkwVkHost or MkwVkRenderer.
NotRexed#2566 added MkwVkHost.screen_size as API version 20, so this branch's take_bridge_key and shot_window move to version 21: take_bridge_key after screen_size, in rx_backend.c's initializer too. tests/test_opening_skip.py takes main's own fix (no version number in it). docs/tested-configurations.md: both sides' rows kept. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…NotRexed#2566's choices NotRexed#2566 made the Output resolution's choices the screen's resolutions and the common sizes, so a choice's number no longer names a fixed size: Auto's index into the old list (1 for 2560x1440) picked whatever stood there. Auto now chooses a size, the screen's own where the tier carries its pixels (up to the game's 2048x1152 any tier, up to 2560x1600 Balanced, up to 4K's pixels High, past them Ultra), and the menu finds it among its choices; a size it does not offer is the game's own (logged), never the player's custom size. Screens smaller than the game's own (1080p, 1920x1200, a Steam Deck's 1280x800) now get their own size at any tier. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
….3.0 Fewer idle threads spinning (NotRexed#2709), bounded waits for shaders still translating (NotRexed#2586), the first start after a preparation warms the pipeline cache (NotRexed#2865, NotRexed#2869), native float atomics (NotRexed#2306), the 97% squeeze past the allowance (NotRexed#2585), output choices from the screen's modes (NotRexed#2566), FSR 4 twice as fast on RDNA 2 (NotRexed#2798), the import cap (NotRexed#2839) and the final NotRexed#2825 (mirror trims settle). Kept: the fork's play() returning the game for Steam's wait (now through start_scoped's process), the handheld texture caps, the RDNA2 detection. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C7fdTPXbwDRohew9qanvbp
…e ownership, Deck preparation and segment heap Port the six display/menu and builder extras missing from this fork, adapted to its sections, HDR, bug report, gamepad/ocarina, keyboard and saved options: - Aspect ratio and Output resolution from the screen's display modes (NotRexed#2566): display_modes.h, the host's screen_size (API 20), HOS_DISPLAY_MODES, old numeric output_res values still read, ultrawide= kept 0/1. - Graphics > Detail > Texture detail (NotRexed#2557): Auto/Full/Medium/Low, mapped in vk_texture.cpp; RX_VK_TEX_* still win. - Gameplay > Skip opening (NotRexed#2827): host/hos_main.c hos_oot_opening, the Python and Rust lift patches, option 52, HOS_SKIP_OPENING, off by default. - Update ownership (NotRexed#2926): the game no longer checks for updates; the folder's launcher does. A game started without its launcher logs one line and never waits on the network. builder_args and WinHTTP are gone. - Steam Deck shader preparation (NotRexed#2800): nx2/steamdeck_shaders.py and make_game.py --steamdeck, opt-in and game-free; the renderer's batch/portable-cache hooks prepare against the Deck driver. - Segment heap (NotRexed#2895): prepare_workers.h, prepare_cpus, and heapType SegmentHeap in both manifests. Game-free tests compile the display-mode rules, texture-detail mapping, skip-opening host function, update ownership, prepare flags and no-game-data checks, and the segment-heap worker count. cargo test --workspace passes.
A player on a 21:9, 16:10 or 4:3 screen can only get a size of that shape by writing
output_res=by hand: the Output resolution row offers six fixed sizes, and the Aspect ratio row (#2119) only 16:9 or the monitor's shape. This fills both rows from the screen's own display modes.What changed
Aspect ratio (the same row, saved as
ultrawide=as before) is now one list of shapes, narrowest first: every shape the screen's modes have (5:4, 4:3, 3:2, 16:10, 16:9, 21:9, 32:9, ...). There's no separate Monitor's shape value any more. Instead, the shape that matches the monitor is marked, e.g. "16:9 (monitor's)" on a 1080p screen, "21:9 (monitor's)" on a 3440x1440 one, "16:10 (monitor's)" on a Steam Deck-shaped 1280x800. It's still the default. An unusual shape shows as its ratio (1600x1024 is 25:16). The row moves from Screen to the top of Resolution and upscaling, right above the Output resolution whose sizes it now picks.Output resolution lists the sizes of the chosen shape:
EnumDisplaySettingsW) and its own size, every size once, each side rounded down to 8, only thosehos_output_size_validaccepts;display_modes.hcommon_sizes). A 1080p screen gets 1440p and 4K without DSR. A shape the screen has none of gets none;The screen's own size is marked "(native)", rounded the same way, so 1366x768 screens see "1360x768 (native)". Picking a shape takes the screen's own size if it has that shape, else the one whose height is nearest the screen's: 21:9 on a 1080p screen is 2560x1080, and 3:2 there is 1920x1280, not 720x480. Larger sizes stay a choice rather than the default. Hints say whether a size is the screen's own, larger (drawn bigger, then scaled down) or smaller.
A screen too big for the game's size limit (e.g. a 7680x2160 32:9 monitor, past 5120x2880's pixels) still gets its shape, at the most pixels a picture of another shape takes (6256x1760 there). A screen whose shape the game can't draw at all (portrait) gets "Monitor's shape" as a value of its own at the end of the row, as on main, and that value saves
ultrawide=1.Which monitor gets marked: "(monitor's)", "(native)" and the sizes listed come from the monitor the game window is on (
MonitorFromWindow, with that monitor's own modes), or from the primary before the window exists. They also follow it while playing: about every 30 frames the menu checks the window's screen. If the window moved to another monitor or the desktop resolution changed, that screen's new sizes are added after the existing choices, so a choice already made keeps its size, and the Aspect ratio row stays on its shape.A size that isn't 16:9 sets the picture's shape, so the cameras widen or narrow and the HUD stays in the middle 16:9. Before, only a size wider than 32:9 did that, and 2560x1080 with 16:9 was stretched. This uses the same rule in
host/hos_main.cand the menu (hos_output_own_shape, 1% off 16:9). It takes precedence overHOS_ASPECTandultrawide=, which now only shape a 16:9 size.Saved options:
ultrawide=stays 0 or 1, with main's default and feat(menu): the Aspect ratio row (was Ultrawide), at the monitor's shape by default #2119's rule for older files. It's checked against the host's screen, the primary, whose shapehost/hos_main.cgives a 16:9 size at startup: 1 when that shape is picked, else 0. So the next start draws the shape picked, even when the window is on another monitor. The host's screen and its shape are always in the list. Any other shape comes fromoutput_res's own size, so nothing new is saved. The launcher's own 16:9 / Monitor's shape setting (recomplauncher.json) writes the same key and still works. The old saved numbers (output_res=1to5) still load (kOutputs, whichnx2/pipeline_share.pymirrors).Linux: a new host call,
MkwVkHost.screen_size(MKWVK_API_VERSION20; main took 19 for the ocarina notes, feat: add separate button mappings for the ocarina notes #1930), gives the menu SDL's primary desktop size, the same one the host shapes the picture from. With it, Linux offers the sizes it offered before, plus the screen's own size and the common sizes of their shapes, and marks the monitor's shape like Windows. With no screen size at all, the old fixed sizes are listed. That includes a windowless start (HOS_HEADLESS), which loads no SDL:hos_sdl_desktop_sizenow returns "screen unknown" there, where it used to call an empty SDL2 slot (found by mooki000,tests/test_sdl_desktop_size.py).HOS_DISPLAY_MODES=<w>x<h>,...stands in for the screen's modes (with the common sizes of their shapes added), for testing a screen you don't have (documented indocs/development.md).Control bridge:
option_set output_resstill reaches every size (fix(menu): option_set walks the list rows in the arrows' order to the value asked for #2496). The arrows stay within one shape, so for a size of another shape it moves the Aspect ratio first, as a player would.Code: the rules live in
gpu/vk/display_modes.has plain code, tested bytests/test_display_modes.py. Tests updated for the new layout and numbering:test_output_resolution,test_menu_env_overrides,test_menu_setting_walk,test_menu_sections(the row's new section),test_framegen_presetandtest_rumble_menu(stand-ins).Translations (feat: the Insert menu in 13 languages, with Game language and Menu la… #1864): seven of feat: the Insert menu in 13 languages, with Game language and Menu la… #1864's entries were this branch's earlier help texts (the old Aspect ratio help and the "The sharpest on a … screen" lines), which the rows no longer show. They're removed from each of the 13 tables, and the rows' current texts are added: the Aspect ratio's help and its four shape lines, the Output resolution's own-size, larger and smaller lines, and
"%s (monitor's)".tx_ultrawideprints the mark from that format, somatch_formattranslates "21:9 (monitor's)" and keeps the shape as written. Like the rest of feat: the Insert menu in 13 languages, with Game language and Menu la… #1864's tables, these are machine-made and use each table's own words for Output resolution, HUD and render targets. Speakers are welcome to correct them.Tested (Windows 11, RTX 5080, a 1920x1080 primary screen whose modes run from 640x480 to 1920x1080)
tests/run_all.py(llvm-mingw), at a1eb460 + this branch: 406 passed (test_output_resolutioncovers the 21:9 primary of the retest from its own modes, the Aspect ratio's values, the bridge's way to 16:9, a 16:9 size kept at the monitor's shape, a window on a 16:9 monitor beside a 32:9 primary, and sizes found while running), 71 skipped, 15 failed. Main alone fails the same 15 on this PC (404 passed; this branch addstest_display_modesandtest_sdl_desktop_size). Among them,test_menu_i18nfails on three texts main's menu no longer has,test_framegen_presetandtest_rumble_menuon an undeclaredtemporal_reset_failurein their stand-ins. This branch adds no failures.HOS_LANGUAGE=de, headless): "16:9 (des Monitors)" and the Aspect ratio's help in German. "1920x1080 (native)" stays English, as on main: the size's label is printed with a%s, which the tables don't match.RX_VK_SHOT_W/H) so they're the raw frame. Each size rendered at exactly that size, with the cameras at its shape (boot: widescreen: picture …, camera ratio …) and nothing stretched:HOS_DISPLAY_MODESstanding in for an ultrawide's list: 2560x1080 and 3440x1440 (21:9, 2.3704 and 2.3889, HUD in the middle 75%), 5120x1440 (32:9, 3.5556, HUD in the middle 50%).RX_VK_MENU_SCRIPT,RX_VK_SHOT_MENU): Aspect ratio stepped through every shape on this screen (5:4 → 1280x1024, 4:3 → 1440x1080, 3:2 → 1920x1280, 25:16 → 1600x1024, 16:10 → 1680x1048, 5:3 → 1280x768, 16:9 (monitor's) → 1920x1080 (native)) and on the simulated ultrawide list (21:9 → 2560x1080, 32:9 → 3840x1080). The Output resolution followed each one with the expected size. Arrows stop at the ends, a shape with a single size shows no arrows, and "Restart needed: Aspect ratio, Output resolution" appears.Needs testing (help wanted: I have one 16:9 screen)
HOS_DISPLAY_MODES. Also an older options file withultrawide=1and a 16:9output_resthere: the row should read "21:9 (monitor's)" (or the screen's shape), the picture should be at the monitor's shape, and saving should keepultrawide=1.ultrawide=is saved against the primary (see above). Fullscreen (F11) goes borderless on whichever monitor the window is on.vk: the window's screen is …: N sizes added, and the marks move); changing which monitor is primary between runs; mixed DPI scaling.rx_present_fx), never stretched.output_res=does).output_res=1to5, a hand-written size of a shape the screen doesn't list,ultrawide=0from before options version 6 on a 16:10 screen (feat(menu): the Aspect ratio row (was Ultrawide), at the monitor's shape by default #2119's rule), andHOS_ASPECT/HOS_OUTPUT_RESruns (fix(menu): the Aspect ratio's move for older files skips runs with HOS_ASPECT #2541).vk: the window's screen is 2560x1440 …, and the new sizes should appear in the Output resolution while your current choice stays. Not tested here.Screenshots
From the headless runs above (Windows 11, RTX 5080, 1920x1080 primary screen): Upscaler Off at 100%, no window scaling filter, Sharpness 0, each shot at the picture's own size.
The Graphics tab on this screen: the Aspect ratio at the monitor's own shape, marked "(monitor's)", with the Output resolution at the screen's own size.
3:2, a shape this screen has only at 720x480. The Output resolution moved to 1920x1280, one of 3:2's common sizes, the one nearest the screen's height. Both rows are marked for the restart.
With
HOS_DISPLAY_MODESstanding in for an ultrawide's list, at a 3440x1440 output: 32:9, with the Output resolution stepped to 5120x1440.The same spot at all seven sizes, scaled to one height: 16:9, 4:3, 16:10, 5:4, both 21:9 sizes and 32:9. Wider shapes see more at the sides with the HUD in the middle 16:9. Narrower ones keep the height and spread the HUD across their width. Nothing is stretched.
Full size, 21:9 at 3440x1440 (
boot: widescreen: picture 3440x1440, scene 2584x1080, camera ratio 2.3889, HUD and movies in the middle 74.4%):Full size, 4:3 at 1440x1080 (
picture 1440x1080, scene 1080x810, camera ratio 1.3333, HUD and movies in the middle 100.0%):🤖 Generated with Claude Code