Repository navigation
fix(menu): the Ultrawide row says Off (16:9) when it is off - #2078
Merged
Merged
Conversation
hckrman101
approved these changes
Nov 11, 2026
hckrman101
left a comment
hckrman101
left a comment
Collaborator
There was a problem hiding this comment.
Small and correct: the off value of the Ultrawide row now reads "Off (16:9)", the "Monitor's shape" text is untouched (so the #1864 translations still match), and the readme row and default follow. I found no test that matches the old "16:9" string, and no other place that builds this label.
CI: the two Windows Python source jobs fail, but the source-regressions run on main has been failing too, so I don't blame this label change; ubuntu is still pending. As the description says, not seen in game; one look at the Graphics tab with the row off would be enough.
pmwork-personal
added a commit
to pmwork-personal/Hookshot-pr
that referenced
this pull request
Nov 11, 2026
Brings in NotRexed#2052 (48:9), NotRexed#2078 (the off value's label) and NotRexed#2041 (the V-Sync row). Conflicts resolved with upstream's text kept and the row's new name on top: - vk_menu.cpp picture_for and hos_main.c's widescreen comment: NotRexed#2052's wording, "Ultrawide" read as the Aspect ratio. - tx_ultrawide: 16:9 again instead of NotRexed#2078's "Off (16:9)". NotRexed#2078 added "Off" because "Ultrawide: 16:9" read as already on; under the name Aspect ratio the value is a shape, and "Aspect ratio: Off (16:9)" would not read well. - readme: the settings table and NotRexed#2052's Output resolution notes, with the row's new name. - test_audio_output_menu.py, test_stick_dead_zone.py: the option stubs take both NotRexed#2041's vsync and the ultrawide key. Also follows the rename where the first commit missed it: recomplauncher.json (label, help, and its default now 1, so the launcher does not write 16:9 over the new default) and tests/test_menu_restart.cpp's sample row names. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
hckrman101
added a commit
that referenced
this pull request
Nov 11, 2026
…ape by default (#2119) 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** - The **Ultrawide** row is now **Aspect ratio**, and **Monitor's shape** is its default (`gpu/vk/vk_menu.h`; `host/hos_main.c` reads an options file with no `ultrawide=` line as Monitor's shape). 16:9 stays a choice. On a 16:9 screen nothing changes. - The saved key stays `ultrawide=` (`ini_key`), so a saved `ultrawide=0` still means 16:9. - **Older options files on a screen narrower than 16:9.** The game saves every row, so a file from before this PR holds `ultrawide=0`, the old default, whether chosen or not. On a screen narrower than 16:9 (16:10 such as the Steam Deck's 1280x800, 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_on` in `host/hos_wide_size.h`: `host/hos_main.c` starts the game with it, and the menu's row follows what the host started with (`host->aspect_ratio()`, in `menu_init` before `restart_init`), so the two agree on Linux too, where the menu has no screen size of its own. `save()` writes `options_version=6`, so a 16:9 chosen after the update stays. - The other value reads **16:9** again instead of #2078's "Off (16:9)". #2078 added "Off" because "Ultrawide: 16:9" read as if ultrawide were already on; under the name Aspect ratio the value is a shape, and "Aspect ratio: Off (16:9)" would not read well. Happy to keep "Off (16:9)" if you prefer it. - `recomplauncher.json`: the same label and help, and its default is `1`, so the launcher does not write 16:9 over the new default. - New help text for the row, and for **Ultrawide menus**, whose text named the old row. The readme's settings table and Output resolution notes, `menu_restart.h` and the comments that named the row follow (#2052's wording kept, with the new name). - Tests: `test_menu_restart.py` and `test_menu_restart.cpp` use the new name; `test_audio_output_menu.py` and `test_stick_dead_zone.py` give their option stubs the `ultrawide` field that `ini_key` now reads. New `test_aspect_default.py`: `hos_aspect_on` over 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. **Tested** - In game on Windows 11, RTX 5090 (driver 621.14), 5120x2160 (21:9) monitor, in one build with the widescreen cap change from #2120: the picture takes the monitor's shape, and Kokiri Forest and Castle Town load. That run was before the merge with current main (#2052, #2041, #2078). This PR only moves a default and renames a row; the code that sizes the picture is unchanged. - `tests/run_all.py` on Windows (llvm-mingw) after merging main at 06c30bd (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 unused `kVramMinimumOnly`). - A build of this branch compiled (`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 build `ini_key` or 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** - 16:10, 4:3, 32:9 and 48:9 screens in game (`test_widescreen_shapes.py` covers their sizes). - Linux and the Steam Deck: SDL gives the screen's size there too, so a Steam Deck (16:10) now starts with a 16:10 picture instead of 16:9. - If #1864's translations name the row, they would need the new name. **Screenshots** From a headless run of this branch (head 2a74ec4) on Windows 11, RTX 5090, with a 5120x2160 (21:9) monitor and no options file, so a first start (`HOS_HEADLESS=1`, `RX_VK_SHOTS` at 2560x1080; the save loaded with `HOS_INPUT_SCRIPT` presses). 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.0f` in `menu_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 files before 6 (`version < 6` in `hos_aspect_on` and `menu_init`). #2110 also writes 5 today; whichever of the two lands later takes the next number. #2197's `test_menu_keys.py` compiles `menu_init`'s options read, which now also reads `host->aspect_ratio`, so its `host` stub gains that member. Its check of older files expected every version below the one `save()` writes to move Insert or F1 to Insert, F1 or Esc, which would move a version 5 file's chosen Insert or F1 again; it now reads the move's version from `menu_init` and checks that files from it up to `save()`'s version keep their choice. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: hckrman101 <239247847+hckrman101@users.noreply.github.com>
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
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.
With Ultrawide off, the Graphics tab showed "Ultrawide: 16:9". On a 3440x1440 monitor that read as if ultrawide were already on, so the game stayed at a 16:9 2560x1440 with bars at the sides, and 100% render resolution stayed well below the screen's width. The off value now reads "Off (16:9)". "Monitor's shape" is unchanged, so the translations in #1864 still match it. The readme's settings table follows.
Testing:
tests/test_menu_restart.py,tests/test_output_resolution.pyandtests/test_widescreen_shapes.pypass on Linux. It is a label change only; I have not seen it in the game yet.