feat(ui): the HUD laid out for every screen shape at its 16:9 size, anchored to the screen's edges #95
No reviewers
Labels
No labels
area/accessibility
area/audio
area/input
area/install
area/menu
area/renderer
area/saves
area/upscaling
good first issue
gpu/amd
gpu/igpu
gpu/intel
gpu/nvidia
help wanted
kind
bug
kind
chore
kind
docs
kind
feature
kind
performance
kind
question
needs measurements
platform/linux
platform/steam-deck
platform/windows
preview
priority
critical
priority
high
priority
low
status
blocked
status
confirmed
status
duplicate
status
invalid
status
needs-info
status
wontfix
testing wanted
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Longshot!95
Loading…
Reference in a new issue
No description provided.
Delete branch "llun/Longshot:feat/hud-layout"
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?
Why
On a screen that isn't 16:9, the HUD looks wrong today. Narrower shapes (5:4, 4:3, 3:2, 16:10) stretch the HUD and menus taller, and wider ones (21:9, 32:9, 48:9) leave the HUD in the middle 16:9, far from the corners. With this change the HUD keeps its 16:9 size on every shape the Aspect ratio row offers, and its parts sit at the screen's edges and corners, as if the game had been made for that shape. 16:9 doesn't change.
What changed
host/hos_wide_ui.c): built on ozwaldorf's pane planner from https://github.com/NotRexed/Hookshot/pull/2843 ("Extended" ultrawide menus, still open there; credited in the commit). The planner sees each 2D pane as the game places it (f_8154cab0) and moves the ones at a side of the 16:9 canvas out to the screen's side. This PR changes these things about it:HUD_LAYOUTS:PlayerStatus_00,Location_00,MapMenu_00for the minimap,Talk_00,MessageLog_01for the text box's button guide, and the world-placed ones, which stay unmoved).MapMenu_00layout as a root of its own, at the same pane address. While its icons' group is at the canvas's origin (RULE_KEEP_ORIGIN), the root getsas_menu: it isn't walked or moved, and on a narrower screen it's fitted to the width like the other menus. The map page's own rules (RULE_KEEP_TAB) went with that.MessageDialog_00, a new layout kind,LK_HELD): drawn at the HUD's size likeTalk_00's box, where the game puts them, never moved and never fitted. Fitted as a menu, they came out at another scale than the box on a narrower screen.P_Fade_00) is drawn wider when its layout is in the middle 16:9 (the centred Ultrawide menus modes) and taller when it is at the HUD's size (narrower than 3:2), inhos_wide_ui_size. Its icon keeps its shape and place in the middle 16:9. This is mooki's proposal from #57 for https://github.com/NotRexed/Hookshot/issues/2220 (Longshot #82).ui_ex< 0). Up and down (visit_y,PANE_Y) is new: when the HUD has to be drawn smaller, the top and bottom panes move out to the screen's top and bottom.hos_wide_ui_tick):HUD_MAX; covers every 21:9 screen up to 3840x1600). On a 32:9 screen that keeps the hearts and the minimap near the middle. At 48:9 (three screens) the HUD stays on the middle screen, as before.HUD_FULL). Below that it shrinks by the ratio over 3:2 (4:3: 89%, 5:4: 83%) so it doesn't take too much of the width, and its top and bottom move out.nx2/oot_wide.py,HUD): one across and up scale (hos_ui_qx,hos_ui_qy) for every 2D screen not kept whole. The old site only scaled across, and only on wider screens. The pane sites come from https://github.com/NotRexed/Hookshot/pull/2843.host/rx_backend.c): on a narrower screen the menus' screen is never kept whole (stretched), whatever the Ultrawide menus row says; that row is about wider screens.tests/test_hud_layout.pyis new. It checks the plan at each shape (16:9, 21:9, 3440x1440, 32:9, 48:9, 16:10, 3:2, 4:3, back to 16:9), the menus' fit, the loading fade at 21:9 and 4:3 and its own screen at the projection site (KEEP_VTABLES[3]), the map page (a menu's, then the minimap again), and the text box's choices and guide.tests/test_wide_ui.pychecks the planner from https://github.com/NotRexed/Hookshot/pull/2843 on the HUD's layouts, and that a menu notes only its root. Each check added in the review round fails without its change.docs/development.md, and there's a row indocs/tested-configurations.md.Flags and settings
HOS_WIDE_UI=0HOS_WIDE_UI_LOG=<n>HOS_HUD_MAX_RATIO=<ratio>0: the screen's edges at any widthHOS_HUD_FULL_RATIO=<ratio>Measurements
main:
82de567a(2026-11-12): the Longshot-Main game folder. Nothing merged since, up to514591a3, changes the HUD, the menus' screens, the loading fade ornx2/oot_wide.py.this PR: feat/hud-layout @ 9c5a39c1 for the frame times (before the simplification and the review round; neither runs in a frame outside the plan, whose time is in its own table). The review round, now
7cedec2d, was measured as 5487b3f1, the same code (the squash added only a docs row and a switch's wording), against607a186c, the head before it.Hardware: RTX 5080 16 GB, NVIDIA 621.24, Ryzen 9 9900X3D, 64 GB DDR5, Windows 11 Pro (26300)
Scene: Kokiri Forest at the debug teleport's arrival, standing; output 3440x1440 (21:9) and 1440x1080 (4:3) through
HOS_OUTPUT_RES; the options' DLSS row; headless, no sound,HOS_NO_PACING=1 HOS_REALTIME_STEP=0Method: 1,800 presents standing after the teleport, frame intervals from
RX_VK_FRAME_LOG, median per run. 4 runs per shape, interleaved main, PR, main, PR. The table gives the median of the two runs (each run's own in brackets). The plan's own time comes fromHOS_WIDE_UI_LOG's line, the last 3 of each run.How to reproduce:
longshot_ctl.py launch <folder> --headless --env HOS_OUTPUT_RES=3440x1440 --env HOS_NO_PACING=1 --env HOS_WIDE_UI_LOG=1 --env RX_VK_FRAME_LOG=frames.csv, then Continue,teleport KokiriForest_Child,wait present --frames 300, then 1,800 presents.82de567ahos_wide_squeeze0)Before the plan walked only the used slots, it took 0.68 to 0.78 ms a present, and the PR's frame medians were about 0.5 ms above main's at both shapes. That is why the bitmap is in this PR.
The plan with a menu open (review round): one run each at 2560x1080 and 1440x1080, of
607a186cand then of this head. Each run walks out of Kokiri Forest, then holds 1,300 presents in play, with the map open (View) and with the pause menu open. The figures are theHOS_WIDE_UI_LOGlines that fall wholly inside each stretch (2 to 3 of them).607a186c, 21:9607a186c, 4:3tonesi measured 0.47 to 0.56 ms with the pause menu open on
607a186c(i7-12700K). Before the review round the plan built the tree for every pane it saw, the menus' included; now it sees only the HUD's.The loading fade (the same runs, a shot every 2 presents through the fade after walking out to Hyrule Field). Brightness is the mean, 0 to 255, outside the middle 16:9 ("bands": the sides at 21:9, above and below at 4:3) and inside it, at the shots where the middle is black:
82de567a607a186cAs the fade lifts, the bands and the middle come back together (this PR's first lit shot: 21:9 bands 3.6, middle 29.7; 4:3 bands 19.1, middle 24.6).
Testing
Tested: In the game on an RTX 5080, Windows 11, headless, through the control bridge, from a Longshot-Main save: Continue, the debug teleport to Kokiri Forest, play, the pause menu's Items page, and its System page (the controls sheet). I ran that at 5:4 1280x1024, 4:3 1440x1080, 3:2 1920x1280, 16:10 1920x1200, 16:9 1920x1080 and 2560x1440, 21:9 2560x1080 and 3440x1440, 12:5 3840x1600, 32:9 5120x1440 and 48:9 5760x1080, with main @
82de567aat every shape and the PR at every shape, plus 32:9 and 48:9 withHOS_HUD_MAX_RATIO=0. The title screen and the file select ran at every shape too, on the way in, but I didn't look at them separately.The review round (5487b3f1, the code of
7cedec2d, against607a186cand main82de567a, at 2560x1080 and 1440x1080): the loading fade as it lifts after walking from Kokiri Forest to Hyrule Field (numbers and pictures above), the map (View button) at both shapes, and the plan's time in play, with the map open and with the pause menu open. The log shows the map is the minimap's ownMapMenu_00root, at the same pane address, going from the HUD's to a menu's while it shows and back after. At 21:9 the map is in the middle as on main; at 4:3 it is fitted to the width (main stretches it to the full height). All runs were headless, the RTX 5080's renderer line in each log, and the saves were restored and compared after each.python -I -B tests/run_all.pyon 5487b3f1 (main514591a3): 490 passed, 6 failed, 39 skipped. All 6 also fail on main514591a3on this PC: test_bake_portability, test_check_third_party, test_finish_output, test_lift_cache, test_menu_i18n, test_release.tests/test_hud_layout.pyfails on main (there is nohost/hos_wide_ui.c) and passes here. There is no CI on Forgejo, so these checks were run locally.Not tested:
MessageDialog_00held andMessageLog_01at the edge are checked game-free only. I've asked dukenheimer to check them with his Saria save.HUD_LAYOUTSare treated as menus: centred and fitted, never stretched, but not anchored.607a186cwith clang on Linux (no warnings inhos_wide_ui.cwith-Wall -Wextra); the review round adds plain C only. T-QSAV asks for AMD or Intel.Needs other testers:
607a186cat 5120x2160 (comment 13721); this round fixes his findings 1 and 2.HOS_OUTPUT_RES, expecting the same pictures (T-QSAV). tonesi ran607a186con Linux with an RTX 3070 Ti: pass (comment 13030)Screenshots
Each picture shows main @
82de567aon top and this PR @ 9c5a39c1 below it: play in Kokiri Forest, then the pause menu's Items page. They are the game's own screenshots, taken headless.82de567a(top) and this PR @ 9c5a39c1 (bottom)The review round (7cedec2d's code), the same pictures as in comment 15003. The loading fade is shown during the load, before it lifts:
607a186c(top) and this PR (bottom)For maintainers to decide, 32:9 and 48:9: the HUD stopping at 12:5's sides (this PR) or reaching the screen edges (
HOS_HUD_MAX_RATIO=0):Risk and rollback
A HUD layout this PR doesn't name, or a menu that is really a HUD element, would sit centred instead of at the edges. That is the old place, but on a narrower screen it is now drawn smaller to fit. A pane the planner misjudges could land at the wrong edge;
HOS_WIDE_UI_LOGshows each move.HOS_WIDE_UI=0puts the HUD back in the middle (narrower: fitted), and reverting the commit restores today's behaviour. At 16:9 nothing runs.Reviewer notes
hos_wide_ui_tick(the rules per shape) andvisit_y; the rest ofhos_wide_ui.cis the planner from https://github.com/NotRexed/Hookshot/pull/2843, cut down to the HUD.HOS_HUD_MAX_RATIO=0).wide_cover(the renderer closes the sides while the loading cover shows) for the same fade. The two are compatible, but they conflict in theHUDsite's text innx2/oot_wide.py, and whichever lands second has to merge it.Issues
See #64
Checklist
For everyone
type(scope): description).main(514591a3).python -I -B tests/run_all.pyrun and passing (any failure that also fails onmainis named above).third_party/untouched (a new folder with aPROVENANCE.mdinstead).If applicable
607a186cbuilt clean by tonesi (clang,-Wall -Wextraonhos_wide_ui.c); the review round changes plain C inhos_wide_ui.conly and is not yet built on Linux (T-QSAV). No paths are touched.Assisted-by:/Co-Authored-By:trailers.docs/tested-configurations.mdfor each measured run.mainand passing here.tests/that reads changed source updated in this PR, not weakened.🤖 Generated with Claude Code
WIP: feat(ui): the HUD laid out for every screen shape at its 16:9 size, anchored to the screen's edgesto feat(ui): the HUD laid out for every screen shape at its 16:9 size, anchored to the screen's edgesCan we simplify code?
c7c93f1e137a9aca22a57a9aca22a54ad0feadaeThanks, done in 4ad0fead (rebased on main
2a2da67f). Since the menus aren't moved here, I dropped everything from https://github.com/NotRexed/Hookshot/pull/2843 that only the menus needed: the pause menu's page strips, its background drawn in pieces, the lists widened as they're built, the menus' name rules and the HOS_WIDE_UI=1 menus mode, plus three of the six hook sites in nx2/oot_wide.py. host/hos_wide_ui.c went from 916 to 648 lines and tests/test_wide_ui.py from 394 to 262; the diff is 506 lines shorter in all. The class arrays became single HUD values too. Shot again in game at 4:3, 21:9 and 32:9 on the simplified build (RTX 5080): the same pictures as before, and the plan still takes 0.10-0.11 ms a present. tests/run_all.py gives 485 passed, and its 6 failures also fail on main here. If you'd like something else trimmed, point me at it.4ad0feadae489dd39db8489dd39d changes only text: the commit message and the source comments now point to Hookshot's pull request as a full URL, https://github.com/NotRexed/Hookshot/pull/2843, instead of a bare number that links to the wrong place here. Code and behaviour are unchanged; tests/run_all.py gives 486 passed, and its 6 failures also fail on main on this PC.
489dd39db8607a186c44Rebased onto main
b9cdc432(#105, CI workflows and CONTRIBUTING only; no conflict). Head607a186c. Fulltests/run_all.pyon Windows: 486 passed, 6 failed, the same six that fail on main itself on this PC (bake_portability, finish_output, lift_cache, check_third_party, setup_runtime, release).Thanks for bringing the HUD layout work over. Reading
c7c93f1e, the default loading fade still takes the centred path:wide_sides()keepskMenus = 0xa, removing loading bit 3 from the full-width mask in the centred modes, whileLoadingFade_00is outside the HUD layouts and menu panes are not widened by default. The new fade assertion usesKEEP_VTABLES[2], the event fade, not the loading fade.Issue 82 is that loading-fade report. Once this is merged, I will reduce pull request 57 to widening only the fade pane, leaving its icon centred; you are welcome to fold that into this pull request instead. This is a source reading only: I have not built or run this head.
Thanks, @mooki: you're right.
wide_sides()takes the loading bit out of the full-width mask whileLoadingFade_00has no rule of its own, and the test's fade check readsKEEP_VTABLES[2], the event fade, so it never covered the loading one.I'll fold the fade-pane widening into this PR (fade pane full width, its icon centred, as you describe for #57), with a check on the loading fade's own vtable, rebase onto main
341d63a4, run the full suite and check the loading fade in game at 21:9 and 4:3 before pushing. That should let #57 close or shrink further; I'll say here when it's up.Linux test (NVIDIA; not T-QSAV, which asks for AMD or Intel): pass
Hardware: RTX 3070 Ti 8 GB, NVIDIA 595.104.02, Pop!_OS 24.04 (Linux 7.2), i7-12700K. Built
607a186c(the PR head) with clang from the Linux toolchain, against main91a1ae8b. The three commits from91a1ae8bto the PR's baseb9cdc432change only CI, forge scripts and docs, nothing inhost/,gpu/ornx2/.What I checked:
widescreen: 17 of 17 sites; main has 11). The build compiles host code with-Wno-everything, so I also compiledhost/hos_wide_ui.candhost/rx_backend.cwith the same flags plus-Wall -Wextra.hos_wide_ui.cgives no warnings.rx_backend.cgives the same 6-Wmissing-field-initializersthat main's gives, none of them in this PR's lines.tests/test_hud_layout.pyandtests/test_wide_ui.pypass with gcc 13.3 and with clang 23.1.5. The fulltests/run_all.pygives 499 passed, 0 failed, 33 skipped. Every skip is a Windows-only check or a tool missing here (spirv-val, glslang, dav1d, a Vulkan device for the checks).HOS_OUTPUT_RES3440x1440, 1440x1080 and 1920x1080, withHOS_WIDE_UI_LOG=1on the PR's runs.Result:
91a1ae8b607a186cThe "Kokiri Forest" place-name card follows the HUD too: at 21:9 it moves to the left edge, and at 4:3 it is no longer squeezed.
The
wide uilines from the PR's runs:wide uilines.Not checked: Windows, AMD, Intel, a window or a real monitor of these shapes (headless only), the loading fade from mooki's comment, text boxes, the map page, other HUDs, other shapes,
HOS_WIDE_UI=0, and timing.3440x1440, play: main, then this PR
3440x1440, pause menu: main, then this PR
1440x1080, play: main, then this PR
1440x1080, pause menu: main, then this PR
Tested on a real ultrawide: 5120x2160 (RTX 5090, Windows 11)
Build: feat/hud-layout @
607a186c, tested as is (the head still conflicts with main). Built for Windows withnx2/make_game.pyand shaders prepared, using llvm-mingw 20261104 and the Hookshot Builder's cpm / wgpu-native / third_party / work. The build took 23 min.Hardware:
Method:
RX_VK_SHOT_W/H).Talk_00), the pause menu.ultrawide=1), Output resolution 5120x2160.HOS_WIDE_UI=0(the old layout).output_res): 32:9 5120x1440, 16:10 2560x1600, 4:3 1920x1440. 16:9 1920x1080 ran with Aspect ratio 16:9.HOS_WIDE_UI_LOG=1in every run, plus one run withHOS_WIDE_UI_LOG=20000for the pane list.The screenshots are attached in pairs: this PR on top,
HOS_WIDE_UI=0below.1-gameplay-location)HOS_WIDE_UI=0both sit at the middle 16:9's corners. Nothing is clipped, off-screen or overlapping, and the scale is right (the same size in both)Location_00)N_SmallDisplay_00left −640)Talk_00/MessageDialog_00,2-dialogue-Talk)DoCommand_00, "A Talk" with X/Y/B)3-pause-menu)4-loading-fade)607a186c5-shape-5120x1440)HOS_WIDE_UI=0's middle 16:95-shape-2560x1600)5-shape-1920x1440)5-shape-1920x1080)HOS_WIDE_UI_LOG=1)vi:lines). This is a reference reading, not a measurementVK_ERRORor validation lines in 15 runsFinding 1: the loading fade still leaves the ultrawide sides lit (mooki's report)
4-loading-fade).607a186c, with the PR and withHOS_WIDE_UI=0.LoadingFade_00as a menu's ("over the whole picture" as a root layout), but none of its 11 panes move. Its fade,P_Fade_00, stays at the 16:9 canvas's width, x [−1920 1920] with width ×1.000. The loading icon (N_LoadIcon_00, x 1778) also stays at the 16:9 bottom-right, not the screen's.Finding 2: the dialogue's button guide stays at the 16:9 edge
MessageLog_01, classed as "a menu's":A_GuideAll_00at x 1840,Pa_HideGuide_00at x 1193.5 andPa_Guide_00at x 1795, all rule 0, stays.MessageDialog_00's own choice buttons (N_BtnNum_00x 1460 andN_BtnIn_00–04x ~1520–1532) are also unmoved.HUD_LAYOUTS(MessageLog_01at least), or have a rule for those panes.Not tested
Screenshots (each: this PR on top,
HOS_WIDE_UI=0below)Code review of
607a186c(code only: I didn't build it or run it).The planner and the per-shape math look right. At 16:9,
hos_wide_ratioandhos_wide_squeezeare 0, so the projection site is skipped andui_onstays 0. The only thing that happens is the boot-time forced remake for 3 presents, and it gives the same transforms, so 16:9 is the game's own. The numbers for 21:9 to 48:9 and for 16:10 to 5:4 match the tests and dukenheimer's logs (660, 672, -192, -300/135). The game gets no mouse or touch input (display.c,nn_hid.c), so no hit-testing has to follow the moved panes. ozwaldorf's credit is in the file header, the commit message and a Co-Authored-By trailer.Before this can merge:
607a186cat 5120x2160. llun said the fix would be folded in here, and nothing has been pushed since. The fade check intests/test_hud_layout.pystill readsKEEP_VTABLES[2].kMenus = 0xa), soUILoadingFadeScreengoes through the projection site. On main a narrower screen gives_q = hos_wide_squeeze = 1, a no-op. Here it getshos_ui_qy = k: 0.889 at 4:3 and 0.833 at 5:4, orr / (16/9)at any narrower shape withHOS_WIDE_UI=0. Being inFULL_LAYOUTSonly stops the menu fit, not the projection scale. So the fade stops short of the top and bottom (inline onrx_backend.c).docs/tested-configurations.md(both add rows at the top of the table), and it is 50 commits behind. The "Rebased on current main" box is ticked, but that's not true now.Questions, each needing a run at a narrower shape:
Talk_00is drawn at the HUD's size.MessageDialog_00andMessageLog_01are classed as menus (dukenheimer's log) and fitted. On a narrower screen, the text box and its choices and button guide come out at two scales: 100% and 90% at 16:10, 89% and 75% at 4:3. This ties in with dukenheimer's finding 2.MapMenu_00is inHUD_LAYOUTS, andtests/test_wide_ui.pymodels the map page as its own root. If the game does the same, the map page is planned and never fitted, while the rest of the pause menu is fitted. Then its side panes go to the screen's edges with the pause menu's frame still in the middle, and on a narrower screen it is drawn wider than the screen (1.185 of the width at 4:3). The map page is listed as untested.A nit: with the pause menu open, the plan took 0.47 to 0.56 ms a present (tonesi's i7-12700K run), up from 0.10 to 0.15 ms in play. The plan builds the tree, checks
alive()and runsrest_offor every pane it has noted, menus included, though only the HUD's are planned. The Measurements section only gives the in-play figure. Also, the samplewide uiline in the description still ends in "their sides moved 0", which this head no longer prints.@ -0,0 +152,4 @@/* (the HUD's root layouts: the hearts, magic, rupees and buttons; the place's name; the minimap (the pause menu's map page isthe same layout); the text box; and the ones placed from the world, never moved. Kept the size of a picture over thewhole screen: the fades and the system overlay, kept whole by their screens) */static const char *const HUD_LAYOUTS[] = {"PlayerStatus_00", "Location_00", "MapMenu_00", "Talk_00", "PlayerStatus3D_00", "Pointer_00",On a narrower screen,
Talk_00is drawn at the HUD's size (k: 100% at 16:10, 89% at 4:3). dukenheimer's log classesMessageDialog_00andMessageLog_01as menus, so they're fitted (r / (16/9): 90% and 75%). So the text box and its choices and button guide come out at different scales and no longer line up. Could you check a dialogue with choices at 16:10 and 4:3? Adding those two toHUD_LAYOUTSwould probably fix this and dukenheimer's finding 2 together.@ -0,0 +154,4 @@whole screen: the fades and the system overlay, kept whole by their screens) */static const char *const HUD_LAYOUTS[] = {"PlayerStatus_00", "Location_00", "MapMenu_00", "Talk_00", "PlayerStatus3D_00", "Pointer_00","BalloonMessage_00"};static const char *const FULL_LAYOUTS[] = {"LoadingFade_00", "SystemOverlay_00"};LoadingFade_00being inFULL_LAYOUTS("kept whole by their screens") only skips the menu fit. With the default menus row, its screen isn't kept whole, on wider or on narrower screens, so the projection still scales it. This is the fade-pane widening llun said would be folded in here (mooki's comment). dukenheimer still sees it on607a186c.@ -0,0 +168,4 @@/* (MapMenu_00 is also the HUD's minimap: there the icons' group sits over the minimap and moves out with it; kept only atthe canvas's origin, where the map page puts it. While it does, the area title and the world map card stay on the map,which stays 16:9. The icons' part itself is never looked into: its icons move as one with their group) */{"MapMenu_00", "N_MapIcon_00", RULE_KEEP_ORIGIN}, {"MapMenu_00", "Pa_MapIcon_00", RULE_KEEP},These rules only matter if the plan walks
MapMenu_00while it shows the map page.tests/test_wide_ui.pymodels it that way, as a root of its own (place(mroot2, 0, 0)). If the game does the same, the map page is HUD here: its side panes move to the screen's edges while the pause menu's frame stays in the middle 16:9, and on a narrower screen it isn't fitted with the rest of the pause menu (1.185 of the width at 4:3, wider than the screen). The map page is listed as untested. Could you run it at 21:9 and 4:3? If it's as above, aMapMenu_00showing its page (in_tab) could be treated as a menu.@ -0,0 +434,4 @@ext_done[i] = rest_done[i] = ext_ydone[i] = 0;rest[i] = plan_new[i] = plany_new[i] = 0.0f, wide_new[i] = 1.0f;}if (on) {Nit: from here on, every noted pane is linked, checked with
alive()and givenrest_of, menus included, but only the HUD's roots are visited. tonesi measured 0.47 to 0.56 ms a present with the pause menu open, against 0.10 to 0.15 ms in play. Could the menu-open figure go in the Measurements? Skipping panes whose root isn't the HUD's would also help.@ -164,1 +164,4 @@hos_wide_keep_mask = forced ? (uint32_t)strtoul(forced, NULL, 16) : keep_mask;extern volatile float hos_wide_ratio; /* (narrower than 16:9: the menus fit its width whatever the Ultrawide menus row says,never stretched up and down; the row is about wider screens) */if (!forced && hos_wide_ratio > 0.0f && hos_wide_ratio < 16.0f / 9.0f * 0.999f) hos_wide_keep_mask &= ~2u;On a narrower screen this drops only bit 1. With the default Ultrawide menus row, bit 3 (
UILoadingFadeScreen) is already cleared (kMenus = 0xainvk_framegen.cpp), so the loading fade now goes through the projection site withhos_ui_qy = k: 0.889 at 4:3 and 0.833 at 5:4, orr / (16/9)at any narrower shape withHOS_WIDE_UI=0. On main the site multiplies byhos_wide_squeeze, which is 1 on a narrower screen, so the fade covered everything. Now it leaves the scene lit above and below. Keeping bit 3 here as well (hos_wide_keep_mask = (hos_wide_keep_mask & ~2u) | 8u) would put it back the way main has it. The wider case is mooki's point, which is still open.@ -0,0 +211,4 @@build_run(a.cc, FIXTURE_HEAD + body + FIXTURE_MAIN, "plan")head = FIXTURE_HEAD.replace("volatile float hos_wide_squeeze, hos_wide_ratio;", "volatile float hos_wide_squeeze;")site = SITE_MAIN.replace("SITE", oot_wide.HUD).replace("FADES", "0x%xULL" % oot_wide.KEEP_VTABLES[2])Still open from mooki's comment:
KEEP_VTABLES[2]is the event fade. The loading fade isKEEP_VTABLES[3], and withhos_wide_keep_mask = 0x5(the default row) this site would scale it. A check on it, at a narrowerhos_ui_qytoo, would catch both fade issues.607a186c447cedec2d56Review round pushed:
7cedec2d, one commit on main514591a3(credit and trailers kept). The description is updated with the numbers and pictures below.@HumanBean, thanks for the careful read. Point by point:
P_Fade_00) is drawn the whole picture's width when its layout sits in the middle 16:9, and its icon stays where it is. The check now reads the loading fade's own screen,KEEP_VTABLES[3], at 21:9 and at 4:3, and fails without the fix. In game at 2560x1080, during the load main and607a186cleave the sides lit (mean 229 to 230 of 255) while the middle is black. This head has 0 there, and the sides lift with the middle.rx_backend.ccomment): fixed, but not by keeping bit 3. I draw the same pane taller (1 / hos_ui_qy) instead. Kept whole, the fade's 16:9 layout would be squeezed across a 4:3 screen, its icon and text with it, as on main. This way they keep their shape and the fade still covers the full height. In game at 1440x1080,607a186clit the bands above and below at 104 while the middle was black; this head has 0. Main is 0 there too (it keeps the screen whole).514591a3, and thetested-configurations.mdconflict is gone.Your questions:
MapMenu_00layout as a root of its own: the log shows the same pane address going from "HUD" to "menu" and back. While it shows its page, it's now drawn as a menu's (as_menu, counted in the plan's change check). It isn't walked or moved, and on a narrower screen it's fitted to the width. At 4:3 it's fitted with the other menus now (main stretches it), and at 21:9 it's in the middle as on main. The pause menu itself has no map page (Collection, Equipment, Items, System).MessageDialog_00is now a layout of its own kind: held where the game puts it at the HUD's size, the box's own scale, never moved or fitted.MessageLog_01is inHUD_LAYOUTS, so its guide follows the minimap to the edge. Both are checked game-free (each check fails without its change). I couldn't get a text box in game: Navi had nothing to say on any D-pad direction in my route.607a186cthen this head, ms a present: play 0.10 to 0.11 then 0.05 to 0.06; the map open 0.09 to 0.12 then 0.05; the pause menu open 0.13 to 0.19 then 0.05 to 0.06. They're in the Measurements, and the samplewide uiline is fixed.@mooki: your fade-pane widening is folded in, as you proposed in comment 12471, and the check reads
KEEP_VTABLES[3]. #57 can shrink to whatever else it covers.@dukenheimer: thank you for the 5120x2160 run. Finding 1 (the fade) and finding 2 (the "Hide / Conversation Log" guide) should both be fixed on
7cedec2d. The loading icon staying at the middle 16:9's bottom right is by design: only the black pane is widened. Could you re-check a dialogue with your Saria save, at 5120x2160 and at one narrower shape (16:10 or 4:3)? I'd like to see the guide at the screen's edge, and any choices at the same scale as the box.@tonesi: thanks for the Linux run and the pause-menu figure. That's what led to this round's change in what the plan notes.
@TrashPanda: your WIP #287 brings over Hookshot's
wide_coverfor the same loading fade. The two are compatible, but they conflict in the text of theHUDsite innx2/oot_wide.py, so whichever lands second has to merge it.python -I -B tests/run_all.py: 490 passed, 6 failed. The same 6 fail on main514591a3on this PC.Description: the dialogue check is test request T-3E3B (any PC with a save next to someone who asks a question). The new box "Host code builds on both Windows and Linux" stays unticked until
7cedec2dis built on Linux:607a186cwas (tonesi), and this round changes plain C in hos_wide_ui.c only. @tonesi, if you have a moment, a Linux build of7cedec2dwould settle it.Pictures for the review round (
7cedec2d, run as 5487b3f1, the same code), from the runs in the Measurements. All are the game's own shots, headless on the RTX 5080, Ultrawide menus Centred.The loading fade during a load, before it lifts. At 21:9, main's sides stay lit while the middle is black; this PR covers the whole picture. At 4:3, the head before this round (
607a186c) lit thin bands above and below; this PR doesn't. The loading icon keeps its place in the middle 16:9.The map (View button), drawn as a menu while it shows. At 21:9 it's in the middle, as on main. At 4:3 it's fitted to the width, where main stretches it to the full height.
Play and the pause menu after the round. The HUD sits at the screen's edges and the menus are unchanged at 21:9. At 4:3 the HUD is in the corners at 89%, and the pause menu is fitted to the width, where main stretches it.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.