WIP: fix(widescreen): the HUD keeps 16:9 on screens narrower than 16:9 (4:3, 16:10, 5:4) #2015

Draft
NotRexed wants to merge 1 commit from fix/narrow-screen-hud into main
NotRexed commented 2026-11-10 23:41:10 +00:00 (Migrated from github.com)

The one part of mimic-wasm's fork (https://github.com/mimic-wasm/Hookshot) taken in, credited to them in the commit.

Before: with Ultrawide on, a screen wider than 16:9 already squeezed the HUD horizontally into the middle 16:9 (hos_wide_squeeze). A narrower screen (4:3, 16:10, 5:4) gave the HUD the whole width at the full height, so it came out stretched.

Now: hos_wide_vertical_squeeze (the screen ratio over 16:9, and 1.0 on wider screens) scales the HUD's rows vertically on narrower screens (nx2/oot_wide.py's HUD patch). The tests are updated (test_widescreen_shapes.py), and test_widescreen_hud.py is new.

Left out of the fork, on purpose:

  • the readme rows flipped to "Fixed" without fixes;
  • a "Native 3D resolution" row defaulting to on, which costs every player GPU time;
  • a "PS3-style" preset;
  • loader.bat, and a hookshot_env.txt with RX_VK_NOOPT=1.

Draft until it's checked in game in a 4:3 and a 16:10 window: the HUD should be its normal shape, centred, with nothing cut off. Wider screens shouldn't change (their vertical scale is 1.0).

🤖 Generated with Claude Code

The one part of mimic-wasm's fork (https://github.com/mimic-wasm/Hookshot) taken in, credited to them in the commit. **Before:** with Ultrawide on, a screen wider than 16:9 already squeezed the HUD horizontally into the middle 16:9 (`hos_wide_squeeze`). A narrower screen (4:3, 16:10, 5:4) gave the HUD the whole width at the full height, so it came out stretched. **Now:** `hos_wide_vertical_squeeze` (the screen ratio over 16:9, and 1.0 on wider screens) scales the HUD's rows vertically on narrower screens (`nx2/oot_wide.py`'s HUD patch). The tests are updated (`test_widescreen_shapes.py`), and `test_widescreen_hud.py` is new. **Left out of the fork, on purpose:** - the readme rows flipped to "Fixed" without fixes; - a "Native 3D resolution" row defaulting to on, which costs every player GPU time; - a "PS3-style" preset; - `loader.bat`, and a `hookshot_env.txt` with `RX_VK_NOOPT=1`. **Draft until** it's checked in game in a 4:3 and a 16:10 window: the HUD should be its normal shape, centred, with nothing cut off. Wider screens shouldn't change (their vertical scale is 1.0). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
simonwjackson commented 2026-11-11 03:31:48 +00:00 (Migrated from github.com)

Thanks for taking on the narrow-screen HUD stretch. I've been playing with two related ideas on top of v2.0.14 and wanted to check whether either is welcome before sending anything.

1. HUD at the screen edges (opt-in). A Graphics row, HUD position: Centred 16:9 / Screen edges. With Screen edges, the gameplay HUD (hearts and magic, minimap, button guide) docks to the real corners on wide and tall screens; menus, dialogue, fades and movies keep their current placement. It follows live window resizes, and each element keeps its size.

Ultrawide: centred vs screen edges
2448x1848: centred vs screen edges
4:3: centred vs screen edges
The option

2. Vert+ on narrow screens (opt-in). Instead of cropping the sides, a 4:3 or taller window keeps the 16:9 horizontal view and shows more above and below, with the camera's culling angle adjusted to match. Left to right: 16:9, 4:3, 2448x1848.

Vert+: 16:9, 4:3, 2448x1848

Would you want either as a small, separate follow-up once #2015 lands? I'd rebase just the part you want onto main and keep it off by default. Not suggesting either goes into this PR.

Tested on Linux, RX 7900 XT (RADV), in Kokiri Forest at 1920x1080, 2560x1080, 3440x1440, 1600x1200 and 2448x1848. Horse gauge, item wheel and dialogue placement aren't checked yet. Work in progress lives on my fork (korri-v2014-fill, korri-v2014-hud-edges).

Thanks for taking on the narrow-screen HUD stretch. I've been playing with two related ideas on top of v2.0.14 and wanted to check whether either is welcome before sending anything. **1. HUD at the screen edges (opt-in).** A Graphics row, *HUD position: Centred 16:9 / Screen edges*. With *Screen edges*, the gameplay HUD (hearts and magic, minimap, button guide) docks to the real corners on wide and tall screens; menus, dialogue, fades and movies keep their current placement. It follows live window resizes, and each element keeps its size. ![Ultrawide: centred vs screen edges](https://raw.githubusercontent.com/simonwjackson/Hookshot/pr2015-frames/hud-ultrawide.jpg) ![2448x1848: centred vs screen edges](https://raw.githubusercontent.com/simonwjackson/Hookshot/pr2015-frames/hud-tall.jpg) ![4:3: centred vs screen edges](https://raw.githubusercontent.com/simonwjackson/Hookshot/pr2015-frames/hud-4x3.jpg) ![The option](https://raw.githubusercontent.com/simonwjackson/Hookshot/pr2015-frames/option-hud-position.jpg) **2. Vert+ on narrow screens (opt-in).** Instead of cropping the sides, a 4:3 or taller window keeps the 16:9 horizontal view and shows more above and below, with the camera's culling angle adjusted to match. Left to right: 16:9, 4:3, 2448x1848. ![Vert+: 16:9, 4:3, 2448x1848](https://raw.githubusercontent.com/simonwjackson/Hookshot/pr2015-frames/vertplus-16x9-4x3-fold.jpg) Would you want either as a small, separate follow-up once #2015 lands? I'd rebase just the part you want onto main and keep it off by default. Not suggesting either goes into this PR. Tested on Linux, RX 7900 XT (RADV), in Kokiri Forest at 1920x1080, 2560x1080, 3440x1440, 1600x1200 and 2448x1848. Horse gauge, item wheel and dialogue placement aren't checked yet. Work in progress lives on my fork (`korri-v2014-fill`, `korri-v2014-hud-edges`).
Joey-Magnus (Migrated from github.com) reviewed 2026-11-11 21:46:26 +00:00
Joey-Magnus (Migrated from github.com) left a comment

There is one bug in the narrow-screen branch of the HUD patch in nx2/oot_wide.py. The instruction at this patch site (0xad401041) is ldp q1, q4, [x2]. So the projection's x row is q1, and its y row is all of q4, with m11 in lane 1. The new branch copies 16 bytes starting at (uint8_t *)c->vreg[4] + 4. Since vreg is uint64_t[32][2], that scales lanes 1-3 of q4 plus lane 0 of q5, a register this instruction never loaded, and leaves lane 0 of q4 alone. It should scale c->vreg[4] from offset 0, the same way the wide branch scales all of c->vreg[1].

tests/test_widescreen_hud.py writes its y row at the same + 4 offset, so it can't catch this. Putting y at c->vreg[4] and a sentinel value in c->vreg[5] would.

The branch also conflicts with #2120 in host/hos_main.c and tests/test_widescreen_shapes.py. The Windows failure is tests/test_log_batch.py's timing check and doesn't look related.

There is one bug in the narrow-screen branch of the HUD patch in nx2/oot_wide.py. The instruction at this patch site (0xad401041) is `ldp q1, q4, [x2]`. So the projection's x row is q1, and its y row is all of q4, with m11 in lane 1. The new branch copies 16 bytes starting at `(uint8_t *)c->vreg[4] + 4`. Since vreg is `uint64_t[32][2]`, that scales lanes 1-3 of q4 plus lane 0 of q5, a register this instruction never loaded, and leaves lane 0 of q4 alone. It should scale c->vreg[4] from offset 0, the same way the wide branch scales all of c->vreg[1]. tests/test_widescreen_hud.py writes its y row at the same `+ 4` offset, so it can't catch this. Putting y at c->vreg[4] and a sentinel value in c->vreg[5] would. The branch also conflicts with #2120 in host/hos_main.c and tests/test_widescreen_shapes.py. The Windows failure is tests/test_log_batch.py's timing check and doesn't look related.
Commenting is not possible because the repository is archived.
No description provided.