feat(menu): DLAA as DLSS's Native render resolution, and Render resolution as a slider in real sizes #2000
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!2000
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/graphics-menu"
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?
The Upscaler row lists DLAA (and FSR 4's native AA) as upscalers of their own, though each is just its engine at full size, and
the Render resolution row names DLSS's modes without saying what size the 3D is drawn at — on an ultrawide screen or at an
output other than 16:9 a player cannot tell what they are choosing. This puts Native (DLAA) under DLSS, makes Render resolution
a slider like a PC game's render scale, and labels every step with its real size.
What changed
row's Native step under their engine. Saved values are unchanged (
dlss=2is still DLAA), so no ini changes meaning.the game's own scale. DLSS's modes fall on it (Quality 67 %, Balanced 58 %, Performance 50 %, Ultra Performance 33 %); 92 to
75 % are taken by its Quality mode, whose range is 50–100 %. Not 42 %: no DLSS mode takes it. A value saved between stops snaps
to the nearest stop.
resolution row names the picture the game actually draws: with Ultrawide on, the screen's shape at the output's height (at
most 3840x2160's pixels, as today), and "(native)" when that is the screen's own size (e.g. 3440x1440 at the 1440 output).
host/hos_wide_size.h: the widescreen picture's size in one place, shared byhost/hos_main.c(the same sizes as before)and the menu, so the rows cannot drift from what the game draws.
Testing
fc375e9with this change and the two follow-ups below: a full sweep of the slider with DLSS drawing at every stop (42 % was dropped
after that test: no DLSS mode took 2134x900), and Native (DLAA) in and out from the slider.
tests/run_all.pyon Windows: 322 of 324 pass;test_precompile_compute_guardandtest_recorder_syncfail the same onuntouched main here. New checks:
test_upscaler_rows.cpp(engines, Native in and out, the slider's stops andsnapping),
test_output_resolution.py(real sizes at 1080p, on a 21:9 and a 3440x1440 screen); the menu checks that stub theUpscaler know
step_engineandsnap_render.Not tested: AMD (FSR 4's Native step is the same code path as DLSS's; no AMD card here), Linux (sizes there are shown as the
16:9 outputs: the screen size is read on Windows only), a 16:10 or 4:3 screen in game.
Follow-ups (separate PRs, to keep this one to the menu): Ultrawide on by default (the row named Aspect ratio), and the wide
picture past 3840x2160's pixels — 5120x2160 on a 21:9 screen at the 4K output — with the render-target pool rule it needs.
Screenshots
From our build, which also has the two follow-ups: there the Ultrawide row is named Aspect ratio, and a 21:9 screen at the 4K
output gets the full 5120x2160. With this PR alone the same screen reads Output resolution 4416x1864 and Native (DLAA,
4416x1864) — upstream's 3840x2160-pixel cap — and the row stays Ultrawide. The Upscaler, Render resolution and Output rows'
labels are this PR's.
🤖 Generated with Claude Code