feat(menu): the Aspect ratio row (was Ultrawide), at the monitor's shape by default #2119
No reviewers
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot!2119
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/aspect-monitor-default"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A player on an ultrawide, 16:10 or 4:3 screen starts with the game's 16:9 picture until they find the Graphics tab's Ultrawide row, change it and restart. The name also hides that the same row shapes the picture on screens narrower than 16:9. PC games usually follow the monitor's shape from the first start, with 16:9 as a choice.
What changed
gpu/vk/vk_menu.h;host/hos_main.creads an options file with noultrawide=line as Monitor's shape). 16:9 stays a choice. On a 16:9 screen nothing changes.ultrawide=(ini_key), so a savedultrawide=0still means 16:9.ultrawide=0, the old default, whether chosen or not. On a screen narrower than 16:9 (16:10 such as the Steam Deck's1280x800, or 4:3), where 16:9 only adds bars above and below, that file's 16:9 moves to Monitor's shape; an ultrawide keeps
its 16:9 (often a real choice there). The rule is one function,
hos_aspect_oninhost/hos_wide_size.h:host/hos_main.cstarts the game with it, and the menu's row follows what the host started with (
host->aspect_ratio(), inmenu_initbefore
restart_init), so the two agree on Linux too, where the menu has no screen size of its own.save()writesoptions_version=6, so a 16:9 chosen after the update stays. Not in this PR: skipping the move in runs withHOS_ASPECTset (Joey's point)came after the merge and follows in its own PR.
recomplauncher.json: the same label and help, and its default is1, so the launcher does not write 16:9 over the new default.menu_restart.hand the comments that named the row follow (#2052's wording kept, with the new name).test_menu_restart.pyandtest_menu_restart.cppuse the new name;test_audio_output_menu.pyandtest_stick_dead_zone.pygive their option stubs theultrawidefield thatini_keynow reads. Newtest_aspect_default.py:hos_aspect_onover 16:10, 4:3, 5:4, 16:9, 1366x768, 21:9, 32:9, portrait and no screen size, plus the host and menu source checks.For the release notes (this changes a default for everyone, and only a 21:9 PC ran it):
Tested
tests/run_all.pyon Windows (llvm-mingw) after merging main at06c30bdc(with #2197): 392 passed, 31 skipped, 1 failed:test_vram_budget_row, which fails the same way on main's own sources on this PC (clang stops on the unusedkVramMinimumOnly).hos_main.c,vk_menu.cpp) before that merge; the merge itself only adds the version 6 move next to #2197's. The move for older files was not run in game: this PC has a 21:9 screen, where an older 16:9 stays. The tests this PR touches pass, and so do the others that buildini_keyor the row:test_framegen_preset,test_menu_env_on,test_recomplauncher_json,test_rumble_menu,test_upscaler_rows,test_vsync_row,test_output_resolution,test_widescreen_shapes.Not tested
test_widescreen_shapes.pycovers their sizes).Screenshots
From a headless run of this branch (head
2a74ec4d) on Windows 11, RTX 5090, with a 5120x2160 (21:9) monitor and no options file, so a first start (HOS_HEADLESS=1,RX_VK_SHOTSat 2560x1080; the save loaded withHOS_INPUT_SCRIPTpresses). The log:widescreen: picture 3416x1440, scene 2560x1080, camera ratio 2.3722.The menu shot is the middle 16:9 of the frame: behind it the title movie stays 16:9 with black sides. Its build had one extra line so the list scrolls headless (
ease_step = 1.0finmenu_record_image), not part of this PR.The widescreen cap PR (#2120) edited the same readme paragraph; it has merged, and the paragraph is merged with it here.
options_version: #2197 (merged) took 5 for the Esc default, so this writes 6 and moves an older file's 16:9 from filesbefore 6 (
version < 6inhos_aspect_onandmenu_init). #2110 also writes 5 today; whichever of the two lands latertakes the next number. #2197's
test_menu_keys.pycompilesmenu_init's options read, which now also readshost->aspect_ratio, so itshoststub gains that member. Its check of older files expected every version below the onesave()writes to move Insert or F1 to Insert, F1 or Esc, which would move a version 5 file's chosen Insert or F1 again; itnow reads the move's version from
menu_initand checks that files from it up tosave()'s version keep their choice.🤖 Generated with Claude Code
This is a good change, and it's well-contained. The host and the menu share one rule (
hos_aspect_on), so they can't disagree. The saved key staysultrawide=, so existing files keep working. The migration only moves the old default where 16:9 can only add bars.host->aspect_ratiowas already inMkwVkHost, so no API bump is needed. On Linux,GetSystemMetricsgets SDL's screen size, whichdisplay_sdl.csets beforegame_main, so the host side works there too. The merge with main is clean. The one red CI job (Windows part 2/2) istests/test_native_astc_texture_count.py, which fails the same way on other PRs today and isn't related.should fix: screenshots. The Graphics tab's row is renamed and the default picture changes shape on non-16:9 screens. CONTRIBUTING asks for screenshots when a change shows on screen. A shot of the renamed row, and the first-start picture on the 21:9 screen you tested, would cover it.
minor
gpu/vk/vk_menu.cpp:2959-2962(at the PR's head):menu_initinfers "the host started this older file at the monitor's shape" fromhost->aspect_ratio()alone. That value is also set whenHOS_ASPECTis given (host/hos_main.cuses it instead of the file). With an older file holdingultrawide=0, running once with, say,HOS_ASPECT=1.6flips the row to Monitor's shape, and the nextsave()writesultrawide=1withoptions_version=5. That stores a choice the player never made. It's rare (a debugging switch), but an easy fix is to skip the move whengetenv("HOS_ASPECT")is set, which is whathos_main.cchecks.minor: as you note, #2197 and #2110 also claim
options_version=5. Whichever lands second has to bump the number and itsversion < Nchecks (here inhos_aspect_onandmenu_init). It might be worth a line in thesave()comment so the next person sees all three migrations. Steam Deck players with an existing options file will see the picture change to 16:10 after this update without choosing it. That is the intent, but it should go in the changelog/release notes, since the Deck wasn't run.hos_aspect_on). It's only tested on one 21:9 machine, so it belongs in the release notes.HOS_ASPECTpoint is still open: the migration atvk_menu.cpp:3121trustshost->aspect_ratio()even whenHOS_ASPECTset it, so a debug run can saveultrawide=1withoptions_version=5.options_version=5is also used by #2197 and #2110, and this PR conflicts with #2177 over the Ultrawide row. Suggested order: #2197, then #2177, then this rebased.Looks good to me. The default flips to the monitor's shape, the saved key stays
ultrawide=, and the older-file move is one function (hos_aspect_on) that the host and the menu both follow, so they can't disagree. I read the diff and the tests:test_aspect_default.pycovers the shapes (16:10, 4:3, 5:4, 1366x768, ultrawides, portrait, no screen size),test_menu_keys.pynow reads the old-shortcut version frommenu_initso the version 6 bump doesn't move a chosen Insert/F1 again, and theultrawidestubs in the other two tests match whatini_keynow reads.save()writes 6, so a 16:9 chosen after the update stays. All CI jobs are green on this head.Since Joey-Magnus's earlier reviews: the screenshots he asked for are in the description now (both links load), and the merge with main is clean. Still open, both small and neither a blocker:
HOS_ASPECTpoint (vk_menu.cpp, theversion < 6block inmenu_init) is not fixed.host->aspect_ratio()is also set byHOS_ASPECTand by a custom output wider than 32:9, so a run with one of those on an olderultrawide=0file on a 16:10 screen can saveultrawide=1the player did not pick. It's a debug switch and a rare setup, so fine to follow up, but skipping the move whengetenv("HOS_ASPECT")is set would close it.options_version=6and the ordering with #2110 and #2177 are covered in the description; whichever lands later takes the next number. Because the default changes for everyone (Steam Deck and 16:10 players included, untested on a real 16:10 screen), it belongs in the release notes.The decision to merge is yours (and NotRexed's, as maintainer); nothing here objects.
Thanks for the reviews and the merge. The
HOS_ASPECTguard landed on the branch right after the merge, so it is its own PR now: #2541.menu_initskips the move whenHOS_ASPECTis set, ashos_main.cdoes, andtest_aspect_default.pypins it.The description now has the screenshots (the renamed row, and a first start on the 21:9 monitor) and a suggested release-notes line for the default change, Steam Deck and 16:10 included.
github-sync referenced this pull request2026-11-12 06:22:54 +00:00