The row writes scene_share = 1 with dlaa = 0, which the start already sized the render-target heap for; widescreen.c now
reads the share live, says when the heap needs a restart for it (the row's note and the Restart count), and logs the
scene size, the picture size and how the scene is scaled once the fixed share takes over and at each change. The
stand-in copies a scene of the picture's size texel for texel with a nearest sampler, and the performance overlay shows
Ocarina's real scene size instead of the other builds' placeholders. scene_share gets its settings row and its ini
text; the row's texts are in all four menu languages.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The scene's share followed the settings alone. When the grown table could not be built or written (a table in a form
that is not rewritten, as a mod's may be, or a profile folder that cannot be written), the game kept the shipped heap
and the scene still went to the whole picture inside it, which is the crash the growth was made for.
The start now asks for the table before the first present and looks at the answer: without the grown table the scene
is three quarters of the picture at most and the picture stays the game's own 2560x1440, with a log line that says so.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The heap grew by the full-picture factor whenever the upscaler setting was on, in every mode, and without a limit:
915 MiB at 3840x2160 where the modes below three quarters need 382, and at 10240x2880 an application pool of 13.5 GiB,
past the 12 GiB heap region, where the game's SetHeapSize is refused and nothing starts.
The share is now the start's own mode: all of the picture for dlaa, the game's own most for the modes below it. The
growth stops at what the pool can take (2,478 MiB): the scene's share is lowered to what fits, with a log line, and a
picture too large even for the game's own scene gets the most there is and a warning. A mode chosen in the menu that
renders more than the start's keeps the start's share until a restart, as the log and nx2navi.ini.example now say.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The heap the engine's render targets live in is made for a 2560x1440 picture whose scene is three quarters of it at most. It grew only with the picture. With DLAA, or FSR at native size, the scene is the whole picture: at the game's own 1440 lines that is 2560x1440 targets where the game never passes 1920x1080, in a heap that had not grown at all. The render-target manager's search for a free block then takes its out-of-memory path and reads through a null block: a player's game ended there (main+0x3ed00, reading address 0x48) each time a dialogue closed in Castle Town on 0.8.0 with dlss = dlaa (#605), the same function that failed at 5120x2160 before the heap followed the picture.
The heap and the application pool now grow by the scene's pixels over the game's most as well: 238 MiB at 1440 lines with the upscaler setting on, nothing without it, and nothing at 1080 lines, where a full scene is the game's own size. The share is decided at the start, from the settings; an upscaler first switched on in the menu of a run that began without one keeps the scene at three quarters until a restart, and the log says so. Compiled; not played.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The game draws the whole picture into the 543x306 target of the save's picture, so a picture wider than 16:9 came out squeezed. The new set wide_save has one site in the viewport helper, where it loads the address of SetViewport: a viewport of exactly 0, 0, 543, 306 gets the patch page's two numbers added to its x and its width, without branches or flags. widescreen.c writes them for a picture wider than 16:9 and switches the set on only then; the scissor, set before, keeps the target's size.
C generated before the set existed keeps the other widescreen sets, and the log says that the save's picture is squeezed.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The game sizes its scene against its own 1440-line picture only while the picture is taller; under a smaller picture
it measures against that picture itself. The share was scaled by the picture's height over 1440 in both cases, so a
1080-line picture got three quarters of the scene its mode names: Quality drew 960x540 instead of 1280x720. A picture
of 1440 lines is unchanged; a 1080-line one now draws 1.78 times the pixels in every mode, which costs frame rate on
slow cards and is what the mode asks for.
From pull request #393 by mooki000, taken as it is.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
On Linux the Screen tab listed the five FSR 3.1 upscaling modes and AMD's frame generation, but only the
Windows build loads amd_fidelityfx_vk.dll: a player who picked a mode got the scene at the mode's share of
the picture with nothing to scale it back up. vk_ffx_available answers from the load's result once it ran,
and before that from the library file being there, so the menu can ask every frame. Where it says no,
the menu lists neither, a mode that is still set shows "in use: off", the scene keeps the game's own
share (vk_dlaa_fsr3), frame generation keeps the plain swapchain with one log line, and the texts name
what does run.
Pull request #371 by mooki000, taken as it is; two hunks merged by hand (vk_fg_wanted, which now also
stays off after a failure, and a README line that had gained Texture filtering). It touches vk_dlaa.c,
which another session is changing: vk_dlaa_fsr3 gains the availability test and one log text changes.
On Windows the menu changes only where the DLL is missing. The Windows files compile; nothing was run.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Without DLSS or FSR 3.1 the game's dynamic resolution took the scene down to a third of the picture under load, and a plain scale showed every step of that. NX2NAVI_SCENE_SHARE sets the share, and 0 leaves the game's dynamic resolution on.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
At Ultra Performance (an 854x480 scene) the Ocarina frame shape took the first single-target pass wider than the scene
as the output pass: a 960x540 post pass comes before the picture's, so DLSS upscaled to 960x540 and that was stretched
to the output. The output pass must now be at least the scene over the mode's share (widescreen.c dlss_share, exposed
as wide_dlss_share), which skips it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Upscaling row no longer carries "DLSS on or off: after restart". It shows "after restart" only while the upscaler picked cannot start in this run. Frame generation says so only for a change to or from NVIDIA's, since AMD's applies at once, and the HDR row no longer says it twice.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The picture's height can now be 1080, below the game's own 1440, for slower GPUs: the scene, the DLSS and FSR 3.1
modes and frame generation follow it, and the ultrawide shapes become 2560x1080 and 3840x1080. "Native" keeps its
floor of 1440. The example settings file now documents game_aspect and game_res.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The game sizes its scene from the scale at the patch page against its own 1440-line picture, so on a 2160-line
picture native DLAA rendered a 1440-line scene and Quality 44 %. The page now gets the share times the picture's
height over 1440, and DLAA is native at any picture size. Switching dlaa off in the menu also gives the scene back
the game's own scale instead of leaving it small with nothing to enlarge it.
FSR 3.1 frame generation was created with the window as its largest render size, but it is given the scene's depth
and motion vectors, up to the picture's size. A 3414x1440 or 5120x2160 scene in a 1920x1080 window wrote past its
resources: a crash in amd_fidelityfx_vk.dll, device faults, striped frames. The context is now made for the picture's
size once.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- A GPU index or name that is not usable, or no longer there, falls back to the best usable GPU with a log line instead
of stopping the game before the menu can change it (vk_device.c pick_device).
- A held Esc no longer opens the menu and closes it again on its first key repeat (menu_win.cpp, menu_sdl.cpp).
- The menu does not open on the boot screen, where it was not drawn while its keys queued up and changed settings once
the game ran.
- The DLSS render scale follows the upscaler that runs: a DLSS or FSR 3.1 mode picked in the menu, which applies after
a restart, or DLSS where NGX is not available, no longer shrinks the scene with nothing to scale it back up.
- Upscaling without DLSS or FSR 3.1 also turns frame generation off, which needs their motion vectors.
- The HDR peak brightness slider reaches the setting's 10000 nits.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Crashes: the render-target heap (HeapDef DynamicTextureAllocatorMem and its parent) grows with the widescreen
picture, so the pause menu no longer reads a null block at 5120x2160; texture uploads keep the game's memory mapped
while they copy it, so UnmapPhysicalMemory no longer pulls it away mid-copy; DLSS Frame Generation no longer crashes
in Streamline's set-up (physical devices and the window surface go through its proxies, its swapchain images are
counted first, resources are tagged per frame); a stale core-wait target is cleared before its thread is freed.
Freezes and races: a resize during a swapchain rebuild is kept, a failed frame generation swapchain is retried
instead of replaced by a plain one, three acquire timeouts in a row rebuild the swapchain, device waits take the
queue lock, a translator child that stops answering times out, an in-flight compute pipeline builds at normal
priority, a save Commit started before the window closes finishes and none starts after, a settings change just
before closing is saved, and a movie sample taken before a flush is dropped.
HDR: Enhanced HDR extends the game's own tonemap so highlights go above the picture's white (the hue slider,
which no longer applies, is gone from the menu); frame generation gets a HUD-less picture, the HDR flag and the HDR10
metadata under HDR too.
Memory: ASTC textures are encoded to BC3 unless the PC has 20 GiB of VRAM and 48 GiB of RAM, as Windows charges video
memory to the commit charge (a long session held 17 GiB of RGBA8 textures and 45.7 GiB of commit on a 32 GiB PC).
Shaders: the translator lowers spill-mode programs with more than eight uniform register groups in a wider spill
layout, and local loads and stores with a uniform-register address (36029 of the game's 36031 variants translate,
20 failed before).
The launcher release ships the shader tools and AMD's FidelityFX library (make_launcher.py --ffx); windres there gets
the toolchain on PATH.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The game sizes its scene each frame from a GPU-time controller. The new patch set res_fixed takes the controller's
fixed path and reads the scale from the patch page, so DLSS Quality, Balanced, Performance and Ultra Performance
render at 67, 58, 50 and 33 percent of the picture and DLAA at all of it. The set goes on once the controller has run
for a few frames, and the menu's Upscaling choice lists the modes and switches them live.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
NX2NAVI_GAME_RES (1440, 1800, 2160, 2880 or window, read at start) sets the picture's height; the widescreen patch
sets now also run at 16:9 when the height is not the game's, with the width following the shape and the scene 3/4 of
both as the game draws it. Measured at 2160p with 21:9: a 5120x2160 picture and a 3840x1620 scene at 60 fps.
The Screen tab's Scaling-to-the-window row and the DLSS rows become one Upscaling row (Bilinear, AMD FSR 1, NVIDIA
DLSS) over NX2NAVI_UPSCALER and NX2NAVI_DLAA (option_rows: opt_choice_index and opt_apply for a row over several
settings), with the FSR strength greyed out unless FSR is chosen and a Resolution row beside the widescreen one. DLSS
always uses NVIDIA's model for its scale (no model row). There are no DLSS quality modes: the game sizes its scene
from the picture by its own 3/4 share, and writing a smaller scene into wide_scene's constant left the light target
as it was, so every mode would render the same.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The patch sets of recomp/patches-v111.txt read the game's 2560x1440 picture and 1920x1080 scene sizes from the patch page, give every 16:9 camera the picture's ratio, squeeze the UI's full-screen projection into the middle 16:9 (fades and the menu backgrounds that redraw a capture stay full width) and pillarbox movies. runtime/widescreen.c sets them up from the new Screen tab row Widescreen (NX2NAVI_GAME_ASPECT: 16:9, window, 21:9 or 32:9, at the next start).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
