Fill wide screens: option to anchor the HUD to the edges on windows taller than 16:9 (2160x1856 Galaxy Z Fold)

Open
  • Is something wrong?
#528 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
c
Domain
frontend, game-dev

Research direction

Start in runtime/nvn/vulkan/exec.c and read the hud_patch logic that classifies HUD panes from c3[33], along with its scissor_rect and text-matrix handling. Trace how the current Fill wide screens setting determines the 16:9 layout and how pane positions relate to the window shape. Done means a default-off Video > HUD at edges option moves top and bottom HUD panes to their window edges on shapes below 1 while leaving other elements in place; verify it on a tall display.

Written by the indexing model from the issue text.

Description

The idea

An option to anchor the in-game HUD to the window's edges on windows taller than 16:9, instead of keeping it in the centred 16:9 band.

Since #125, Video > Fill wide screens works on taller shapes: the world fills the window vertically (rt_persp tan(fovy/2) / shape) and hud_patch keeps the HUD layers in the 16:9 layout (m11 x shape). That is the right default for 16:10 and 4:3, where the band is nearly the whole window. On much taller shapes the band gets small: I play streamed to a Galaxy Z Fold 6 inner screen at 2160x1856 (shape ≈ 0.655). The 16:9 band is 2160x1215, so the hearts, rune icon, minimap, temperature and stamina gauges sit about 320 px in from the top and bottom edges, with the world drawn above and below them. The pause menu, map, loading and title screens staying 16:9 with bars is fine (they are laid out for it); it is the HUD that reads as "floating in the middle" on a near-square screen.

What I'd like: with Fill wide screens on and shape < 1, HUD layers whose panes sit in the top part of the 16:9 layout move to the window's top edge, those in the bottom part to the bottom edge, and the rest (reticle, dialogue, pick-up banners) stay where they are. Cemu's graphic packs do this for BOTW on ultrawide ("HUD at edges"), and Savage Wind already does the horizontal analogue on 21:9 by not widening the HUD. A toggle (Video > HUD at edges, default off) would keep today's behaviour for everyone else.

Anything else
  • Savage Wind 0.4.1-alpha.4 (commit 428d9ccd), Linux AppImage, game 1.9.0 with DLC 3.0, RX 9070 XT (RADV, Mesa 26.2.6), borderless 2160x1856 @ 119.56 Hz, wide_view = 1, field_of_view = 100. The 16:9 band is visible in the log as [post] 1920x1080 smaa -> 2160x1856.
  • Where it would live, from reading the source: hud_patch (runtime/nvn/vulkan/exec.c) already classifies each HUD draw by the pane rectangle in c3[33] projected through the view (the lo / hi loop), so a per-pane vertical offset (m13 scaled by the pane's view depth) for panes above / below the band's middle could be added there, with the same offset applied in scissor_rect for the minimap mask and in the two text-matrix branches.
  • Not game-breaking, I play around it; it would just make the Fold (and any other squarish or portrait-ish handheld screen) feel native. Happy to test builds on this display and send window shots (SAVAGEWIND_WINDOW_SHOT_AT).
Dominant language
C
Stars
811
Forks
37
Avg merge
17m
Merged PRs (30d)
13

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Revivedx/SavageWindRecomp

All issues in Revivedx/SavageWindRecomp

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.