tangerineturtle1/NX2navi v0.9.1

NX2navi 0.9.1

on GitHub

Install or update

• Already have 0.6.0 or newer: start the launcher; it offers 0.9.1, updates itself and keeps the game it compiled
  and the shaders it prepared. Only what changed is compiled again. The update then builds the graphics pipelines of
  this release's list into your driver's cache once, about a minute on a fast card; the row Prepare the Shaders
  shows it.
• Already have 0.5.0: the same, and the game's code 0.5.0 compiled is kept as it was compiled (for any x86-64
  processor); Rebuild the Game in the launcher's home compiles it again for yours.
• New install: download NX2navi-Setup-0.9.1.exe below, put it next to your .nup dump of the game and start
  it. Windows SmartScreen warns on the first start because the setup is not signed: choose More info and Run
  anyway. The launcher checks your game files, builds the game (10 to 25 minutes, once), prepares every shader and
  starts it.

Requirements: Windows 10 or 11; an x86-64 CPU with SSE4.2; 16 GB of RAM; about 30 GB free for the game and 1.5 GB
for the launcher; a GPU with Vulkan 1.3 and VK_EXT_external_memory_host (current NVIDIA and AMD cards). A GPU without
VK_EXT_mesh_shader gets the mesh shader fallback, untested on such a card.

New

• Mods in the launcher. Mods, on the launcher's home screen, opens the mods folder and adds a mod you downloaded,
  as its .zip, .7z or .rar file or its folder; one put into the mods folder by hand works as well. Before the game
  starts, the launcher unpacks archives and moves a mod's files to where the game looks for them when they sit a folder
  or two down. Each mod has an On/Off switch and says what it changes, which other mod changes the same files and
  which of them wins, and why the game cannot use it when it cannot; Load Order sets which mod wins. A mod with code
  patches or code cheats is built into the game before it starts, which takes a few minutes the first time: the
  launcher's own build left those out until now.

Faster

• A new install no longer builds its pipelines while you play. A release now carries a list of the graphics
  pipelines the game is known to draw, 8,849 of them in this one. The install builds all of them while it prepares the
  shaders, and every start builds them before play, as it already did for the pipelines your own install had drawn.
  Before, a new install met each pipeline in play first: in Hyrule Field one ten-second stretch of a first visit had
  1,769 draws wait for their pipelines, 461 ms in all, the longest frame 88 ms. In a first walk through Kakariko
  Village on fresh caches no draw waited for a pipeline with the list, where 634 pipelines were missed without it, and
  the first minute had 10 frames over 25 ms instead of 137. pipe_seed = 0 in nx2navi.ini leaves the list out.
• Less waiting for a pipeline the list does not have. Such a pipeline is linked from the shader libraries the
  install prepared, and its draws waited 3 ms for that in every frame until it was there. The 3 ms are now counted
  once for each pipeline, from the first draw that needed it, and a frame that has already left a draw out waits for
  nothing more: a pipeline the driver has to compile costs one frame the wait and the frames after it nothing.
  pipe_link_draw_ms and pipe_link_ms set longer waits, which leave fewer draws out of a frame and make that frame
  longer.
• Compute shader variants are prepared too. The list now carries the 629 compute shader variants met in play. No
  pipeline record names a compute shader, so a variant the shader list lacked was translated on the frame that first
  used it, 30 and 38 ms in two frames of one first-visit session. Fourteen of the list's variants are of shaders the
  preparation does not read from the game yet, three of that session's four among them: those are still translated at
  first use.
• The draw replay runs on several CPU cores by default (replay_workers = 3; contributed by epicmeme546): a
  frame's large groups of draws are recorded on three threads beside the one that submits them. On an RX 7900 XT in
  Hyrule Field it gave 51.7 instead of 43.6 fps standing. replay_workers = 0 records on one thread as before; try
  it if a picture looks wrong, and please report it.
• No CPU core is set aside for the recording thread any more (recorder_core = 0 is the default now). On an
  i9-14900KF the reserved core left the replay thread waiting about 200 ms roughly once a second in Kakariko: 27 frames
  a minute took 150 ms or longer, none without it. recorder_core = auto reserves one as before. Found by
  TheShinySylveon (pull request #625).

Fixed

• Part of the scene black for a frame. The game's per-frame render targets share memory, and a texture slot whose
  own image was let go of could follow a target of another size laid out at the same place: the pass that writes the
  half-size lighting term and the pass that reads it both got the wrong image, the term read as zero, and a jump
  attack's hit effect drew the right 44 % of the scene black. A slot now follows only a texture of its own size. By
  bct8925 (pull request #647).
• Bright white specks on distant surfaces at night. The 1x1 stand-in a material samples while its texture is not
  there yet was never cleared, so a roughness map read through it could be near zero: on Kakariko's distant cliffs the
  highlight reached 3392 in single pixels, which bloom and the temporal upscaler spread into white spots. Stand-ins
  are mid grey now, and those shaders write to start at zero. By Leyukaka (pull request #634).
• Textures blinking black for a moment in Castle Town on cards with much video memory. The textures the game lets
  go of were swept from 2,048 on, whatever the card; the limit now follows the card's video memory budget, up to
  8,192. On an RTX 5060 Ti 16 GB the sweep had dropped 412 in a session and a few textures blinked; with the higher
  limit it dropped none. By schoperena (pull request #616).
• With DLSS, the minimap showing the game's picture behind its room shapes after a room change or the pause menu:
  the game's 2000x2000 area map was taken for the picture DLSS writes to. Only a pass of the scene's shape is taken
  now. By bct8925 (pull request #648).
• DLSS and frame generation carried their history across a camera cut. An area load or a spawn moves the camera
  5 to 180 m in one frame; such a frame now starts a new history, and frame generation is told of every new start, so
  it no longer makes frames between two unrelated pictures. dlaa_cut = 0 turns the camera test off. By bct8925
  (pull request #651).
• Water drawn as a rectangle over solid ground at the Hyrule Castle moat and the Castle Town canal, and a red beam
  there (issue #398). The water's shader worked out each corner's place on the screen and blended that across the
  surface, which goes wrong as soon as a corner of the surface is behind the camera; its place is now worked out per
  pixel. The distance through the water that dims what lies under it can no longer be negative, which had turned the
  dimming into a gain. Found and corrected by ChurchOfIlias (pull request #666); the game applies the correction to
  those two shaders itself. water_projective = 0 in nx2navi.ini leaves them as they are. The correction was compared
  byte for byte on an NVIDIA card; on AMD it runs the same steps on AMD's translation of the shaders and was not run by
  us. Why the distance comes out negative is not known yet.
• The launcher run from the source with an older Python stopped at Gather Build Tools with nothing but "No
  module named 'zstandard'". It now says so on its first screen, with the command that installs what is missing.
• A flickering light line along the bottom and right edges of the picture with FSR 4, FSR 3.1 or DLSS. To let the
  upscaler build a smoother picture, the scene is drawn moved by a fraction of a pixel, a little differently each frame.
  When it moved up or to the left, AMD's driver left the last row or column of the scene undrawn, the fog's colour stayed
  there, and the upscaler blended it into the edge. That row or column is now filled from the one next to it before the
  upscaler reads the scene.

Changed

• The Anti-aliasing setting works with FSR 4, FSR 3.1 and DLSS. Choosing Game SMAA, Off, FXAA or SMAA (Ultra) with
  one of them on under Upscaling used to switch the upscaler off and leave the picture to bilinear scaling. Now the
  upscaler stays, its TAA keeps running, and the chosen pass runs along with it (the row says "plus TAA from
  Upscaling"): Off leaves the edges to the TAA alone, SMAA (Ultra) smooths what the TAA leaves. Picking FSR or DLSS
  under Upscaling keeps the Anti-aliasing choice too, and the row's TAA entry now sets FSR 4 where it runs, no longer
  FSR 3.1 in its place.
• The performance overlay shows the anti-aliasing under Upscaling, as TAA + SMAA (Ultra) and the like while FSR
  or DLSS runs.

Known issues

• A rare one-frame flicker of shadows or lighting, on grass and objects, may remain; the fix for the black part of the
  scene above removes one cause of it. Please report where you still see it.
• FSR 4, its frame generation, the AMD-only fixes and the mesh shader fallback were not run by us on the cards they
  are for before this release. Please report how they behave.
• The first visit to an area after an install can still pause for a moment while its textures are decoded.
• Integrated AMD GPUs can fail at the title screen (their host memory heap is too small for the game's memory).
• Nothing in this release was run on Linux by us.

Thanks

Pull requests in this release came from bct8925, Leyukaka, schoperena, TheShinySylveon, ChurchOfIlias and
epicmeme546. Thanks to everyone who sent logs, captures and test reports.

Report problems as issues, with the game's log (logs\nx2navi.log in the game folder) and what you were doing; Export
Save with the bug report box ticked packs the log, your settings and your save into one zip.

NX2navi is an independent, non-commercial fan project, not affiliated with or endorsed by Nintendo. The Legend of
Zelda, Ocarina of Time and Nintendo Switch are trademarks of Nintendo.