tangerineturtle1/NX2navi v0.9.0

NX2navi 0.9.0

on GitHub

Install or update

• Already have 0.6.0 or newer: start the launcher; it offers 0.9.0, updates itself and keeps the game it compiled
  and the shaders it prepared. Only what changed is compiled again. This version has a new shader translator: the
  shaders you have carry over and are used as they are, and the game translates them again in the background while you
  play, at a low priority. Until that is done (several minutes of play after the update) the frame rate can be a little
  lower; it is a one-time cost.
• 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.0.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.

Faster

• Stutter while running through open areas. To skip memory the game has not written for a while when it looks
  for changes each frame, the runtime write-protects it in 2 MiB pieces, and the game's first write takes the
  protection off again. The buffers the game streams the next stretch of ground into were protected again as soon as
  they had been idle a moment and written again moments later: running from the Kakariko Village gate across Hyrule
  Field did that some 30,000 times in nine minutes, and while the game streamed, each time took Windows 15 to 20 ms,
  with the game waiting. A piece the game writes again soon after it was protected is now left alone for a while,
  longer each time, a piece is protected only after 1,800 frames without a write, and taking the protection off no
  longer holds up the game's other threads while Windows does it. On that run: no frame over 100 ms while running
  where there had been 29 to 52 a minute, the slowest 1 % of frames at about 20 fps instead of 7 to 9, and standing at
  the edge of Lake Hylia afterwards 60 fps instead of 38.
• The compute shaders the game used last time are ready first. At start the pipelines of the compute shaders the
  game dispatched most recently are built on two threads, and the rest on one thread in the background, so the game
  keeps more of the CPU while it plays. Measured by automata-rtx (pull request #637) on an RTX 4080 SUPER: Castle Town
  76.1 instead of 73.7 fps with 1 frame over 25 ms instead of 6, Hyrule Field 85.7 instead of 80.7 fps.
• Fewer textures dropped and made again when the PC's memory runs low. When most of what the drops would free is
  made again within seconds, the drops pause for a while instead of churning.
• ASTC texture decoding keeps its scratch memory between uploads and stages its blocks in the shared staging
  memory, so an area's textures decode with fewer allocations.
• The mesh shader fallback (GPUs without mesh shaders) prepares its programs on up to four threads instead of one:
  on a cold start 956 draws were skipped while they waited instead of 3,266, and the slowest 1 % of frames ran at 56
  instead of 16 fps.
• When the video memory runs out, the runtime gives back the staging and snapshot memory it keeps and its spare
  blocks, and tries the allocation again, instead of failing it.
• Less video memory for the game's textures, with the same picture. On cards that get the game's ASTC textures as
  BC3 (all with less than 20 GB, and larger ones on PCs with less than 48 GB of memory), a texture none of whose texels
  is see-through is now BC1, half the size: BC1 holds exactly the colour half of the BC3 blocks it replaces, so every
  texel is the same as before. About a third of the game's ASTC textures are, and in Hyrule Field after a seven-minute
  teleport tour through five areas the ASTC textures took 2.5 instead of 3.0 GB, the game's video memory at its peak
  11.5 instead of 12.1 GB and its commit at its peak 24.9 instead of 25.5 GB (Windows counts video memory in the
  commit too). A texture's first upload checks its blocks while it copies them, and a large texture's copy now runs on
  several threads: the tour's first 7,200 frames, its area loads, took 94 instead of 101 seconds, and its slowest 1 %
  of frames ran at 24 instead of 21 fps. astc_bc1 = 0 in nx2navi.ini keeps every ASTC texture BC3.
• Diagnostics stay out of the way. Everything that only measures or logs for bug reports is off unless switched on
  in nx2navi.ini; the long-wait watch of the game's threads is now off too (wait_watch_s = 10 turns it on).

New

• One Anti-aliasing setting: the game's own SMAA, off, FXAA, SMAA at its Ultra preset, or TAA.
• Direct mouse camera on game 1.1.1: the camera takes the mouse's own movement after the stick's dead zone.
  Contributed by Gaetarra (pull request #462).
• HDR, two ways: one fixed tone-mapped look with true blacks (its on switch and the three whites are its only
  settings), or Native, the game's own HDR picture as it is.
• Experimental: the draw replay on several CPU cores (replay_workers = 3 in nx2navi.ini, off by default;
  contributed by epicmeme546). It records a frame's large groups of draws on several threads; on an RX 7900 XT in
  Hyrule Field it gave 51.7 instead of 43.6 fps standing. Its pictures are not yet proven right across the whole game:
  leave it off to play, and report what you see if you try it.

Fixed

• DLSS Frame Generation and FSR were given a fixed depth range. They now get the scene's own near and far planes,
  field of view and units, as the generated frames need.
• DLSS and DLAA jitter now covers the shading drawn against the copied depth, as the rest of the scene, and
  textures get the -1 texture LOD bias NVIDIA asks for while DLSS or FSR jitters the picture.
• Movies out of step with their sound above 60 fps: a movie shows one frame per game update and the pacer holds
  the movie's speed, at any frame rate. The movie after the Gohma fight no longer shows frozen coloured stripes.
• The time of day ran slow. The game cut each frame's step of its clock to whole seconds: at 60 fps the day ran
  about 12 % slow, and above 120 fps much slower. The fraction now carries from frame to frame, so the day keeps the
  game's own pace at any frame rate.
• Held buttons repeated at the wrong rate at frame rates other than 60: the engine's second time step follows the
  display too.
• The pipeline cache was not saved when the game was closed while shaders were still being built, also with the
  normal Quit, so those shaders were built again at the next start. New builds now wait while the cache is saved at
  exit, on every GPU. Found by automata-rtx (pull request #638).
• Effects drawn by mesh programs: a mesh program's whole buffer is cleared before it runs, outputs the program does
  not write get the console's defaults, and fragment inputs it does not write are filled, so they no longer show what
  an earlier draw left behind.
• Shader translation: compute programs get the local memory they ask for, the translator's compare-and-swap loops
  can no longer spin without end, and 64- and 128-bit loads and stores count every register they use.
• Kakariko Village's haze dropping out for a frame, leaving darker, hard-edged clear patches, a few times a minute.
  The game moves about 30 of the village's textures to new addresses every four or five frames and lets go of the old
  ones before the frames that still draw with them have been drawn; those draws got blank stand-ins. They now sample
  the texture's own image as long as it still holds the texture, and textures the game lets go of and takes back are
  kept as long as their longest absence (tex_stale_kept = 0 and tex_keep_taken = 0 turn each off).
• A texture a shader reads as a 3D one but the game made flat gets a one-slice 3D copy instead of a blank
  stand-in.
• The post pass's picture shows when it writes RGB9E5 texels, in the upscaler's stand-in too.
• A graphics pipeline the driver refuses is built again without the driver's optimiser instead of being dropped.
• Ground that vanished in open areas, leaving a view into the void below. The game streams the terrain's height
  maps through a fixed set of memory and sets up the next piece of ground there before it lets go of the one before; the
  runtime took that letting go for the new piece too, and the piece was drawn at height zero, far below the ground. Seen
  after some minutes of running in Hyrule Field, and in Kokiri Forest, Kakariko Village and the Graveyard. Found and
  fixed by MartinIsla (pull request #535).
• Ground flickering white on PCs with 16 GB of memory. Past a bound on the game's own memory, textures gave way one
  after the other, although dropping them could never bring the game back under that bound: the bound leaves the video
  memory out, and a dropped texture lowers both sides alike. Textures now give way only when the system's memory is
  really running low (tex_proc_commit_mb only writes a line into the log now).
• Stutter and textures missing for a moment on cards with 8 to 12 GB. The game lets go of textures and takes them
  back within frames, hundreds a frame in towns. Above 80 % of the card's memory those were dropped, only to be made and
  uploaded again a moment later. Only textures that stayed let go of for two seconds, and that nothing looked up since,
  are dropped now: on a seven-minute teleport tour with an 8 GB card's budget, a fifth fewer textures made again, a
  third less time the game waited on textures, and in Hyrule Field afterwards the slowest 1 % of frames at 32 fps
  instead of 22. Render targets the game lets go of are kept up to a hard limit, so they come back with their content
  (ordinarybob, pull request #570).
• A texture the GPU drew is written back to the game's memory before it is dropped, as the end of its frame would
  have done.
• AMD FSR 4 turning into FSR 3.1 by itself. Each upscaling mode made an FSR 4 context of its own (about 220 MB of
  video memory each), and three creations that failed in a row, as they can while a save loads, turned FSR 4 off until
  the game was restarted. Now one context per output size serves every mode, contexts nothing used for 90 seconds go,
  a creation that fails frees the others and tries again two seconds later, and choosing FSR 4 in the menu again tries
  it anew.
• A gamepad axis that reports a value from the start (a virtual pad nobody holds, a trigger mapped onto a stick, a
  stick resting far off its middle) no longer turns the camera or moves Link on its own, or takes the gamepad role
  from the controller in your hands: an axis counts once it has been seen at rest. Ctrl, Shift or Alt with F11 is
  left to overlays.
• Robustness: texture sizes are worked out in 64 bits, so a damaged texture description cannot wrap to a small
  size; NVN queries on a missing object answer 0; a buffer without a memory pool gets memory of its own.
• CPUs with two dies of different cache sizes: the game keeps to the large-cache die only when it has 8 cores.
• Debug menu: a teleport always goes to one of the area's own start positions, and the free camera no longer goes
  under the map.

Changed

• One Resolution row instead of Window size and Resolution. Each choice is a size in your game's shape (with 21:9:
  2560 x 1080, 3440 x 1440, 4300 x 1800 and up) and sets both the picture's size and the window outside fullscreen,
  which takes it at once, within your monitor; the picture changes after a restart, as before. Native draws at the
  window's size and leaves the window as it is.
• FSR 4 is named by the version your driver runs: AMD FSR 4.1 Native AA and so on with AMD's current drivers.
• Texture filtering of the game's surface textures is 16x by default; Game in the Texture filtering row keeps
  the game's own.
• Linux: Mesa's shader cache beside the game may grow to 8 GB instead of 1 GB, and on drivers without graphics
  pipeline libraries every pipeline of the shipped list is prepared ahead.
• The launcher's docs say that downloads follow the PC's HTTP proxy (KevinParnell, pull request #572).

Known issues

• A rare one-frame flicker of shadows or lighting, on grass and objects, is still being looked into. It happens at any
  frame rate.
• 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 while the graphics driver builds what it has not seen.
• 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 automata-rtx, MartinIsla, Gaetarra, ordinarybob, KevinParnell 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.