MagicBeanDev/Longshot
MagicBeanDev/Longshot
Watch
54
67
Fork
You've already forked Longshot
 71
Code Issues 124 Pull requests 196 Projects Releases 8 Packages Wiki Activity Actions 442

fix(runtime): a new install draws the game's 2560x1440, not its reduced 2048x1152 #292

Merged
HumanBean merged 3 commits from Amateurwizrd/Longshot:fix/default-output-2560x1440 into main 2026-11-14 01:46:53 +00:00
Conversation 5 Commits 3 Files changed 11 +123 -94
Amateurwizrd commented 2026-11-13 19:50:37 +00:00
Contributor

Why

A new install draws the game at 2048x1152, 80% of the 2560x1440 picture the game itself draws docked. Nobody chose that size: the game was told a reduced graphics scale by accident, and the result was then named "the game's own".

What changed

  • runtime: hos_output_default() in host/hos_wide_size.h now gives 2560x1440 when no Output resolution is chosen, or the main screen's own size where that has fewer pixels (the rule it had, with 2560x1440 in place of 2048x1152). A screen that is not known, or of no size the game takes, gets 2560x1440 too.
  • runtime: output_mode() in host/nn_applet.c takes that size for a new install, so GetCurrentGraphicsScale answers tier 0 by default. Its comments say what the tier is. The log line names the case: oe: output resolution 2560x1440 (none chosen: the game's).
  • menu: menu_init() in gpu/vk/vk_menu.cpp takes the same default, so the host and the menu still agree with no restart.
  • Kept as it was: output_res=2048x1152 (and the old output_res=0) still asks for tier 1 and draws 2048x1152. The menu still offers it, now marked "(reduced)" (was "(game's)", which read as the default), with the hint "The game's own reduced size, 80% of its 2560x1440: lighter on the GPU." in all 13 translations. An options file that already holds an output_res= line is read as before, so existing installs do not change. The handheld profile is untouched.
  • docs: the default in README.md, docs/graphics-and-controls.md and docs/development.md (the output_res row), and that a screen with fewer pixels than 2560x1440 starts at its own shape on purpose (below).
  • launcher: recomplauncher.json's Output resolution default is 2560x1440, as the game's (was 2048x1152).
  • tests: tests/test_output_resolution.py covers the new default (the rule's cases, a new install on the host and the menu side, the handheld profile, and 2048x1152 asked for by HOS_OUTPUT_RES). Its expected menu labels say "(reduced)".

What the tier is, from how the console's library and the game behave (no game code is in this PR): nn::oe::GetCurrentGraphicsScale returns a whole number in w0, not a float. The library asks the system for its graphics scaling parameter, which is 10, 20 or 30, and returns 0, 1 or 2 for it. At start the game calls GetOperationMode, GetPerformanceMode, GetCurrentFocusState and GetCurrentGraphicsScale one after the other and keeps the four answers side by side; it reads the scale again when notification message 300 arrives, and sizes its frame by it: x1, x0.8 or x0.667 of its 2560x1440 display size. Longshot's stand-in set only the float register, so w0 still held the answer of the call before it, GetCurrentFocusState's 1 (in focus), and the game drew 2048x1152. e706b9dd then kept 1 as the default on purpose ("x0.8 as before").

nxnative found the same thing in other Switch 2 games and in this one, and changed its answer to tier 0 in both modes: https://github.com/seedds/nxnative/pull/1304. Its testers measured Ocarina of Time at 2048x1152 with tier 1 and 2560x1440 with tier 0. Its maintainer's caveat applies here too: that the tier is the share of the GPU the system leaves the game is read from the games' code, and which tier a real console reports in which mode has not been measured on hardware.

Flags and settings

Flag What it does Default now Recommendation Helps on Doesn't help on Untested on
output_res (the menu's Output resolution), no line in the options file The size a new install starts with 2560x1440, or the main screen's size where that has fewer pixels (was 2048x1152, or the screen's size below that) On by default: it is the picture the game draws at its full graphics scale Screens of 2560x1440 and more: a sharper picture, and DLSS or FSR start from the game's real 3D size Screens with fewer pixels than 2048x1152 (a Steam Deck, 1080p): no change. Existing installs: no change, their file holds a size Screens between the two sizes (2560x1080, 2256x1504): they now start at their own size and shape, pixel for pixel, instead of 2048x1152 widened or narrowed to the monitor's shape (intended, below); only the unit test ran them. VRAM on 4 to 6 GB cards (Risk)
recomplauncher.json's Output resolution default What RecompLauncher shows (and writes) for a new install 2560x1440 (was 2048x1152) As the game's default RecompLauncher installs, which otherwise kept the old picture - RecompLauncher itself: whether it writes its defaults before the first start was not checked; if it does, a Steam Deck there gets 2560x1440 rather than its own 1280x800 (it got 2048x1152 before)

No new switch. HOS_OUTPUT_RES=2048x1152 or the menu's 2048x1152 gives the old picture.

Measurements

main: fbd42024 (2026-11-13)
this PR: fix/default-output-2560x1440 @ b8542e6b
Hardware: RTX 5070 Ti 16 GB, driver 621.01, Ryzen 7 7800X3D, 32 GB, Windows 11 Pro 26200
Scene: Kokiri Forest (child) and Hyrule Field (child), standing still. No Output resolution chosen on either side, 2560x1440 window on a 3840x2160 screen, Quality preset Custom, Render resolution 75%, the game's own upscaler, Lanczos window filter, frame generation off, no frame rate cap
Method: 60 s per run after 15 s of settling, 3 runs each per scene, alternated (main, this PR, main, this PR, main, this PR). Frame times from PresentMon 2.6's capture of longshot.exe; fps is frames over their time, 1% low the same over the slowest hundredth of the frames. GPU time is the median of the log's vk: GPU time lines over the same minute. The log's own fps over the last 5.0 s lines agree with PresentMon to 0.2 fps. The head adds only the docs/tested-configurations.md rows to the measured commit
How to reproduce: build main and this branch into two game folders that share one set of shader caches (here: a copy of main's folder built again with make_game.py --update). Before each run remove the output_res= line from longshot_options.ini. Start with HOS_WINDOW_SIZE=1707x960 (2560x1440 at 150% scaling), HOS_FPS_MAX=1000, RX_VK_FRAMEGEN=0, HOS_AUDIO=0 and HOS_CONTROL set, load a save standing in the scene, then over the control bridge option_set quality_preset 0 and option_set resolution 2, wait 15 s and measure 60 s

main @ fbd42024 this PR @ b8542e6b Δ
Output resolution of a new install (log) 2048x1152 2560x1440 +56% pixels
3D at Render resolution 75% 1536x864 1920x1080 +56% pixels
Kokiri Forest: fps (runs; median) 81.9 / 82.7 / 79.5; 81.9 82.8 / 81.8 / 82.7; 82.7 +0.8 fps
Kokiri Forest: 1% low fps 52.2 / 66.8 / 64.9; 64.9 63.3 / 49.8 / 64.9; 63.3 -1.6 fps
Kokiri Forest: median frame time 12.11 / 12.05 / 12.48; 12.11 ms 11.99 / 12.11 / 12.04; 12.04 ms -0.07 ms
Kokiri Forest: p99 frame time 13.95 / 14.08 / 14.55; 14.08 ms 14.13 / 14.58 / 14.07; 14.13 ms +0.05 ms
Kokiri Forest: GPU time a frame 6.6 / 6.6 / 6.6 ms 6.9 / 6.9 / 6.9 ms +0.3 ms
Hyrule Field: fps (runs; median) 102.3 / 103.3 / 101.8; 102.3 101.1 / 100.8 / 99.4; 100.8 -1.5 fps
Hyrule Field: 1% low fps 86.7 / 83.8 / 84.3; 84.3 83.2 / 82.3 / 78.9; 82.3 -2.0 fps
Hyrule Field: median frame time 9.76 / 9.61 / 9.85; 9.76 ms 9.84 / 9.85 / 10.06; 9.85 ms +0.09 ms
Hyrule Field: p99 frame time 11.10 / 11.23 / 11.14; 11.14 ms 11.24 / 11.56 / 11.54; 11.54 ms +0.40 ms
Hyrule Field: GPU time a frame 6.1 / 6.2 / 6.1 ms 6.5 / 6.5 / 6.4 ms +0.4 ms
Draws a frame, Kokiri Forest / Hyrule Field about 3410 / 2490 about 3420 / 2430 within 3%
tests/test_output_resolution.py with this PR's cases fails passes

GPU time rises by 0.3 to 0.4 ms a frame in every run. The frame time follows in Hyrule Field (+0.09 ms median, +0.40 ms p99); in Kokiri Forest the difference is smaller than the spread between main's own runs (12.05 to 12.48 ms). The cost on this PC is small because the CPU limits the frame here (GPU time 6 to 7 ms of a 10 to 12 ms frame). A slower GPU pays more for the same 56%.

main moved several times while this was measured. A first round of the same 12 runs (main @ 9f64464b against this change on it, 4b7f5f4a) gave the same picture: Kokiri Forest 11.74 against 11.96 ms, Hyrule Field 9.72 against 9.85 ms, GPU time +0.2 to +0.3 ms. The table above is the second round. The branch has since been rebased onto main 9fccd0fd: the change is c312ae2d there, the same patch as the measured b8542e6b, and the head 1896790e adds the review's follow-up (the 2048x1152 label and hint, recomplauncher.json's default, comments and docs), which changes no size drawn. Not measured again: the commits in between do not touch the Output resolution, both sides get them alike, and what the table measures is the cost of 56% more pixels, which the two rounds put at the same 0.3 to 0.4 ms of GPU time.

main @ fbd42024, a new install (Kokiri Forest, run 2):

[hos host] longshot v3.0.0-rc.3-15-gfbd42024 (source a78515be)
[hos host] oe: output resolution 2048x1152 (the game's)
[hos sead::MainThread] nvn: window crop 0,0 2048x1152
[hos Presentation Thread] vi: 5396 frames presented (82.2 fps over the last 5.0 s, interval 1)
[hos Presentation Thread] vi: 5811 frames presented (82.9 fps over the last 5.0 s, interval 1)
[hos Presentation Thread] vi: 6228 frames presented (83.3 fps over the last 5.0 s, interval 1)
[hos Presentation Thread] vk: GPU time 6.6 ms a frame (the longest submission 2.0 ms); 0.0 textures made a frame

this PR @ b8542e6b, a new install (Kokiri Forest, run 2):

[hos host] longshot v3.0.0-rc.3-16-gb8542e6b (source 07a7f5b6)
[hos host] oe: output resolution 2560x1440 (none chosen: the game's)
[hos host] vk: the Output resolution: none chosen, 2560x1440 (the game's 2560x1440, or the screen's where smaller)
[hos sead::MainThread] nvn: window crop 0,0 2560x1440
[hos Presentation Thread] vi: 5340 frames presented (81.2 fps over the last 5.0 s, interval 1)
[hos Presentation Thread] vi: 5749 frames presented (81.6 fps over the last 5.0 s, interval 1)
[hos Presentation Thread] vi: 6160 frames presented (82.0 fps over the last 5.0 s, interval 1)
[hos Presentation Thread] vk: GPU time 6.9 ms a frame (the longest submission 2.0 ms); 0.0 textures made a frame

this PR @ b8542e6b with output_res=2048x1152 in the options file (the old picture, still there):

[hos host] longshot v3.0.0-rc.3-16-gb8542e6b (source 07a7f5b6)
[hos host] oe: output resolution 2048x1152 (the game's at graphics scale 1)
[hos sead::MainThread] nvn: window crop 0,0 2048x1152

tests/test_output_resolution.py as this PR has it, run on main @ fbd42024 (the temporary folder's path shortened):

FAIL       1.6s  tests/test_output_resolution.py
Assertion failed: is(2560, 1080, 2560, 1080), file ...\rule.cpp, line 15
0 passed, 1 failed, 0 skipped in 2 s (windows, 16 at once)

and on this PR:

pass       3.4s  tests/test_output_resolution.py

Testing

Tested: on Windows 11, RTX 5070 Ti (621.01), Ryzen 7 7800X3D.

  • In the game: the 12 measured runs above, the 12 of the earlier round, plus one run of this PR with output_res=2048x1152. Each side loaded both saves and stood for 75 s. No device lost, no crash, about the same draws a frame on both sides, and the log's sizes are the ones in the table.
  • The previous head, f516654c (on main 514591a3), built and started once with no Output resolution chosen: longshot v3.0.0-rc.3-27-gf516654c, oe: output resolution 2560x1440 (none chosen: the game's), nvn: window crop 0,0 2560x1440, Kokiri Forest at 12.22 ms median over 20 s (81.4 fps). No device lost.
  • python -I -B tests/run_all.py with llvm-mingw 20261104, on the previous head (f516654c on main 514591a3): 493 passed, 7 failed, 33 skipped, and the same counts with the same 7 failures on main @ 514591a3: nx2/test_nup_paths.py, tests/test_check_third_party.py, tests/test_gpu_hang_watch.py, tests/test_menu_i18n.py, tests/test_portable_builder_home.py, tests/test_portable_builder_startup.py, tests/test_release.py. tests/test_menu_i18n.py reads gpu/vk/vk_menu.cpp and fails on both sides over the same text, the "Testing tools: ..." hint in the pt_BR table, which this PR does not touch; none of the other six reads the changed code. On the measured base the counts were 490 / 6 / 33 on both sides (the same list without tests/test_menu_i18n.py). The 33 skips are Linux-only checks and checks that need spirv-val or another tool this PC lacks.
  • Linux, compile only: host/nn_applet.c and gpu/vk/vk_menu.cpp compile to objects for x86_64-linux-gnu with nx2/build.py's Linux flags and tools.lock's sysroot (llvm-mingw's clang as a cross compiler, on Windows). Not linked, not run.

Not tested: the head 1896790e (main 9fccd0fd + this change + the review follow-up): not built, not run in the game and tests/run_all.py not run on it; the 2048x1152 row's new "(reduced)" mark and hint, and their 13 translations, have not been seen in the game. A Linux build and run. AMD and Intel GPUs. A GPU slow enough for the larger picture to cost real frame rate, and what Auto (this PC) does there. A first start with no options file at all (the runs kept the file and removed only its output_res= line). A screen with fewer pixels than 2560x1440: 1080p and the Steam Deck take the same path as before, and the sizes in between (2560x1080, 2256x1504) take a new one that only the unit test ran. DLSS and FSR at the new default (this build has neither). The handheld profile in the game (unchanged code; covered by the unit test).

Needs other testers:

  • Any PC (the author's is fine): build the head 1896790e, run tests/run_all.py, start a new install once, and screenshot the Output resolution row stepped to 2048x1152, expecting 2048x1152 (reduced) and the hint "The game's own reduced size, 80% of its 2560x1440: lighter on the GPU." A screen of 2560x1080 or 2256x1504, if anyone has one: a new install should log (none chosen: the screen's, smaller than the game's 2560x1440) and the menu show that size "(native)". (request to open)
  • Linux, any GPU (a Steam Deck or a 1080p screen is welcome too): build this branch and start a new install (no output_res= line). On a screen of 2560x1440 or more, expecting oe: output resolution 2560x1440 (none chosen: the game's) and nvn: window crop 0,0 2560x1440 in the log; on a smaller screen, expecting the screen's own size with (none chosen: the screen's, smaller than the game's 2560x1440). Either way the menu's Output resolution shows that size with no restart question, and Kokiri Forest loads and plays (T-A2R9)

Screenshots

Kokiri Forest, the same save and spot, a new install's Output resolution on both, the FPS counter at Breakdown, the game's window alone (2560x1440). Taken in runs of their own, not in the measured ones.

main @ fbd42024 this PR @ b8542e6b
The Insert menu: Output resolution and Render resolution 2048x1152 (game's), 75% (1536x864) 2560x1440, 75% (1920x1080)
The window in play a 2048x1152 picture scaled up to the window 2560x1440, pixel for pixel

The four pictures are in the first comment on this pull request: main_menu.png, pr_menu.png, main_window.png, pr_window.png. Since then the 2048x1152 choice reads 2048x1152 (reduced) (was 2048x1152 (game's), as in main_menu.png); no screenshot of that yet.

Risk and rollback

A new install on a screen of 2560x1440 or more draws 56% more pixels than before (the 3D goes from 1536x864 to 1920x1080 at the game's own 75%). On a slow GPU that costs frame rate; Auto (this PC), the first start's preset, lowers the Render resolution when frames are missed. Screens between 2048x1152 and 2560x1440 in pixels (2560x1080, 2256x1504) now start at their own size and shape, a path only the unit test covered here. That is intended: it is the rule main already had for screens below 2048x1152 (a Steam Deck's 1280x800, 1920x1200 start at their own size and shape), it draws pixel for pixel, and the shape is the monitor's, which the Aspect ratio row's default gave the old 2048x1152 too (widened to 2728x1152 on 21:9, narrowed to 1728x1152 on 3:2); choosing 16:9 on the Aspect ratio row still takes a 16:9 size. To get the old picture: choose 2048x1152 in the menu, or set output_res=2048x1152. Reverting the commit restores the old default.

VRAM on 4 to 6 GB cards was not measured (only a 16 GB card here). An estimate from the render-target sizes: the game's render targets follow the output's pixels, and the pool it ships for them is 305 MB at 2560x1440; Longshot reserves 512 MB for both sizes (hos_rt_pool_size's floor), so the reservation does not change, and what the targets use in it grows by at most about 110 MB (305 MB x (1 - 0.64)), plus about 10 to 30 MB for Longshot's own output-sized images. What DLSS or FSR keep at the output's size grows too, by an amount not estimated here. Minimum (4GB) and Low (6GB) chosen on the row use the handheld profile (1536x864) and do not change; Auto (this PC), the first start's preset, keeps the docked profile at its tier's Render resolution (50% on Minimum, 75% on Low), so a 4 to 6 GB card on a 1440p or larger screen does take the new size. The VRAM budget rows are unchanged.

Reviewer notes

  • Existing installs keep 2048x1152, because the menu saved that size at their first start and a saved default cannot be told from a choice. Moving them (an options_version step) is left out on purpose: it would also move players who chose 2048x1152.
  • recomplauncher.json's default is now 2560x1440, so the two defaults do not drift. A launcher default is one size on every screen: if RecompLauncher writes it before the first start, a Steam Deck there draws 2560x1440 (it drew 2048x1152 before, also larger than its screen).
  • The menu's mark on 2048x1152 is now "(reduced)", and its hint "The game's own reduced size, 80% of its 2560x1440: lighter on the GPU.": "(game's)" read as the game's preferred size, and the default, once that is 2560x1440. The 13 translations are replaced one for one (machine-made like the rest of the tables), so each table's count in kLangs stays. The bug report's line (pipeline_share.h output_text, "the game's own") is left as it is.
  • The handheld profile still gets tier 1 (1536x864). nxnative answers tier 0 in both modes; that is a separate change with its own measurements.
  • HOS_GRAPHICS_SCALE still sets only the float the game does not read.

Issues

None filed for this.

Checklist

For everyone

  • One topic.
  • The title is a Conventional Commit (type(scope): description).
  • Rebased on current main.
  • python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above). Not run on the head 1896790e: the author's run was on f516654c; CI's run or a local one on this head is needed.
  • Tested in the game, or what wasn't is named under Testing.
  • Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests).
  • Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported.
  • No game files, dumps, build output or generated files.
  • third_party/ untouched (a new folder with a PROVENANCE.md instead).
  • The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

If applicable

  • AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
  • Flags noted, and the switch reference updated (docs/development.md, the README).
  • Screenshots for a change that shows on screen. The new default is shown; the 2048x1152 row's new "(reduced)" mark is not: it needs a run of this head.
  • A row in docs/tested-configurations.md for each measured run.
  • A game-free test added for the fix, failing on main and passing here. Added, failing on main and passing at f516654c; not run on 1896790e.
  • A check under tests/ that reads changed source updated in this PR, not weakened.
  • Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. Built at f516654c (Windows; Linux compile only); the head 1896790e is not built yet.
  • Docs updated.
## Why A new install draws the game at 2048x1152, 80% of the 2560x1440 picture the game itself draws docked. Nobody chose that size: the game was told a reduced graphics scale by accident, and the result was then named "the game's own". ## What changed - runtime: `hos_output_default()` in `host/hos_wide_size.h` now gives 2560x1440 when no Output resolution is chosen, or the main screen's own size where that has fewer pixels (the rule it had, with 2560x1440 in place of 2048x1152). A screen that is not known, or of no size the game takes, gets 2560x1440 too. - runtime: `output_mode()` in `host/nn_applet.c` takes that size for a new install, so `GetCurrentGraphicsScale` answers tier 0 by default. Its comments say what the tier is. The log line names the case: `oe: output resolution 2560x1440 (none chosen: the game's)`. - menu: `menu_init()` in `gpu/vk/vk_menu.cpp` takes the same default, so the host and the menu still agree with no restart. - Kept as it was: `output_res=2048x1152` (and the old `output_res=0`) still asks for tier 1 and draws 2048x1152. The menu still offers it, now marked "(reduced)" (was "(game's)", which read as the default), with the hint "The game's own reduced size, 80% of its 2560x1440: lighter on the GPU." in all 13 translations. An options file that already holds an `output_res=` line is read as before, so existing installs do not change. The handheld profile is untouched. - docs: the default in `README.md`, `docs/graphics-and-controls.md` and `docs/development.md` (the `output_res` row), and that a screen with fewer pixels than 2560x1440 starts at its own shape on purpose (below). - launcher: `recomplauncher.json`'s Output resolution default is 2560x1440, as the game's (was 2048x1152). - tests: `tests/test_output_resolution.py` covers the new default (the rule's cases, a new install on the host and the menu side, the handheld profile, and 2048x1152 asked for by `HOS_OUTPUT_RES`). Its expected menu labels say "(reduced)". What the tier is, from how the console's library and the game behave (no game code is in this PR): `nn::oe::GetCurrentGraphicsScale` returns a whole number in `w0`, not a float. The library asks the system for its graphics scaling parameter, which is 10, 20 or 30, and returns 0, 1 or 2 for it. At start the game calls `GetOperationMode`, `GetPerformanceMode`, `GetCurrentFocusState` and `GetCurrentGraphicsScale` one after the other and keeps the four answers side by side; it reads the scale again when notification message 300 arrives, and sizes its frame by it: x1, x0.8 or x0.667 of its 2560x1440 display size. Longshot's stand-in set only the float register, so `w0` still held the answer of the call before it, `GetCurrentFocusState`'s 1 (in focus), and the game drew 2048x1152. e706b9dd then kept 1 as the default on purpose ("x0.8 as before"). nxnative found the same thing in other Switch 2 games and in this one, and changed its answer to tier 0 in both modes: https://github.com/seedds/nxnative/pull/1304. Its testers measured Ocarina of Time at 2048x1152 with tier 1 and 2560x1440 with tier 0. Its maintainer's caveat applies here too: that the tier is the share of the GPU the system leaves the game is read from the games' code, and which tier a real console reports in which mode has not been measured on hardware. ## Flags and settings | Flag | What it does | Default now | Recommendation | Helps on | Doesn't help on | Untested on | |---|---|---|---|---|---|---| | `output_res` (the menu's Output resolution), no line in the options file | The size a new install starts with | 2560x1440, or the main screen's size where that has fewer pixels (was 2048x1152, or the screen's size below that) | On by default: it is the picture the game draws at its full graphics scale | Screens of 2560x1440 and more: a sharper picture, and DLSS or FSR start from the game's real 3D size | Screens with fewer pixels than 2048x1152 (a Steam Deck, 1080p): no change. Existing installs: no change, their file holds a size | Screens between the two sizes (2560x1080, 2256x1504): they now start at their own size and shape, pixel for pixel, instead of 2048x1152 widened or narrowed to the monitor's shape (intended, below); only the unit test ran them. VRAM on 4 to 6 GB cards (Risk) | | `recomplauncher.json`'s Output resolution default | What RecompLauncher shows (and writes) for a new install | 2560x1440 (was 2048x1152) | As the game's default | RecompLauncher installs, which otherwise kept the old picture | - | RecompLauncher itself: whether it writes its defaults before the first start was not checked; if it does, a Steam Deck there gets 2560x1440 rather than its own 1280x800 (it got 2048x1152 before) | No new switch. `HOS_OUTPUT_RES=2048x1152` or the menu's 2048x1152 gives the old picture. ## Measurements main: fbd42024 (2026-11-13) this PR: fix/default-output-2560x1440 @ b8542e6b Hardware: RTX 5070 Ti 16 GB, driver 621.01, Ryzen 7 7800X3D, 32 GB, Windows 11 Pro 26200 Scene: Kokiri Forest (child) and Hyrule Field (child), standing still. No Output resolution chosen on either side, 2560x1440 window on a 3840x2160 screen, Quality preset Custom, Render resolution 75%, the game's own upscaler, Lanczos window filter, frame generation off, no frame rate cap Method: 60 s per run after 15 s of settling, 3 runs each per scene, alternated (main, this PR, main, this PR, main, this PR). Frame times from PresentMon 2.6's capture of `longshot.exe`; fps is frames over their time, 1% low the same over the slowest hundredth of the frames. GPU time is the median of the log's `vk: GPU time` lines over the same minute. The log's own `fps over the last 5.0 s` lines agree with PresentMon to 0.2 fps. The head adds only the `docs/tested-configurations.md` rows to the measured commit How to reproduce: build `main` and this branch into two game folders that share one set of shader caches (here: a copy of main's folder built again with `make_game.py --update`). Before each run remove the `output_res=` line from `longshot_options.ini`. Start with `HOS_WINDOW_SIZE=1707x960` (2560x1440 at 150% scaling), `HOS_FPS_MAX=1000`, `RX_VK_FRAMEGEN=0`, `HOS_AUDIO=0` and `HOS_CONTROL` set, load a save standing in the scene, then over the control bridge `option_set quality_preset 0` and `option_set resolution 2`, wait 15 s and measure 60 s | | main @ fbd42024 | this PR @ b8542e6b | Δ | |---|---|---|---| | Output resolution of a new install (log) | 2048x1152 | 2560x1440 | +56% pixels | | 3D at Render resolution 75% | 1536x864 | 1920x1080 | +56% pixels | | Kokiri Forest: fps (runs; median) | 81.9 / 82.7 / 79.5; 81.9 | 82.8 / 81.8 / 82.7; 82.7 | +0.8 fps | | Kokiri Forest: 1% low fps | 52.2 / 66.8 / 64.9; 64.9 | 63.3 / 49.8 / 64.9; 63.3 | -1.6 fps | | Kokiri Forest: median frame time | 12.11 / 12.05 / 12.48; 12.11 ms | 11.99 / 12.11 / 12.04; 12.04 ms | -0.07 ms | | Kokiri Forest: p99 frame time | 13.95 / 14.08 / 14.55; 14.08 ms | 14.13 / 14.58 / 14.07; 14.13 ms | +0.05 ms | | Kokiri Forest: GPU time a frame | 6.6 / 6.6 / 6.6 ms | 6.9 / 6.9 / 6.9 ms | +0.3 ms | | Hyrule Field: fps (runs; median) | 102.3 / 103.3 / 101.8; 102.3 | 101.1 / 100.8 / 99.4; 100.8 | -1.5 fps | | Hyrule Field: 1% low fps | 86.7 / 83.8 / 84.3; 84.3 | 83.2 / 82.3 / 78.9; 82.3 | -2.0 fps | | Hyrule Field: median frame time | 9.76 / 9.61 / 9.85; 9.76 ms | 9.84 / 9.85 / 10.06; 9.85 ms | +0.09 ms | | Hyrule Field: p99 frame time | 11.10 / 11.23 / 11.14; 11.14 ms | 11.24 / 11.56 / 11.54; 11.54 ms | +0.40 ms | | Hyrule Field: GPU time a frame | 6.1 / 6.2 / 6.1 ms | 6.5 / 6.5 / 6.4 ms | +0.4 ms | | Draws a frame, Kokiri Forest / Hyrule Field | about 3410 / 2490 | about 3420 / 2430 | within 3% | | `tests/test_output_resolution.py` with this PR's cases | fails | passes | | GPU time rises by 0.3 to 0.4 ms a frame in every run. The frame time follows in Hyrule Field (+0.09 ms median, +0.40 ms p99); in Kokiri Forest the difference is smaller than the spread between main's own runs (12.05 to 12.48 ms). The cost on this PC is small because the CPU limits the frame here (GPU time 6 to 7 ms of a 10 to 12 ms frame). A slower GPU pays more for the same 56%. main moved several times while this was measured. A first round of the same 12 runs (main @ 9f64464b against this change on it, 4b7f5f4a) gave the same picture: Kokiri Forest 11.74 against 11.96 ms, Hyrule Field 9.72 against 9.85 ms, GPU time +0.2 to +0.3 ms. The table above is the second round. The branch has since been rebased onto main 9fccd0fd: the change is c312ae2d there, the same patch as the measured b8542e6b, and the head 1896790e adds the review's follow-up (the 2048x1152 label and hint, `recomplauncher.json`'s default, comments and docs), which changes no size drawn. Not measured again: the commits in between do not touch the Output resolution, both sides get them alike, and what the table measures is the cost of 56% more pixels, which the two rounds put at the same 0.3 to 0.4 ms of GPU time. main @ fbd42024, a new install (Kokiri Forest, run 2): ``` [hos host] longshot v3.0.0-rc.3-15-gfbd42024 (source a78515be) [hos host] oe: output resolution 2048x1152 (the game's) [hos sead::MainThread] nvn: window crop 0,0 2048x1152 [hos Presentation Thread] vi: 5396 frames presented (82.2 fps over the last 5.0 s, interval 1) [hos Presentation Thread] vi: 5811 frames presented (82.9 fps over the last 5.0 s, interval 1) [hos Presentation Thread] vi: 6228 frames presented (83.3 fps over the last 5.0 s, interval 1) [hos Presentation Thread] vk: GPU time 6.6 ms a frame (the longest submission 2.0 ms); 0.0 textures made a frame ``` this PR @ b8542e6b, a new install (Kokiri Forest, run 2): ``` [hos host] longshot v3.0.0-rc.3-16-gb8542e6b (source 07a7f5b6) [hos host] oe: output resolution 2560x1440 (none chosen: the game's) [hos host] vk: the Output resolution: none chosen, 2560x1440 (the game's 2560x1440, or the screen's where smaller) [hos sead::MainThread] nvn: window crop 0,0 2560x1440 [hos Presentation Thread] vi: 5340 frames presented (81.2 fps over the last 5.0 s, interval 1) [hos Presentation Thread] vi: 5749 frames presented (81.6 fps over the last 5.0 s, interval 1) [hos Presentation Thread] vi: 6160 frames presented (82.0 fps over the last 5.0 s, interval 1) [hos Presentation Thread] vk: GPU time 6.9 ms a frame (the longest submission 2.0 ms); 0.0 textures made a frame ``` this PR @ b8542e6b with `output_res=2048x1152` in the options file (the old picture, still there): ``` [hos host] longshot v3.0.0-rc.3-16-gb8542e6b (source 07a7f5b6) [hos host] oe: output resolution 2048x1152 (the game's at graphics scale 1) [hos sead::MainThread] nvn: window crop 0,0 2048x1152 ``` `tests/test_output_resolution.py` as this PR has it, run on main @ fbd42024 (the temporary folder's path shortened): ``` FAIL 1.6s tests/test_output_resolution.py Assertion failed: is(2560, 1080, 2560, 1080), file ...\rule.cpp, line 15 0 passed, 1 failed, 0 skipped in 2 s (windows, 16 at once) ``` and on this PR: ``` pass 3.4s tests/test_output_resolution.py ``` ## Testing **Tested:** on Windows 11, RTX 5070 Ti (621.01), Ryzen 7 7800X3D. - In the game: the 12 measured runs above, the 12 of the earlier round, plus one run of this PR with `output_res=2048x1152`. Each side loaded both saves and stood for 75 s. No device lost, no crash, about the same draws a frame on both sides, and the log's sizes are the ones in the table. - The previous head, f516654c (on main 514591a3), built and started once with no Output resolution chosen: `longshot v3.0.0-rc.3-27-gf516654c`, `oe: output resolution 2560x1440 (none chosen: the game's)`, `nvn: window crop 0,0 2560x1440`, Kokiri Forest at 12.22 ms median over 20 s (81.4 fps). No device lost. - `python -I -B tests/run_all.py` with llvm-mingw 20261104, on the previous head (f516654c on main 514591a3): 493 passed, 7 failed, 33 skipped, and the same counts with the same 7 failures on main @ 514591a3: `nx2/test_nup_paths.py`, `tests/test_check_third_party.py`, `tests/test_gpu_hang_watch.py`, `tests/test_menu_i18n.py`, `tests/test_portable_builder_home.py`, `tests/test_portable_builder_startup.py`, `tests/test_release.py`. `tests/test_menu_i18n.py` reads `gpu/vk/vk_menu.cpp` and fails on both sides over the same text, the "Testing tools: ..." hint in the pt_BR table, which this PR does not touch; none of the other six reads the changed code. On the measured base the counts were 490 / 6 / 33 on both sides (the same list without `tests/test_menu_i18n.py`). The 33 skips are Linux-only checks and checks that need spirv-val or another tool this PC lacks. - Linux, compile only: `host/nn_applet.c` and `gpu/vk/vk_menu.cpp` compile to objects for `x86_64-linux-gnu` with `nx2/build.py`'s Linux flags and tools.lock's sysroot (llvm-mingw's clang as a cross compiler, on Windows). Not linked, not run. **Not tested:** the head 1896790e (main 9fccd0fd + this change + the review follow-up): not built, not run in the game and `tests/run_all.py` not run on it; the 2048x1152 row's new "(reduced)" mark and hint, and their 13 translations, have not been seen in the game. A Linux build and run. AMD and Intel GPUs. A GPU slow enough for the larger picture to cost real frame rate, and what Auto (this PC) does there. A first start with no options file at all (the runs kept the file and removed only its `output_res=` line). A screen with fewer pixels than 2560x1440: 1080p and the Steam Deck take the same path as before, and the sizes in between (2560x1080, 2256x1504) take a new one that only the unit test ran. DLSS and FSR at the new default (this build has neither). The handheld profile in the game (unchanged code; covered by the unit test). **Needs other testers:** - Any PC (the author's is fine): build the head 1896790e, run `tests/run_all.py`, start a new install once, and screenshot the Output resolution row stepped to 2048x1152, expecting `2048x1152 (reduced)` and the hint "The game's own reduced size, 80% of its 2560x1440: lighter on the GPU." A screen of 2560x1080 or 2256x1504, if anyone has one: a new install should log `(none chosen: the screen's, smaller than the game's 2560x1440)` and the menu show that size "(native)". (request to open) - Linux, any GPU (a Steam Deck or a 1080p screen is welcome too): build this branch and start a new install (no `output_res=` line). On a screen of 2560x1440 or more, expecting `oe: output resolution 2560x1440 (none chosen: the game's)` and `nvn: window crop 0,0 2560x1440` in the log; on a smaller screen, expecting the screen's own size with `(none chosen: the screen's, smaller than the game's 2560x1440)`. Either way the menu's Output resolution shows that size with no restart question, and Kokiri Forest loads and plays (T-A2R9) ## Screenshots Kokiri Forest, the same save and spot, a new install's Output resolution on both, the FPS counter at Breakdown, the game's window alone (2560x1440). Taken in runs of their own, not in the measured ones. | | main @ fbd42024 | this PR @ b8542e6b | |---|---|---| | The Insert menu: Output resolution and Render resolution | `2048x1152 (game's)`, `75% (1536x864)` | `2560x1440`, `75% (1920x1080)` | | The window in play | a 2048x1152 picture scaled up to the window | 2560x1440, pixel for pixel | The four pictures are in the first comment on this pull request: `main_menu.png`, `pr_menu.png`, `main_window.png`, `pr_window.png`. Since then the 2048x1152 choice reads `2048x1152 (reduced)` (was `2048x1152 (game's)`, as in `main_menu.png`); no screenshot of that yet. ## Risk and rollback A new install on a screen of 2560x1440 or more draws 56% more pixels than before (the 3D goes from 1536x864 to 1920x1080 at the game's own 75%). On a slow GPU that costs frame rate; Auto (this PC), the first start's preset, lowers the Render resolution when frames are missed. Screens between 2048x1152 and 2560x1440 in pixels (2560x1080, 2256x1504) now start at their own size and shape, a path only the unit test covered here. That is intended: it is the rule main already had for screens below 2048x1152 (a Steam Deck's 1280x800, 1920x1200 start at their own size and shape), it draws pixel for pixel, and the shape is the monitor's, which the Aspect ratio row's default gave the old 2048x1152 too (widened to 2728x1152 on 21:9, narrowed to 1728x1152 on 3:2); choosing 16:9 on the Aspect ratio row still takes a 16:9 size. To get the old picture: choose 2048x1152 in the menu, or set `output_res=2048x1152`. Reverting the commit restores the old default. VRAM on 4 to 6 GB cards was not measured (only a 16 GB card here). An estimate from the render-target sizes: the game's render targets follow the output's pixels, and the pool it ships for them is 305 MB at 2560x1440; Longshot reserves 512 MB for both sizes (`hos_rt_pool_size`'s floor), so the reservation does not change, and what the targets use in it grows by at most about 110 MB (305 MB x (1 - 0.64)), plus about 10 to 30 MB for Longshot's own output-sized images. What DLSS or FSR keep at the output's size grows too, by an amount not estimated here. Minimum (4GB) and Low (6GB) chosen on the row use the handheld profile (1536x864) and do not change; Auto (this PC), the first start's preset, keeps the docked profile at its tier's Render resolution (50% on Minimum, 75% on Low), so a 4 to 6 GB card on a 1440p or larger screen does take the new size. The VRAM budget rows are unchanged. ## Reviewer notes - Existing installs keep 2048x1152, because the menu saved that size at their first start and a saved default cannot be told from a choice. Moving them (an `options_version` step) is left out on purpose: it would also move players who chose 2048x1152. - `recomplauncher.json`'s default is now 2560x1440, so the two defaults do not drift. A launcher default is one size on every screen: if RecompLauncher writes it before the first start, a Steam Deck there draws 2560x1440 (it drew 2048x1152 before, also larger than its screen). - The menu's mark on 2048x1152 is now "(reduced)", and its hint "The game's own reduced size, 80% of its 2560x1440: lighter on the GPU.": "(game's)" read as the game's preferred size, and the default, once that is 2560x1440. The 13 translations are replaced one for one (machine-made like the rest of the tables), so each table's count in `kLangs` stays. The bug report's line (`pipeline_share.h` `output_text`, "the game's own") is left as it is. - The handheld profile still gets tier 1 (1536x864). nxnative answers tier 0 in both modes; that is a separate change with its own measurements. - `HOS_GRAPHICS_SCALE` still sets only the float the game does not read. ## Issues None filed for this. ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main`. - [ ] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). Not run on the head 1896790e: the author's run was on f516654c; CI's run or a local one on this head is needed. - [x] Tested in the game, or what wasn't is named under Testing. - [x] Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). - [x] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### If applicable - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [x] Flags noted, and the switch reference updated (docs/development.md, the README). - [ ] Screenshots for a change that shows on screen. The new default is shown; the 2048x1152 row's new "(reduced)" mark is not: it needs a run of this head. - [x] A row in `docs/tested-configurations.md` for each measured run. - [ ] A game-free test added for the fix, failing on `main` and passing here. Added, failing on main and passing at f516654c; not run on 1896790e. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [ ] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. Built at f516654c (Windows; Linux compile only); the head 1896790e is not built yet. - [x] Docs updated. 
With no Output resolution chosen the game was told graphics scale tier 1, at which it draws 0.8 of its 2560x1440
display size. The tier is the console's graphics scaling parameter (10, 20, 30 read as tier 0, 1, 2), not the
operation mode; tier 1 came from a register left at the call before's answer. hos_output_default now gives 2560x1440,
or the screen's own size where that has fewer pixels, so the default runs at tier 0. 2048x1152 stays a choice and
still asks for tier 1; options files that already hold a size are read as before.

Assisted-by: Claude Fable 5.2
Co-Authored-By: Claude Fable 5.2 <[email protected]>
docs: tested-configurations rows for the default Output resolution runs
Some checks failed
PR description / Description follows the template (pull_request_target) Successful in 3s
Details
CI / Conventional Commit title (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been cancelled
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been cancelled
Details
CI / Workflow lint (actionlint) (pull_request) Has been cancelled
Details
Third-party parts / As their notes say (pull_request) Has been cancelled
Details
Third-party parts / The same as upstream (pull_request) Has been cancelled
Details
f516654ce1 
The two sides of the pull request's measurement: main fbd42024 and this branch at b8542e6b, a new install's
Output resolution on both, Kokiri Forest and Hyrule Field.

Assisted-by: Claude Fable 5.2
Co-Authored-By: Claude Fable 5.2 <[email protected]>
Amateurwizrd commented 2026-11-13 19:50:45 +00:00
Author
Contributor

The screenshots for the description: Kokiri Forest, the same save and spot, a new install's Output resolution on both, the FPS counter at Breakdown, the game's 2560x1440 window alone. Taken in runs of their own, not in the measured ones.

main @ fbd42024, the Insert menu: Output resolution 2048x1152 (game's), Render resolution 75% (1536x864).

main @ fbd42024, the Insert menu

this PR @ b8542e6b, the Insert menu: Output resolution 2560x1440, Render resolution 75% (1920x1080).

this PR @ b8542e6b, the Insert menu

main @ fbd42024 in play: a 2048x1152 picture scaled up to the window.

main @ fbd42024, in play

this PR @ b8542e6b in play: 2560x1440, pixel for pixel.

this PR @ b8542e6b, in play

The screenshots for the description: Kokiri Forest, the same save and spot, a new install's Output resolution on both, the FPS counter at Breakdown, the game's 2560x1440 window alone. Taken in runs of their own, not in the measured ones. main @ fbd42024, the Insert menu: Output resolution `2048x1152 (game's)`, Render resolution `75% (1536x864)`. ![main @ fbd42024, the Insert menu](https://git.magicbean.dev/attachments/0cb18c9f-39d0-4192-aa5d-5a1f0d7e64fe) this PR @ b8542e6b, the Insert menu: Output resolution `2560x1440`, Render resolution `75% (1920x1080)`. ![this PR @ b8542e6b, the Insert menu](https://git.magicbean.dev/attachments/4bbc5149-6464-459b-ae20-5446fca17412) main @ fbd42024 in play: a 2048x1152 picture scaled up to the window. ![main @ fbd42024, in play](https://git.magicbean.dev/attachments/9c0c46fb-758b-4dd3-825e-4d48edab68dc) this PR @ b8542e6b in play: 2560x1440, pixel for pixel. ![this PR @ b8542e6b, in play](https://git.magicbean.dev/attachments/1e1add6e-dab0-44fb-830f-b19bf9e87648)
main_menu.png
1.2 MiB
pr_menu.png
1.4 MiB
main_window.png
5.5 MiB
pr_window.png
6.3 MiB
Amateurwizrd changed title from WIP: fix(runtime): a new install draws the game's 2560x1440, not its reduced 2048x1152 to fix(runtime): a new install draws the game's 2560x1440, not its reduced 2048x1152 2026-11-13 19:51:07 +00:00
HumanBean requested changes 2026-11-14 01:07:42 +00:00
Dismissed
HumanBean left a comment

Review of 292 at f516654c. I read the code only; I didn't build or run anything.

v3.0.0: yes, once it is rebased. It is small, it keeps existing installs as they are, and it is measured with a before/after and screenshots. The tier explanation for GetCurrentGraphicsScale is a description of behaviour with nxnative cited, not game code, so the licence box holds.

Must change before merge:

  • It doesn't merge. Forgejo reports it as not mergeable against main 25ee6a83. Since 514591a3, main has changed README.md's menu table, docs/development.md's options-file table and vk_menu.cpp (menu_init among them, via #103 and #136). So "Rebased on current main" is false right now. Please rebase, and say in the comment why the numbers still hold (pr status also warns that it was measured on fbd42024). The CI run at the head was still queued when I looked.

Checked and fine:

  • hos_output_default now returns void. Both callers (nn_applet.c output_mode, vk_menu.cpp menu_init) and the test were updated, and no other caller is left.
  • A screen size that isn't known goes to 2560x1440 on both sides.
  • A 2048x1152 screen maps back to tier 1, matching what the menu saves for it.
  • The handheld profile and HOS_OUTPUT_RES are unchanged.
  • Existing files keep their output_res=.

Suggestions / questions (not blocking):

  • VRAM on 4-6 GB cards. This changes the default for everyone, and it was measured only on a 16 GB card. Larger targets cost memory where Minimum/Low are chosen. A note in Risk on what that costs (or one run on a 4-6 GB card) would cover AGENTS.md's "what it costs where it wasn't" for a new default. T-A2R9 asks for Linux only.
  • Screens between the two sizes now get their own shape (2560x1080, 2256x1504, and so on: inline). Before, they got 16:9 2048x1152 widened by the Aspect ratio row. This is probably better, but only the unit test has run it.
  • recomplauncher.json's Output resolution default is still 2048x1152. A RecompLauncher install therefore keeps the old picture. Worth a follow-up issue so the two defaults don't drift.
  • The menu still marks 2048x1152 "(game's)" while the default is 2560x1440. Players will read that as the game's preferred size. The rename can come later, as you say.
Review of 292 at `f516654c`. I read the code only; I didn't build or run anything. **v3.0.0: yes, once it is rebased.** It is small, it keeps existing installs as they are, and it is measured with a before/after and screenshots. The tier explanation for `GetCurrentGraphicsScale` is a description of behaviour with nxnative cited, not game code, so the licence box holds. **Must change before merge:** - **It doesn't merge.** Forgejo reports it as not mergeable against `main` `25ee6a83`. Since `514591a3`, `main` has changed `README.md`'s menu table, `docs/development.md`'s options-file table and `vk_menu.cpp` (`menu_init` among them, via [#103](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/103) and [#136](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/136)). So "Rebased on current `main`" is false right now. Please rebase, and say in the comment why the numbers still hold (`pr status` also warns that it was measured on `fbd42024`). The CI run at the head was still queued when I looked. **Checked and fine:** - `hos_output_default` now returns `void`. Both callers (`nn_applet.c` `output_mode`, `vk_menu.cpp` `menu_init`) and the test were updated, and no other caller is left. - A screen size that isn't known goes to 2560x1440 on both sides. - A 2048x1152 screen maps back to tier 1, matching what the menu saves for it. - The handheld profile and `HOS_OUTPUT_RES` are unchanged. - Existing files keep their `output_res=`. **Suggestions / questions (not blocking):** - **VRAM on 4-6 GB cards.** This changes the default for everyone, and it was measured only on a 16 GB card. Larger targets cost memory where Minimum/Low are chosen. A note in Risk on what that costs (or one run on a 4-6 GB card) would cover AGENTS.md's "what it costs where it wasn't" for a new default. T-A2R9 asks for Linux only. - **Screens between the two sizes now get their own shape** (2560x1080, 2256x1504, and so on: inline). Before, they got 16:9 2048x1152 widened by the Aspect ratio row. This is probably better, but only the unit test has run it. - **`recomplauncher.json`'s Output resolution default is still `2048x1152`.** A RecompLauncher install therefore keeps the old picture. Worth a follow-up issue so the two defaults don't drift. - **The menu still marks 2048x1152 "(game's)"** while the default is 2560x1440. Players will read that as the game's preferred size. The rename can come later, as you say.
README.md Outdated
@ -385,3 +385,3 @@
| Graphics | Quality preset | Custom, Minimum (4GB), Low (6GB), Balanced (8GB), High (12GB), Ultra (16GB+), Auto (this PC) | Auto (this PC) on a first start; Custom in an options file from before it |
| | Aspect ratio | The shapes your screen's resolutions have, narrowest first (5:4, 4:3, 16:10, 16:9, 21:9, 32:9, ...), your monitor's own marked "(monitor's)" (after a restart) | Your monitor's |
| | Output resolution | The Aspect ratio's sizes: your screen's resolutions and the common ones (1440p, 4K, 5K at 16:9; 1920x1200, 2560x1600 at 16:10; 3440x1440 at 21:9; ...), and 2048x1152 (the game's own) at 16:9; your screen's own size is marked "(native)" (after a restart) | 2048x1152, or your screen's size where it is smaller (a Steam Deck's 1280x800, a 1080p monitor); Auto (this PC) leaves it as it is |
| | Output resolution | The Aspect ratio's sizes: your screen's resolutions and the common ones (1440p, 4K, 5K at 16:9; 1920x1200, 2560x1600 at 16:10; 3440x1440 at 21:9; ...), and 2048x1152 (the game's own reduced size, 80% of its 2560x1440) at 16:9; your screen's own size is marked "(native)" (after a restart) | 2560x1440, the game's own picture, or your screen's size where it is smaller (a Steam Deck's 1280x800, a 1080p monitor); Auto (this PC) leaves it as it is |
HumanBean commented 2026-11-14 01:07:42 +00:00
Owner

This conflicts with main now: #136 and #103 changed this table. Please rebase. The recomplauncher.json default (output_res: 2048x1152) will then be the only place that still says the old size.

This conflicts with `main` now: #136 and #103 changed this table. Please rebase. The `recomplauncher.json` default (`output_res: 2048x1152`) will then be the only place that still says the old size.
host/hos_wide_size.h Outdated
@ -25,3 +26,1 @@
if ((uint64_t)sw * sh >= 2048ULL * 1152 || !hos_output_size_valid(sw, sh)) return 0;
*w = sw, *h = sh;
return 1;
if ((uint64_t)sw * sh < 2560ULL * 1440 && hos_output_size_valid(sw, sh)) *w = sw, *h = sh;
HumanBean commented 2026-11-14 01:07:42 +00:00
Owner

Screens with fewer pixels than 2560x1440 but more than 2048x1152 now take their own size: 2560x1080 (21:9), 2256x1504 (3:2), 2560x1200. Those sizes are off 16:9, so hos_output_own_shape now sets the picture's shape from the default, where before it came from 2048x1152 widened by the Aspect ratio row. That is probably the better result, but it's a new path for ultrawide and 3:2 laptop screens that only the unit test has covered. Worth a line in the T-A2R9 request, or a run on one of those sizes.

Screens with fewer pixels than 2560x1440 but more than 2048x1152 now take their own size: 2560x1080 (21:9), 2256x1504 (3:2), 2560x1200. Those sizes are off 16:9, so `hos_output_own_shape` now sets the picture's shape from the default, where before it came from 2048x1152 widened by the Aspect ratio row. That is probably the better result, but it's a new path for ultrawide and 3:2 laptop screens that only the unit test has covered. Worth a line in the T-A2R9 request, or a run on one of those sizes.
HumanBean added this to the v3.0.0 milestone 2026-11-14 01:22:18 +00:00
HumanBean force-pushed fix/default-output-2560x1440 from f516654ce1
Some checks failed
PR description / Description follows the template (pull_request_target) Successful in 3s
Details
CI / Conventional Commit title (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been cancelled
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been cancelled
Details
CI / Workflow lint (actionlint) (pull_request) Has been cancelled
Details
Third-party parts / As their notes say (pull_request) Has been cancelled
Details
Third-party parts / The same as upstream (pull_request) Has been cancelled
Details
to 1896790ef0
Some checks failed
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been skipped
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been skipped
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been skipped
Details
Third-party parts / The same as upstream (pull_request) Has been skipped
Details
CI / Conventional Commit title (pull_request) Successful in 4s
Details
CI / Workflow lint (actionlint) (pull_request) Successful in 7s
Details
Third-party parts / As their notes say (pull_request) Successful in 6s
Details
PR description / Description follows the template (pull_request_target) Failing after 8s
Details
2026-11-14 01:30:15 +00:00 Compare
HumanBean commented 2026-11-14 01:31:41 +00:00
Owner

Rebased onto main 9fccd0fd and answered the review (#292 (comment)). The head is now 1896790e. Nothing was built, tested or run for this push.

Rebase. The branch is linear on 9fccd0fd: c312ae2d (the change, was 9c4d7a7e), 83d00991 (the tested-configurations rows, was f516654c) and 1896790e (the follow-up below).

  • The change's own lines are identical to the old patch. jj merged README.md, docs/development.md and vk_menu.cpp with no conflict: main's edits from #103 and #136 sit next to this PR's lines, not on them.
  • The one conflict was docs/tested-configurations.md, where main had added rows at the top of the same table. I kept both sides: this PR's two rows first, then main's.
  • No main change is reverted. Each rebased commit's diff matches its original line for line.
  • The numbers still hold. The measured patch (b8542e6b) is unchanged in c312ae2d. The commits main gained since fbd42024 don't touch the Output resolution and apply to both sides alike. The follow-up changes no size the game draws.

Review points.

  1. Rebased, and the "Rebased on current main" box is ticked with the template's wording.
  2. VRAM on 4 to 6 GB cards: Risk now says it is not measured, with an estimate from the render-target sizes:
    • The render-target pool is 512 MB at both sizes (hos_rt_pool_size's floor), so the reservation doesn't change.
    • What the game's targets use inside it grows by at most about 110 MB (its 305 MB at 2560x1440 × 0.36).
    • Longshot's own output-sized images add about 10 to 30 MB more. DLSS and FSR use more too; I didn't estimate that.
    • Minimum (4GB) and Low (6GB) chosen on the row use the handheld profile and are unaffected. Auto (this PC) stays docked and does take the new size.
  3. Screens between the two sizes (2560x1080, 2256x1504) starting at their own size and shape: kept, on purpose.
    • It is main's existing rule for screens below 2048x1152 (1280x800, 1920x1200), and it draws pixel for pixel.
    • The shape is the monitor's, which the Aspect ratio row's default already gave the old 2048x1152.
    • This is now said in host/hos_wide_size.h, README.md, docs/graphics-and-controls.md, docs/development.md and the description.
  4. recomplauncher.json is the RecompLauncher manifest that ships inside both builders (docs/releases.md). Its output_res default is now 2560x1440. Risk says that if RecompLauncher writes its defaults before the first start, a Steam Deck there gets 2560x1440; it got 2048x1152 before. I didn't check whether it does.
  5. The 2048x1152 choice is now marked (reduced), not (game's), which meant "the game's own size" and so read as the default. Its hint is now "The game's own reduced size, 80% of its 2560x1440: lighter on the GPU."
    • All 13 tables in gpu/vk/menu_i18n.h replace the two texts one for one, in sorted order, so the kLangs counts are unchanged. The new translations are machine-made, like the rest.
    • tests/test_output_resolution.py's expected labels are updated to match.

Boxes. Unticked until someone builds and runs 1896790e, each with the reason beside it: run_all.py, the game-free test, the host build, and the screenshot of the new (reduced) mark.

This change needs a run. The (reduced) label and hint show on screen and haven't been seen in the game. That run, tests/run_all.py on this head (or CI's), and a screenshot are listed under Needs other testers.

Rebased onto main `9fccd0fd` and answered the review (https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/292#issuecomment-15716). The head is now `1896790e`. Nothing was built, tested or run for this push. **Rebase.** The branch is linear on `9fccd0fd`: `c312ae2d` (the change, was `9c4d7a7e`), `83d00991` (the tested-configurations rows, was `f516654c`) and `1896790e` (the follow-up below). - The change's own lines are identical to the old patch. jj merged `README.md`, `docs/development.md` and `vk_menu.cpp` with no conflict: main's edits from https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/103 and https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/136 sit next to this PR's lines, not on them. - The one conflict was `docs/tested-configurations.md`, where main had added rows at the top of the same table. I kept both sides: this PR's two rows first, then main's. - No main change is reverted. Each rebased commit's diff matches its original line for line. - The numbers still hold. The measured patch (`b8542e6b`) is unchanged in `c312ae2d`. The commits main gained since `fbd42024` don't touch the Output resolution and apply to both sides alike. The follow-up changes no size the game draws. **Review points.** 1. Rebased, and the "Rebased on current `main`" box is ticked with the template's wording. 2. VRAM on 4 to 6 GB cards: Risk now says it is not measured, with an estimate from the render-target sizes: - The render-target pool is 512 MB at both sizes (`hos_rt_pool_size`'s floor), so the reservation doesn't change. - What the game's targets use inside it grows by at most about 110 MB (its 305 MB at 2560x1440 × 0.36). - Longshot's own output-sized images add about 10 to 30 MB more. DLSS and FSR use more too; I didn't estimate that. - Minimum (4GB) and Low (6GB) chosen on the row use the handheld profile and are unaffected. Auto (this PC) stays docked and does take the new size. 3. Screens between the two sizes (2560x1080, 2256x1504) starting at their own size and shape: kept, on purpose. - It is main's existing rule for screens below 2048x1152 (1280x800, 1920x1200), and it draws pixel for pixel. - The shape is the monitor's, which the Aspect ratio row's default already gave the old 2048x1152. - This is now said in `host/hos_wide_size.h`, `README.md`, `docs/graphics-and-controls.md`, `docs/development.md` and the description. 4. `recomplauncher.json` is the RecompLauncher manifest that ships inside both builders (`docs/releases.md`). Its `output_res` default is now `2560x1440`. Risk says that if RecompLauncher writes its defaults before the first start, a Steam Deck there gets 2560x1440; it got 2048x1152 before. I didn't check whether it does. 5. The 2048x1152 choice is now marked `(reduced)`, not `(game's)`, which meant "the game's own size" and so read as the default. Its hint is now "The game's own reduced size, 80% of its 2560x1440: lighter on the GPU." - All 13 tables in `gpu/vk/menu_i18n.h` replace the two texts one for one, in sorted order, so the `kLangs` counts are unchanged. The new translations are machine-made, like the rest. - `tests/test_output_resolution.py`'s expected labels are updated to match. **Boxes.** Unticked until someone builds and runs `1896790e`, each with the reason beside it: `run_all.py`, the game-free test, the host build, and the screenshot of the new `(reduced)` mark. **This change needs a run.** The `(reduced)` label and hint show on screen and haven't been seen in the game. That run, `tests/run_all.py` on this head (or CI's), and a screenshot are listed under Needs other testers.
HumanBean reviewed 2026-11-14 01:38:13 +00:00
HumanBean left a comment

Re-review of the head 1896790e, after our earlier review (#292 (comment)) and its follow-up (#292 (comment)). I read the code only and ran nothing: no build, no tests, no checkers.

Verdict: the code is right and I found no bug. What's left is the runs. The only For everyone box still unticked is run_all.py on this head. CONTRIBUTING says a PR in that state stays WIP, and the description check fails on it, so I'm not approving yet. This review replaces our request for changes.

Rebase

  • c312ae2d and 83d00991 add and remove exactly the same lines as 9c4d7a7e and f516654c did. Their diffs are against 9fccd0fd, so none of main's changes is reverted.
  • docs/tested-configurations.md only gains this PR's two rows. Main's rows are still there.
  • Main has moved since, to eca9b12a (#216, #191, #190). Those commits touch other parts of docs/development.md and docs/tested-configurations.md, and Forgejo still reports the PR as mergeable. It doesn't need another rebase.

1896790e

  • Keys match the menu. menu_i18n.h uses " (reduced)" and "The game's own reduced size, 80% of its 2560x1440: lighter on the GPU.", and both are exactly the strings in vk_menu.cpp (tx_output_res, hn_output_res). Nothing in gpu/, host/ or nx2/ still uses " (game's)" or "The game's own size.", so taking those keys out of the tables is right. "Native (the game's)" is a different key and still used.
  • Sort order. Lookup doesn't depend on it: vk_menu_i18n.cpp table() builds an unordered_map. tests/test_menu_i18n.py still checks it, though, and every table is in order. " (reduced)" sits between " (not connected)" and " and ", and the hint sits between "…own pace…" and "…own shape.".
  • Counts and keys. Each of the 13 tables has as many entries as its kLangs count says (pt-BR 531 … zh-Hant 539). No key appears twice. All 13 contain both new keys and neither old one.
  • The % in the hint is safe. In "80% of" and in translations like "80 % de" / "80% dos", the % isn't read as a conversion: vk_menu_i18n.cpp conversion() and the test's regex don't accept a space after %. Hints aren't used as printf formats either; "80% suits" is already in the menu.
  • Spacing and translations. Every translation of " (reduced)" keeps the leading space and has no trailing space. The adjectives agree with the word "resolution" in each language (reduzida, reducida, réduite, reduziert, ridotta, verkleind, zmniejszona, уменьшенное, 縮小, 축소, 缩小/縮小), and the hints read naturally.
  • Test labels. tests/test_output_resolution.py: all 18 case rows and the two tx_output_res(0) assertions (2728x1152, 4096x1152) now expect (reduced), and nothing left in the file expects (game's).
  • VRAM estimate. The reasoning holds. When the game uses its own size, hos_output_size() returns 2560x1440 either way, so hos_rt_pool_size() reserves 512 MB for both sizes. 305 MB × (1 − 0.64) ≈ 110 MB is an upper bound for targets that scale with pixel count. Each RGBA8 image grows by about 5.3 MB, so 10 to 30 MB is roughly 2 to 6 of Longshot's own images.
  • Docs match the code. hos_output_default() uses the screen's own size when it is valid and has fewer pixels than 2560x1440. That covers 2560x1080 and 2256x1504, and before this change it already covered 1280x800 and 1920x1200 (2,304,000 px is less than 2048x1152's 2,359,296). An invalid output_res= line still gives the reduced 2048x1152, and the README's "anything else uses the game's reduced 2048x1152" says so correctly.
  • recomplauncher.json. This file ships in both builders (scripts/builder_package.py, scripts/linux/appimage.sh). Nothing in this repo reads the defaults field. RecompLauncher's schema (https://recomplauncher.com/schema/recomplauncher.json) describes settings[].defaults as "The game's own values for keys the file doesn't have yet". So it describes what the game does; RecompLauncher doesn't write it. Changing it can't change what a Steam Deck or an existing install draws, because the game still decides when the line is missing and an existing file already has the line. The only effect is which choice RecompLauncher shows as selected. That is now right on screens of 2560x1440 and up. On a Deck it's still wrong (2560x1440 shown, 1280x800 drawn), as 2048x1152 was before. See the inline comment.

CI on 1896790e: nothing compiled it. In ci.yml, the Python source checks and the SPIR-V fixtures only run on workflow_dispatch, so on this PR they were skipped. The checks that ran passed: the title, actionlint and the third-party notes. "PR description" fails because of the unticked boxes.

Still to do before it can merge

  1. python -I -B tests/run_all.py on 1896790e, run locally or through a manual CI dispatch. test_menu_i18n.py and test_output_resolution.py matter most. Then tick that box, the game-free test box and the host build box.
  2. A build of the head and one new install, with a screenshot of the Output resolution row stepped to 2048x1152 (reduced) and its hint. That settles the Screenshots box. The test request for this is still listed as "to open".
  3. Optional: change the RecompLauncher sentences in Flags and settings (the Untested column), Reviewer notes and the follow-up comment to match the schema. RecompLauncher doesn't write defaults, so the "if it writes its defaults" risk for a Steam Deck doesn't arise. What's left is a launcher showing the wrong choice on small screens.

Once 1 and 2 are done and pr status 292 passes, this can be approved as it is.

Re-review of the head `1896790e`, after our earlier review (https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/292#issuecomment-15716) and its follow-up (https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/292#issuecomment-15863). I read the code only and ran nothing: no build, no tests, no checkers. **Verdict: the code is right and I found no bug. What's left is the runs.** The only *For everyone* box still unticked is `run_all.py` on this head. CONTRIBUTING says a PR in that state stays WIP, and the description check fails on it, so I'm not approving yet. This review replaces our request for changes. **Rebase** - `c312ae2d` and `83d00991` add and remove exactly the same lines as `9c4d7a7e` and `f516654c` did. Their diffs are against `9fccd0fd`, so none of main's changes is reverted. - `docs/tested-configurations.md` only gains this PR's two rows. Main's rows are still there. - Main has moved since, to `eca9b12a` (https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/216, https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/191, https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/190). Those commits touch other parts of `docs/development.md` and `docs/tested-configurations.md`, and Forgejo still reports the PR as mergeable. It doesn't need another rebase. **`1896790e`** - **Keys match the menu.** `menu_i18n.h` uses `" (reduced)"` and `"The game's own reduced size, 80% of its 2560x1440: lighter on the GPU."`, and both are exactly the strings in `vk_menu.cpp` (`tx_output_res`, `hn_output_res`). Nothing in `gpu/`, `host/` or `nx2/` still uses `" (game's)"` or `"The game's own size."`, so taking those keys out of the tables is right. `"Native (the game's)"` is a different key and still used. - **Sort order.** Lookup doesn't depend on it: `vk_menu_i18n.cpp` `table()` builds an `unordered_map`. `tests/test_menu_i18n.py` still checks it, though, and every table is in order. `" (reduced)"` sits between `" (not connected)"` and `" and "`, and the hint sits between "…own pace…" and "…own shape.". - **Counts and keys.** Each of the 13 tables has as many entries as its `kLangs` count says (pt-BR 531 … zh-Hant 539). No key appears twice. All 13 contain both new keys and neither old one. - **The `%` in the hint is safe.** In "80% of" and in translations like "80 % de" / "80% dos", the `%` isn't read as a conversion: `vk_menu_i18n.cpp` `conversion()` and the test's regex don't accept a space after `%`. Hints aren't used as printf formats either; "80% suits" is already in the menu. - **Spacing and translations.** Every translation of `" (reduced)"` keeps the leading space and has no trailing space. The adjectives agree with the word "resolution" in each language (reduzida, reducida, réduite, reduziert, ridotta, verkleind, zmniejszona, уменьшенное, 縮小, 축소, 缩小/縮小), and the hints read naturally. - **Test labels.** `tests/test_output_resolution.py`: all 18 case rows and the two `tx_output_res(0)` assertions (2728x1152, 4096x1152) now expect `(reduced)`, and nothing left in the file expects `(game's)`. - **VRAM estimate.** The reasoning holds. When the game uses its own size, `hos_output_size()` returns 2560x1440 either way, so `hos_rt_pool_size()` reserves 512 MB for both sizes. 305 MB × (1 − 0.64) ≈ 110 MB is an upper bound for targets that scale with pixel count. Each RGBA8 image grows by about 5.3 MB, so 10 to 30 MB is roughly 2 to 6 of Longshot's own images. - **Docs match the code.** `hos_output_default()` uses the screen's own size when it is valid and has fewer pixels than 2560x1440. That covers 2560x1080 and 2256x1504, and before this change it already covered 1280x800 and 1920x1200 (2,304,000 px is less than 2048x1152's 2,359,296). An invalid `output_res=` line still gives the reduced 2048x1152, and the README's "anything else uses the game's reduced 2048x1152" says so correctly. - **`recomplauncher.json`.** This file ships in both builders (`scripts/builder_package.py`, `scripts/linux/appimage.sh`). Nothing in this repo reads the `defaults` field. RecompLauncher's schema (https://recomplauncher.com/schema/recomplauncher.json) describes `settings[].defaults` as "The game's own values for keys the file doesn't have yet". So it describes what the game does; RecompLauncher doesn't write it. Changing it can't change what a Steam Deck or an existing install draws, because the game still decides when the line is missing and an existing file already has the line. The only effect is which choice RecompLauncher shows as selected. That is now right on screens of 2560x1440 and up. On a Deck it's still wrong (2560x1440 shown, 1280x800 drawn), as 2048x1152 was before. See the inline comment. **CI on `1896790e`: nothing compiled it.** In `ci.yml`, the Python source checks and the SPIR-V fixtures only run on `workflow_dispatch`, so on this PR they were skipped. The checks that ran passed: the title, actionlint and the third-party notes. "PR description" fails because of the unticked boxes. **Still to do before it can merge** 1. `python -I -B tests/run_all.py` on `1896790e`, run locally or through a manual CI dispatch. `test_menu_i18n.py` and `test_output_resolution.py` matter most. Then tick that box, the game-free test box and the host build box. 2. A build of the head and one new install, with a screenshot of the Output resolution row stepped to `2048x1152 (reduced)` and its hint. That settles the Screenshots box. The test request for this is still listed as "to open". 3. Optional: change the RecompLauncher sentences in *Flags and settings* (the Untested column), *Reviewer notes* and the follow-up comment to match the schema. RecompLauncher doesn't write `defaults`, so the "if it writes its defaults" risk for a Steam Deck doesn't arise. What's left is a launcher showing the wrong choice on small screens. Once 1 and 2 are done and `pr status 292` passes, this can be approved as it is.
recomplauncher.json Outdated
@ -267,3 +267,3 @@
],
"defaults": {
"output_res": "2048x1152"
"output_res": "2560x1440"
HumanBean commented 2026-11-14 01:38:13 +00:00
Owner

Right change, and it's safer than the Risk section says. RecompLauncher's schema (https://recomplauncher.com/schema/recomplauncher.json) describes settings[].defaults as "The game's own values for keys the file doesn't have yet". So RecompLauncher uses this value to pick which choice to show as selected while longshot_options.ini has no output_res= line. It doesn't write it. A Steam Deck or an existing install still draws what the game decides (hos_output_default, or the line already in the file). The only thing that's off is the display: on a screen smaller than 2560x1440 the launcher shows 2560x1440 selected while the game draws the screen's own size. Before this change it showed 2048x1152 there, also wrong. The "if RecompLauncher writes its defaults before the first start" sentence in Flags and settings and Reviewer notes can say that instead.

Right change, and it's safer than the Risk section says. RecompLauncher's schema (https://recomplauncher.com/schema/recomplauncher.json) describes `settings[].defaults` as "The game's own values for keys the file doesn't have yet". So RecompLauncher uses this value to pick which choice to show as selected while `longshot_options.ini` has no `output_res=` line. It doesn't write it. A Steam Deck or an existing install still draws what the game decides (`hos_output_default`, or the line already in the file). The only thing that's off is the display: on a screen smaller than 2560x1440 the launcher shows 2560x1440 selected while the game draws the screen's own size. Before this change it showed 2048x1152 there, also wrong. The "if RecompLauncher writes its defaults before the first start" sentence in *Flags and settings* and *Reviewer notes* can say that instead.
HumanBean dismissed HumanBean's review 2026-11-14 01:38:20 +00:00
Reason:

Superseded by #292 (comment): the rebase and the follow-up answer every point; no code change is needed, only the run of run_all.py, a build and the (reduced) screenshot remain.

HumanBean commented 2026-11-14 01:41:41 +00:00
Owner

Rebased again onto current main (a4c77174). Seven PRs had merged since, among them #324, #189 and #269. The three commits are now 8853a536, a0161645 and 7578caa2, and the first two are still yours.

Only docs/tested-configurations.md conflicted: main had added rows at the top of the table, where this PR adds its two. I kept both, with this PR's rows first and main's right after, as in the last rebase. Each commit's added and removed lines are the same as before the rebase. No tests or builds were run on this PC.

Rebased again onto current `main` (a4c77174). Seven PRs had merged since, among them https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/324, https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/189 and https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/269. The three commits are now 8853a536, a0161645 and 7578caa2, and the first two are still yours. Only `docs/tested-configurations.md` conflicted: `main` had added rows at the top of the table, where this PR adds its two. I kept both, with this PR's rows first and `main`'s right after, as in the last rebase. Each commit's added and removed lines are the same as before the rebase. No tests or builds were run on this PC.
HumanBean force-pushed fix/default-output-2560x1440 from 1896790ef0
Some checks failed
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been skipped
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been skipped
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been skipped
Details
Third-party parts / The same as upstream (pull_request) Has been skipped
Details
CI / Conventional Commit title (pull_request) Successful in 4s
Details
CI / Workflow lint (actionlint) (pull_request) Successful in 7s
Details
Third-party parts / As their notes say (pull_request) Successful in 6s
Details
PR description / Description follows the template (pull_request_target) Failing after 8s
Details
to 7578caa2ae
Some checks failed
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been skipped
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been skipped
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been skipped
Details
Third-party parts / The same as upstream (pull_request) Has been skipped
Details
CI / Conventional Commit title (pull_request) Successful in 6s
Details
PR description / Description follows the template (pull_request_target) Failing after 8s
Details
CI / Workflow lint (actionlint) (pull_request) Successful in 9s
Details
Third-party parts / As their notes say (pull_request) Successful in 10s
Details
Website / Website on Cloudflare (pull_request_target) Has been skipped
Details
2026-11-14 01:41:43 +00:00 Compare
HumanBean deleted branch fix/default-output-2560x1440 2026-11-14 01:46:54 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
area/accessibility
Barriers for people with disabilities

  
area/audio
Sound and music

  
area/input
Controllers, keyboard, mouse

  
area/install
Installing, updating, building from your game

  
area/menu
In-game menu and settings

  
area/renderer
Vulkan renderer, shaders, effects

  
area/saves
Save files

  
area/upscaling
DLSS, FSR, frame generation

  
good first issue
A good start for a new contributor

  
gpu/amd
AMD GPUs

  
gpu/igpu
Integrated GPUs

  
gpu/intel
Intel GPUs

  
gpu/nvidia
NVIDIA GPUs

  
help wanted
Extra hands or knowledge wanted

  
kind
bug
 Something doesn't work as it should

  
kind
chore
 Build, CI, dependencies, tidying

  
kind
docs
 Documentation

  
kind
feature
 A new feature or an improvement

  
kind
performance
 Frame rate, frame time, loading, memory

  
kind
question
 A question rather than a change

  
needs measurements
Waiting for before/after measurements

  
platform/linux
Linux only

  
platform/steam-deck
Steam Deck

  
platform/windows
Windows only

  
preview
Maintainers: deploy a preview of this PR's website (read its changes first). Removed after the run.

  
priority
critical
 Crashes, data loss, or blocks most players

  
priority
high
 Important: next in line

  
priority
low
 Nice to have

  
status
blocked
 Waits on something else first

  
status
confirmed
 Reproduced or agreed on

  
status
duplicate
 Already reported or proposed

  
status
invalid
 Not a problem in this project

  
status
needs-info
 Waiting for more information from the reporter

  
status
wontfix
 Will not be worked on

  
testing wanted
Wanted: a test on other hardware (posts a test request in #test-requests)

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
Milestone
Clear milestone
No items
No milestone
v3.0.0
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
MagicBeanDev/Longshot!292
No description provided.