Repository navigation
fix: preserve FPS counter scale when the menu fits to the screen - #1665
Closed
monsterlag wants to merge 8 commits into
Closed
monsterlag wants to merge 8 commits into
monsterlag wants to merge 8 commits into
Conversation
…d in small windows (v2.0.13) The menu's scale is a whole step for each 720 lines and the Graphics tab is about 820 lines a step, so at 1440p or 4K fullscreen it came out taller than the screen; copy_over leaves out a bitmap that does not fit, and F1 and Insert showed nothing (a window on the same monitor was scale 1 and fitted). Drawn too large, the menu is now drawn again a step smaller, kept until the window's size changes; at the smallest scale and still too tall (a 720-line window) it is cut to the window, centred as before (the mouse's origin is the same), rather than left out. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… and tabs show; the help below is cut) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Retain the viewport scale for the FPS bitmap and margins while the menu keeps its fitted integer step. Add authored actual-source coverage for open, closed and resized menus plus existing FPS ordering checks. Assisted-by: OpenAI Codex
The cap raised the pacing and wrote the measured rate, up to the cap, into the engine's nominal rate. The engine's own rate is 60 over a whole number of display intervals, never above 60, and its controller puts 60 back before the time step is made from it: above 60 fps every frame still stepped 1/60 s and the game ran fps/60 too fast (4.0 in the menus at 240 fps, 1.23 to 1.42 in Kokiri at 73 to 85 fps). nx2/oot_patches.py puts the host's measured frame time at the engine's two step divides, both or neither. host/nn_vi.c publishes it while the cap is above 60 and keeps the rate under it within the engine's 15 to 60. At a cap of 60 nothing is published and the game's own divide runs. HOS_FPS_STEP=0 keeps the rate up to the cap, as before; HOS_FPS_LOG=1 also logs the game clock against the wall clock. Co-Authored-By: Claude <noreply@anthropic.com>
…-fps-scale-independent
Compile the actual menu hit header after the maintainer hotfix routes menu_record placement through menu_hit::origin. Keep all existing ordering assertions. Assisted-by: OpenAI Codex
…-fps-scale-independent
monsterlag
changed the base branch from
hotfix/menu-fits-screen
to
release/v2.0.13
November 10, 2026 13:08
monsterlag
marked this pull request as ready for review
November 10, 2026 13:15
Owner
|
Thanks, good catch: the v2.0.13 menu fit shrank the FPS counter with it. Your code and tests are in #1680 with you as co-author. That PR leaves out the two screenshots under |
NotRexed
added a commit
that referenced
this pull request
Nov 10, 2026
…drawn smaller to fit (v2.0.13 line) (#1680) The menu fit (v2.0.13) set cur_scale to the menu's smaller step, and the FPS counter was drawn and placed at cur_scale: opening the menu at 1440p or 2160p shrank the counter, which stayed small after it closed. The counter now uses the screen's own scale (scale_of). From monsterlag's #1665, without its screenshots (no game imagery in the repository); tests/test_menu_fps_scale.py. Co-authored-by: monsterlag <64719697+monsterlag@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Opening the fitted menu at 1440p or 2160p shrinks the FPS counter, and it stays smaller after the menu closes. Keep the counter's bitmap, font and margins at the viewport scale while the menu retains its smaller fitted scale.
This follows the menu hotfix in v2.0.13, targeting
release/v2.0.13; main already uses the new ImGui menu. Menu fitting, clipping, pointer mapping and game timing are unchanged by this PR.Windows 11, RTX 5090, Vulkan 1.4 driver
0x9a4a8000, 5120x2160 fullscreen, native cap60, frame generation off: opening/closing the menu reproduced the smaller counter before the patch. With the patch it retains its original size, the full Graphics menu remains readable, and pointer navigation between Controls and Graphics works. No setting values were edited. The patched runtime used the matching host/renderer source tree12a90038(integration9c13035), identical to this PR's source headc2ef031; the current head only adds the images below.Both screenshots are after opening and closing the menu. The title background animates; the counter is at top right. Sky saved unmodified 4096x1728 captures of the 5120x2160 game window.
Before:
After:
Validation:
c2ef031: 218 passed, 1 failed, 22 skipped. The failure is the unchanged MSVC-target precompile fixture's missingwindows.hin the local LLVM-MinGW environment, before fixture execution. It remains a failure; the full suite was not rerun and no checks or skip policy were relaxed.Assisted-by: OpenAI Codex; visual checks with GPT-6.1 Terra.