tangerineturtle1/NX2navi v0.10.2-rc4

NX2navi 0.10.2 preview 4

on GitHub

This is a preview build for testers, not a finished release. It may have new problems. The final 0.10.2 will replace it by itself.

How to get it: start the launcher, open Settings, set Update Channel to Preview, then select Updates. On the Stable channel the launcher does not offer it. To go back, set the channel to Stable; the launcher keeps your previous version.

A new install uses NX2navi-Setup-0.10.2-rc4.exe below. There is no Linux build of this preview.

New since preview 3:

• One long frame about 30 seconds into every session (55 to 82 ms) is gone.

New since preview 1 (there was no public preview 2):

• The whole scene no longer flashes for single frames with Helpers take small jobs on.
• Less video memory held in reserve: on a run through Hyrule Field, 13.2 GB in use where it was 16.7.
• Textures the game writes again with the same content are no longer decoded a second time.
• The tone mapped HDR picture has its settings back in the Screen tab.
• The low-end GPU mode is gone from the settings.
• Flashing or white foliage on cards that take the mesh shader fallback is fixed (by Tobim6).

Please report what you find in the tester chat, with nx2navi.log from game\logs.

Install or update

• Already have 0.6.0 or newer: start the launcher; it offers 0.10.2, updates itself and keeps your saves and
  settings. This update translates the game's code once more (for the ocarina recorder's fix) and prepares every shader
  again with the fixed shader translator: a few minutes, once.
• New install: download NX2navi-Setup-0.10.2.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: as for 0.10.0: 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).

Changed

• The Game tab's Testing settings keep 0.10.1's defaults: CPU helper threads Automatic
  (replay_workers = auto), Start next frame early On (tail_early = 1), and Helpers work ahead and Helpers
  take small jobs off (replay_pipe = 0, replay_small = 0). The last two stay experimental: a tester's
  measurement on an RTX 3090 found them slower at four of eight places and no more than 7 % faster at the others.
• Automatic texture detail is more careful with video memory (texture_detail = auto): Full now starts at
  cards of 12 GB (10 GB cards get Reduced, as 8 GB cards do), and integrated graphics never get Full, because
  their video memory is the PC's own memory. With a card filled to the room of an 8 GB one, a tester measured 29.6 fps
  with Full and 42.8 with Reduced on the same tour, and a handheld that got Full closed when a save was loaded.
  A texture detail you chose yourself stays as you set it.
• Less video memory held in reserve. The game lets go of textures as you move and takes a few of them back; the
  ones it let go of were kept for three minutes and could hold a quarter of the card's video memory (up to 8 GB), and
  what they held at their fullest stayed in use for the rest of the session. They are now kept for one minute and may
  hold a thirty-second of the card's video memory, 384 MB to 1 GB (tex_released_hold, tex_released_mb). Measured
  on a run through Hyrule Field at 5120x2160 with DLSS Performance on an RTX 5090: 13.2 GB in use on average where
  it was 16.7, 13.8 at most where it was 17.9, at the same frame rate. An 8 GB card keeps 384 MB of such textures
  where it kept up to 1.9 GB.
• Textures the game writes again with the same content are no longer decoded a second time. Running through
  Hyrule Field the game rewrites texture memory with the bytes it already holds; textures over 64 KB were then
  uploaded and decoded again each time, one of them 29 times in five seconds. On the same run that was 49,660 second
  uploads in three minutes, now 214, and the graphics card's upload work fell from 0.41 to 0.14 ms a frame
  (tex_same_big = 0 brings the old behaviour back for a comparison).
• The tone mapped HDR picture has its settings back in the Screen tab, under HDR output on its tone mapped
  choice (not Native) and the three brightness rows: Tone mapper and Gamma correction, then the rows of the tone
  mapper chosen, with Exposure, Highlights, Shadows, Contrast and Saturation among them. Each change shows
  at once. Left alone they give the picture HDR had from 0.9.0 to 0.10.1, true blacks included. Gamma correction now
  counts with every tone mapper; its Off shows the dark tones lighter. Lines for these settings that your
  nx2navi.ini still holds from before 0.9.0 (hdr_tonemap, hdr_exposure, hdr_gamma and the others
  nx2navi.ini.example lists) count again: remove them for the default look.

Removed

• The low-end GPU mode is gone from the settings menu's Game tab, with the rows under it: it no longer gained
  frame rate, and the mesh shader fallback now covers the cards it was written for. low_end_gpu = 1 in an existing
  nx2navi.ini does nothing, and the log says so once; the game then runs as it does for everyone else. The settings
  the mode turned on can still be set one by one in nx2navi.ini (nx2navi.ini.example lists them); a line for one of
  them that is already in your file keeps counting.

Fixed

• See-through ground (issues #569 and #824). 0.10.0 and 0.10.1 shipped an older shader translator, whose shaders
  could not reach the newest texture slots, so ground and walls could turn see-through after some play. 0.10.2 ships
  the translator built from its own sources, prepares the shaders again with it, and no longer uses translations kept
  from the old one. The release tools now refuse a translator that was not built from the release's sources.
• AMD Radeon RX 5000 and 6000 cards losing the device (the game ending with code 72): on AMD's driver these cards
  now take the mesh shader fallback by default (mesh_fallback = auto), and a lost device is noticed and reported
  sooner. Not yet confirmed by players with these cards: please report how it goes.
• Sky-coloured holes in the ground where grass is still loading, on cards that take the mesh shader fallback: a
  patch of grass or leaves is now left out whole until it is ready, where its depth alone was drawn before
  (mesh_fallback_hold = 0 brings that back). Not yet confirmed by players with these cards either.
• The game not starting after a settings change on a laptop with two graphics cards ("no usable Vulkan device",
  code 70, until nx2navi.ini was edited by hand): with DLSS Frame Generation on and the Graphics card setting on
  the card that is not NVIDIA's, the device could not be made. The game now starts on the NVIDIA card, and where
  there is none, or frame generation cannot be set up, it starts without frame generation and the log says why.
• A crash on GeForce GTX 10 cards that had the low-end GPU mode on (the game closing inside NVIDIA's driver at
  the first grass or foliage of an area, reported on a GTX 1050 Ti, a GTX 1070 and a Titan X): the mode turned on an
  older way of drawing the game's mesh shaders that this driver does not survive. NVIDIA cards without mesh shaders
  now always take the mesh shader fallback, and the mode itself is gone (see Removed).
• Flashing or white foliage on cards that take the mesh shader fallback (reported on a Radeon RX 580): the numbers
  each such draw goes by were written in an order the graphics card was free to change, and about half the draws got
  the wrong ones. Each is now written exactly once (by Tobim6).
• The whole scene flashing for single frames with Helpers take small jobs on (replay_small, with Helpers work
  ahead; the interface stayed as it was), under DLSS or FSR 3.1: a helper thread could name an earlier image of the
  frame as the scene after a later one had been named, and the upscaler then took that image for one frame. At one
  place in Kakariko with both settings as a tester had them, 51 and 52 frames flashed in two runs of 100 seconds, and
  none with the fix. Both settings stay off by default.
• One long frame about 30 seconds into every session (55 to 82 ms, the longest frame of play in the two sessions
  it was found in): the first memory report asked Windows for a summary of the game's heap, and that summary holds
  every allocation of the game while it is taken. It is now taken before play only (mem_census = 1 asks for it in
  play too, for a diagnosis).
• Crashes and hangs found in a review of the whole runtime; none was seen in our own play, and each fix has a check
  of its own:
  • a crash when the game read memory the lazy write-back was just handing to the GPU (NVIDIA and Intel cards);
  • a game thread reading a frame's record another thread had just freed, when two threads submitted at once;
  • a race between a system event's signal and its destruction, and full event tables (vsync events after 16, host
    events), each of which ended the game;
  • a movie ending the game when memory for a picture ran short;
  • game sessions closed while another thread still used them;
  • after 15 to 66 hours in one session, textures the game writes stopping to update (the counters behind them are
    now 64-bit);
  • audio settings the game sends that our audio renderer did not accept ended the game; now the one effect is left
    out and one line goes into the log (audio_strict = 1 brings the old behaviour back for bug reports);
  • a stuck shader translation no longer holds the game for four minutes;
  • a save file could be closed while another thread was still reading it.
• Crash reports and exits: a second crash no longer cuts the first one's report short; a stack overflow writes a
  report; an error or a lost device ends the game without running every library's shutdown, where DLSS's could crash;
  HD rumble stops at every end; the end of the log is written even past its 64 MiB cap. A hang watch writes a report
  to the log when no frame is shown with the window in front, or the GPU does not finish, for 20 seconds
  (hang_watch_s, 0 turns it off). The launcher
  explains code 72 (the graphics device was lost) and shows the game's error line after a restart and from the Steam
  shortcut.

Frame pacing and RivaTuner Statistics Server

• RivaTuner's profile is put back when the game closes, before the slow save of its pipelines, and no frame drawn
  after that writes the game's limit into it again. After a crash or a Task Manager kill, the next start puts it back
  from rtss-profile.txt next to the game, unless you changed the profile since. If you never made a RivaTuner
  profile for the game yourself, delete Profiles\ocarina.exe.cfg in RivaTuner's folder once: earlier versions could
  leave a frozen copy of the global profile there.
• The game hands the limit to RivaTuner only once RivaTuner is seen holding it, and takes it back while a movie
  plays, while the window is minimised or no picture goes out, and for the run when RivaTuner lets frames through
  faster than the limit or never shows its hold. A limit set in RivaTuner itself on top of the game's is named in the
  log and in the menu's frame rate row.
• A limit change reaches RivaTuner's profile once it stays, not at every switch of low latency; display on a 59.94 Hz
  monitor is rounded down for RivaTuner versions without fractional limits.
• With DLSS Frame Generation, Reflex now holds the frame limit (reflex_limit = 1), so the game waits once per
  frame instead of twice; the game's limiter takes over during movies and when Reflex does not hold it.
• Fewer stutters: turning DLSS or FSR on or off, changing its mode, pausing and resizing no longer stop the
  graphics card until it is idle; fewer memory freezes right after an area load; pipelines are remembered as soon as
  they are first built; the shipped list of pipelines built before play grew to 10,230.

Fixed above 60 fps

• The ocarina's song recorder keeps its timing at any frame rate (ocarina_timing, on by default). Above 60 fps
  its clock stood still: a song taught to the scarecrow lost its pauses and the recorder's time limits never came.
  Songs recorded above 60 fps in earlier versions keep their missing pauses.
• The shake key swings at the game's own pace at any frame rate.
• Dynamic resolution (dyn_res = 1) aims at the frame limit you set, not at 60 fps.

Settings

• In nx2navi.ini, a comment after a value (pace_smooth = 0 ; off) and the words off, false and no now mean
  what they say for on/off settings; before, such a line could turn the setting on. Paths and names keep their whole
  text.
• New: reflex_limit, ocarina_timing, audio_strict, hang_watch_s, mesh_fallback_hold, and switches that
  bring back the earlier behaviour of this release's larger changes should one cause trouble: upscaler_idle_wait,
  present_order, wb_lazy_unlocked. See nx2navi.ini.example.