The heap bound in scene_for counts the output's own growth against the 2 GiB limit, so a 7680x4320 output at
render_scale game went from the 4096x2304 scene dev renders to 2712x1526, with no setting changed. The bound now
shrinks no scene below 4096 a side, the size dev gave; scenes the 4096 cap kept smaller still grow up to the bound.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With dynamic_res at 0 by default the fixres set held the scene at 100 % for every player, the reason #573 was turned
down. The default is now 1, so the set stays off unless a player turns dynamic resolution off in the menu or
totk.ini, and the Steam Deck profile no longer needs its own entry.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.4.3 scales the scene size it reads from the patch page by canvas width over the console mode's base width, which is
1280 in handheld, not 1920. A handheld 1280x720 output at render_scale 100 put 1920x1080 on the page, so the game
rendered a 1920x1080 scene while the DynamicTextureAllocator heap was sized for 1280x720, and heavy scenes ran it out
(crash at main+0x1c2590). scene_scale now uses the mode's base for res_init and res_dlss_mode. In handheld the game
composes a 1280x720 canvas unless the output patch is on, so the output patch is switched on with the scene patch there
and the canvas is the output the factor and the heap assume. Docked is unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The game picks a scene tier of 100, 90 or 80 % mostly from a fixed cost model made for the Switch that grows with the
scene width squared, so on a wide output it drops to 80 % on any GPU: at 5120x1440 every frame drew 80 % of the scene.
Patch set fixres replaces the one instruction that moves the tier's scale into the controller's result (1.2.1
main+0xcc2c00, 1.4.3 main+0x5848a8 as MacNativeGames patches it) with 1.0. The new setting dynamic_res (menu toggle,
live) brings the game's stepping back and is on by default in the Steam Deck profile.
The scene cap goes from 4096 to 8192 a side, so render_scale above 80 works on a 32:9 output, and the scene also stays
within a DynamicTextureAllocatorMem under 2 GiB; the log says when it was made smaller. The memory selftest now maps
past the real pool size instead of a fixed 4 GiB, which a larger scene grows past.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
df9ba65 keeps a content mod's heap sizes when its table is the one served, that
is when the mod is above the texture pack. With the pack on top (HDPacks.com's
4kTextures sorts first), the pack's table was still swapped for the game's own,
and The Second Quest's larger RSDB and UI heaps were lost: the game crashed at
start writing to address 0 in main+0x1d4200. heapdef_overlay now grows the
table of the highest switched-on mod that changes other heaps only, and falls
back to the game's own table when no mod has one.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
heapdef_overlay replaced the served mod table whenever any switched-on mod grew the texture heap. With an HD pack and
another mod that ships a HeapDef for other heaps on top of it, the other mod's sizes were lost. It now checks the
served table itself (resolution.c res_heapdef_tex_grown): only a table with TextureHeap over the shipped size is
swapped, any other stays the base and gets the growth on top.
A mod HeapDef the port cannot read no longer logs "TextureHeap 0 KiB": the failure is logged with the mod's name.
read_original sat between read_served and its comment; each function has its own comment again.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
HD texture packs made for the emulators ship their own HeapDef with TextureHeap and its parent grown for the
emulators' 8 GB memory option (HDPacks.com's 4K pack: by 3,419,000 KiB). Served as it is, the game asked for room the
application pool does not have and crashed at start (#673); without the file it looped the panic Blood Moon.
Before mem_init sizes the pool, resolution.c reads the HeapDef of every switched-on mod (mods.c mods_peek_romfs, which
lists the mods' RomFS roots without the rest of the scan: mods_scan needs paths main sets later) and counts the largest
TextureHeap growth over the shipped 506,880 KiB like TOTK_TEX_HEAP_EXTRA_MB (the larger of the two, at most 4 GiB). The
pool and the heap cap grow by it, and romfs.c heapdef_overlay serves the game's own table grown by that amount in the
mod's place, so the other heaps keep the sizes of the game version that runs.
Tested with the HDPacks.com 4K Texture Pack v1.0 as players install it, on 1.4.3 and 1.2.1 (RTX 4080 SUPER): the game
loads a save and runs at 60 fps with 0 validation errors, and holds 4.5 GB of game memory pools against 1.2 GB without
the pack. docs/mods.md, README.md and totk.ini.example say so; other packs come with no guarantee.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
HD texture packs made for emulators with 8 GB of DRAM, such as the HDPacks 4K pack, grow "TextureHeap" in their own
HeapDef table. Served as a mod, that table replaces the one the port grows for the resolution and the shadow map, and
the game crashes at boot; without it the pack's textures do not fit, and the game loads and then starts its panic
Blood Moon over and over.
tex_heap_extra_mb ([mods], 0 to 4096 MiB, read at start) grows TextureHeap and its parent ゲームグラフィックス in the
port's HeapDef, and the application pool and the heap cap by the same amount. LOW_SIZE goes from 6 to 10 GiB so the
stack and heap block holds the largest heap. At 0 the pool, the heap cap and the HeapDef are what they were.
The selftest's "beyond the pool" MapPhysicalMemory asked for 4 GiB, which a grown pool holds; it now asks for just
past the pool.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A game resolution that is not 16:9 widened the camera while the HUD stayed at 16:9 stretched across the picture whenever romfs-patches-<w>x<h> was not next to romfs-index.bin, which is always so for a build from source. resolution.c now falls back to the largest 16:9 size inside the asked one and keeps the camera aspect patch off, logging the command that makes the layout. build_game.py copies every romfs-patches* folder with a manifest.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Merged on top of #566 and #594, by hand in vk_dlaa.c:
- One dlss_preset key: default keeps #594's model per mode (K for DLAA, Quality and Balanced, M for Performance, L
for Ultra Performance); k, j or any other letter a..m takes that model in every mode, live, recreating the features
as #534 does. The menu texts say so, with pt-BR and zh-Hans added.
- The mask pass stays on #594's camera motion (the identity and the CPU-made reprojection in dlaa_mv.comp's two
blocks) and adds #534's outputs; it runs before the per-object pass. Where the reactive mask test
(TOTK_DLSS_REACTIVE) ran, DLSS gets that mask instead of the characters'.
- #566 dropped the scaler_skipped/scaler_missed report, so #534's reset of it goes too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The scene patch, the heap sized for the largest DLSS scene and the function-entry hook that catches the game's render
size setup were on for every 1.4.3 player; they are on now only when DLSS can run (dlaa = 1, nvngx_dlss.dll there),
and the hook gives up after 1800 presents if the setup is never seen. Everyone else keeps the game's own scene size
and dynamic resolution, as before #594.
The uniform snapshot's second copy in host memory and the per-object motion's last-frame blocks are made only while
DLSS is available: without it nothing reads them, and the snapshot goes into the device copy in one pass as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Solid scene draws whose position reads an object's own uniform blocks (bones c5, place c7, c6) are drawn a second time
with a vertex shader variant (translator patch 0012) that computes last frame's position from last frame's blocks; the
game writes those into two copies that take turns, and the uniform snapshot keeps both (vk_mvprev.c). The draws are
listed during the replay and recorded through the recorder thread with repeated state skipped. Blocks whose last-frame
copies measured wrong (c9 and c11 of walls and cliffs) keep this frame's; positions without an object block (terrain,
grass) keep the camera's motion, which measured as good.
The camera motion is reprojected in double precision on the CPU: the float inverse made noise on far surfaces and a
still camera that DLSS followed into a wobble. DLSS gets Ultra Performance (a third of the output, also in the F1 menu)
and NVIDIA's recommended preset per mode (K, M for Performance, L for Ultra Performance; TOTK_DLSS_PRESET overrides).
Test switches: TOTK_MV_CHECK measures the motion vectors and DLSS's output against the picture, TOTK_DLAA_TIMES times
DLSS and the motion passes on the GPU. A reactive mask pass for transparents is included but off (TOTK_DLSS_REACTIVE):
its mask covers sky and fog too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.4.3 sets its render size once, at start (main+0x7000e67028 calls
main+0x585bd0(renderer, force)). The function-entry hook catches that call's
renderer, and a TOTK_DLSS change writes the new scene size to the patch page and
has the next nvnQueuePresentTexture call the setup again with force set, on the
game's thread between frames, with the guest registers kept. The heap is sized
for the largest scene a mode asks for. The DLSS texture bias is part of the
sampler cache key and follows the mode and the dlaa switch. The game's scaling
pass is told from the in-place FXAA by its missing depth attachment, not by the
sizes, which change a frame ahead of the drawing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
vk_dlaa.c reached the NGX core only through Windows: the registry, LoadLibraryA and GetModuleFileNameW. On Linux the
NVIDIA driver installs the core as libnvidia-ngx.so.1 with the same Vulkan entry points; it is opened with plat_lib_open.
The parameter object's vtable follows the Itanium C++ ABI there, each overload group in declaration order rather than
MSVC's reverse order, so the slot enum has a Linux variant; vtable_ok confirms it at start. NGX gets the executable's
folder as a 32-bit wchar_t string, converted from UTF-8 without the C locale, and loads libnvidia-ngx-dlss.so.<version>
from there. The Windows path is unchanged.
resolution.c sized the scene for a DLSS mode only on Windows, where it looks for nvngx_dlss.dll; on Linux it now looks
for libnvidia-ngx-dlss.so.<version> next to totk, so quality, balanced and performance work there too. The no-op
stubs vk_dlaa.c had for other platforms go, as Linux now builds the real code.
The DLSS modes already apply only with dlaa on (3de0839), so the DLL check no longer looks at dlaa, and off Windows,
where vk_dlaa.c is no-op stubs, a DLSS mode no longer shrinks the scene. fxaa = 0 names the FXAA shader it skipped,
or reports a minute of frames without it, so a translator change that moves FXAA_FS shows on any GPU.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A DLSS mode (quality, balanced, performance) shrank the scene to 67, 58 or 50 % of the output and sharpened the
material textures' mip bias to match, even when nvngx_dlss.dll was missing and NGX reported DLSS as not available.
The game's plain scaling then stretched the smaller scene, and the negative bias made textures shimmer in motion.
With dlaa = 1 the scene size now waits on nvngx_dlss.dll next to totk.exe (checked before the device exists, as
the size is decided then) and follows render_scale without it. The mip bias applies only when NGX came up with
DLSS. dlaa = 0 keeps the documented size with the game's scaling, without the bias.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With dlaa = 0 and dlss = quality left from the menu, the scene still rendered at 67 % and the plain upscaler
stretched it, so the picture looked blurrier with DLSS switched off.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The sampler keeps both the DLSS mip bias and pull request #321's anisotropic level; DLAA's pass hook runs after the
contact shadows'; the extension arrays grow for NGX's extensions beside HDR's and the calibrated timestamps.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Keeps pull request #321's anisotropic filtering, which #89 added a second time, and #267's shadow_res beside #89's
shadow_scale. The HDR parameters move from byte 1408 of the support buffer to 1440: translator patches 0010 and 0011
read pcss at 1408 and shadow_spread at 1424.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each frame the engine sizes its shadow cascades to the area they cover (main+0xcebdf4 in 1.2.1): from 960 down to about
400 near the ground, so leaf shadows turn coarse, and every change of size moves the shadow texels, so they jump instead
of sliding. The Switch does the same; the community mods force a fixed size. The shadow patch set loads the size from
patch page +92 just before the engine rounds it (main+0xcec22c in 1.2.1, 0x683604 in 1.4.3), and the menu's Shadow map size
(shadow_res in totk.ini) chooses it: game, 512, 768, 1024 (default), 1536 or 2048, with the texture heap grown above 960. A write
watch on the size field found the one writer; with the setting, every shadow map in both versions is the fixed size.
recomp/patches.py lists the patch page words in use.
Conflicts: the known-key and section lists in cfg.c keep both sides; vk_backend.c, vk_device.c and vk_exec_draw.c include platform.h and vk_dlaa.h; create_instance takes the window's instance extensions from gfx_window_vk_extensions as on main, in a 12-entry array for NGX's.
The camera update and setup routines that the aspect set patches load the camera's vertical view angle a few words
before the ratio and pass it to sead's perspective projection. The new set fov loads the angle as before and multiplies
it by a factor the runtime writes to patch page +60, so TOTK_FOV (70..140 percent, menu Screen tab, live) widens or
narrows the view. The game's own zooms (bow, scope) scale with it; 100 switches the set off.
Checked on 1.4.3 at 1920x1080 at 70, 100, 130 and 140: the view narrows and widens around Link, the HUD is unchanged,
no objects appear or vanish at the edges, no validation errors. 1.2.1 has no fov sites yet (its original words are
unverified here); the setting logs that and does nothing there.
Merged with applezra's follow-ups on the same branch: the sun shadow filter narrowed by the shadow map scale
(translator patch 0011), anisotropic filtering forced only on tiling samplers, and TOTK_DUMP_UBO with a vec4 count.
Conflicts with dev: cfg.c (names, display section, defaults next to aspect and device_profile), menu.cpp (the new rows
after the aspect row), vk_texture.c (the pool alias check takes scale == 1 and dev's bind_pool_memory size argument),
build_xlate.py (patches 0005-0011 are ours; the Linux note kept), totk.ini.example (both sections). The contact pass
release went into gfx_present.c, the shared half of the old gfx_window.c.
aniso defaults to game: the picture stays as before until a player raises it in the menu.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
patches-v121.txt takes the aspect set at upstream's 1.2.1 sites (game_patches.c aspect_install): the same two camera
loads and two viewport divisions as 1.4.3, with the same original words and the same replacement from page +56. The
installer now builds the romfs-patches-<w>x<h> overlays for 1.2.1 too; ultrawide_layout.py passes on its
Common.Product.110 at all ten sizes. Checked in game at 3440x1440 (camera 2.3889) and 1920x1200 (1.6000): wider or
taller view, HUD at the corners or edges, no validation errors.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TOTK_DLSS (dlaa|quality|balanced|performance, read at start) sets the scene to
67, 58 or 50 % of the output. DLSS then runs at the begin of the game's scaling
pass (the FXAA shader drawing the light target into the output-sized target,
before the HUD) and its result replaces that draw; the HUD is drawn afterwards
and never jittered or passed through DLSS. The jitter now ends where the scene
ends (the bloom), separately from where DLSS runs. Scaled modes add a mip bias
of log2(scale) to repeating, mipmapped material samplers.
With a scene smaller than the output, fxaa = 0 no longer skips the game's
scaling draw (it left the 3D picture out).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.2.1 has no camera aspect patch, so the installer no longer builds romfs-patches-<w>x<h> for it (the layout tool is checked against 1.4.3 and could fail the whole install), and romfs.c overlay_init skips that overlay on 1.2.1 through res_wants_wide_overlay. overlay_init and res_init now both call res_is_16x9 (1% tolerance), so 1366x768 counts as 16:9 and logs no missing overlay.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An output_res such as 3440x1440 now widens the camera's view to that shape on 1.4.3: patches-v143.txt
sets the aspect ratio at the camera and viewport sites that hand it to the perspective projection.
The HUD and menus come from a romfs-patches-<w>x<h> overlay that make_romfs_patches.py --aspect
builds through tools/ultrawide_layout.py, and romfs.c overlay_init picks that overlay when the game
resolution is not 16:9. The installer prepares it for 2560x1080, 3440x1440, 3840x1600 and 5120x2160.
When the window's shape differs from the game resolution's, the new aspect setting keeps the
picture's shape with black bars (fit, the default) or stretches it over the window.
The sun's shadow cascades end at 20, 40, 80 and 160 m: the depth shadow parameter object (main+0x6fa3c0) registers
depth_shadow_near_0_1..3 and depth_shadow_far_0 as immediates, and the field's .bgsdw files do not override them. The
new cascade patch set reads the four distances from patch page +64..+76 instead, and shadow_range (percent, 50 to 400,
default 100) writes them there at start, so the visible steps where shadows turn softer move away from the player. It
spreads the shadow map over more ground, which shadow_scale pays back. Only patches-v143.txt has the set; on 1.2.1 the
setting logs that and does nothing.
The setting is in totk.ini.example and on the Screen tab of the menu (English and Russian).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The left stick now moves the menu cursor as the D-pad does (ImGui only scrolled with it). The page's rows are a
direct NavFlattened child of the menu window: behind a second child level ImGui did not clip them, so up from
Continue went to the tabs and down from the tabs to Continue.
The full overlay reads temperature, board power, clock and GPU load from ADL's PM log on AMD GPUs (matched by PCI
bus), and shows the window, game image and 3D scene sizes, the scaling to the window (FSR and its sharpness), the
frame limit and the presentation mode in use.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.2.1 renders the scene size it reads, while 1.4.3 scales it by output width / 1920: on 1.2.1 the scene set is on
whenever the output grows (2560x1440 gave a 1600x900 scene before, 2133x1199 now). An output at or below the shipped
size needs no grown HeapDef. The release deps carry the static libzstd and its header, totk.ini.example the four new
keys, THIRD_PARTY_NOTICES.md the MacNativeGames sites, FSR 1 and zstd.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The output and scene patch sets make the game read its output, swapchain and scene sizes from the patch page
(MacNativeGames' sites for 1.2.1 and 1.4.3); resolution.c picks them from TOTK_OUTPUT_RES and TOTK_RENDER_SCALE and
grows the HeapDef texture heap, its parent and the application pool to match. vk_fsr.c runs AMD FSR 1 EASU and RCAS
on the present when the window is larger than the game's output (TOTK_UPSCALER, TOTK_SHARPNESS).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
