github tangerineturtle1/NX2navi v0.7.0
NX2navi 0.7.0

26 minutes ago

A performance and feature release for The Legend of Zelda: Ocarina of Time for Nintendo Switch 2 (game version
1.1.1): a higher frame rate in towns and less stutter, less memory, DLSS Multi Frame Generation, save sharing, a
launcher you can restyle, and many fixes. No game files are included: the setup builds the game on your PC from
your own dump.

Install or update

  • Already have 0.6.0 or 0.6.1: start the launcher; it offers 0.7.0, updates itself and keeps the game it compiled
    and the shaders it prepared. Only what changed is compiled again, and the update fills the graphics driver's cache
    again before you play.
  • 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.7.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, VK_EXT_external_memory_host and VK_EXT_mesh_shader (current NVIDIA and AMD
cards).

Faster

  • Towns. Large towns release and take back thousands of textures a second, and every one made the game's texture
    table look up about 10,000 entries again. A texture that comes back unchanged now leaves the table alone.
  • Every frame. The wait after a frame's first GPU submission no longer includes the copy back to memory (3 to 4 ms
    a frame), the command recorder no longer spins while it has nothing to do, and work a draw repeats is skipped.
  • Less stutter. Textures are created over several frames instead of all at once, shaders are read from the disk
    off the render thread, a controller that connects or disconnects no longer stalls the game for 100 ms and more, and
    DLSS Frame Generation no longer makes 100 to 150 ms frames after menus and cutscenes.
  • Experimental FPS boost (Screen tab of the settings menu, off by default, takes effect after a restart; wb_lazy
    in nx2navi.ini). What the game's shaders write into its memory is copied back from the video card after every GPU
    submission, in case the game's CPU code reads it: 66 MiB a frame in Hyrule Field, more than half of the frame's GPU
    time. With the boost on it is copied once and after that only when the CPU touches it: standing in Hyrule Field on
    our test PC (RTX 5090, 3416x1440, DLAA) that is 76 fps instead of 57. It is experimental because single frames of the
    scene can flicker with it on, more when other programs keep the processor busy; tell us what you see if you try it.
  • Threads that wait. A signalled event woke every waiting thread of the game, 200 times a second for the audio
    renderer's alone, and each took a processor core to find nothing for it. Only the threads that wait for that event
    wake now.
  • The log. A thread of its own writes it, so a slow disk, a virus scanner or a console window no longer holds up
    the thread that draws the frame (log_async = 0 for the old way).
  • Less memory. With a full shader cache the game holds about 1.6 GiB less video memory from the title screen on
    (twenty very large shaders the game never runs were created at every start), video memory blocks are smaller, DLSS
    models that are not in use are freed, textures no shader has sampled for two minutes give way when memory runs low,
    and textures give way before the game's buffers lose their place in video memory.

New

  • DLSS Multi Frame Generation at 2x, 3x and 4x on cards that support it (Frame generation on the Screen tab).
    With frame generation on and no frame limit chosen, the game limits itself to the display's refresh rate.
  • Share a save: Saves in the launcher (Export Save, Import a Save) and Saves on the Game tab of the
    settings menu write your save into one zip in your Downloads folder, with the game's log and settings for a bug
    report, and import a zip someone shared. Attach the bug report zip to a report from a place in the game, so it can
    be reached and checked quickly. An import copies your current save to the saves folder of the game folder first;
    in the game it takes effect at the next start.
  • Customize Launcher (on the launcher's home screen): six colour schemes, a background picture of your own with
    adjustable dimming, animations (a gliding cursor, sliding screens, drifting sparks) and sound effects: the game's
    own select and back sounds, read from your game, quiet (Low) unless you pick another loudness or turn them off.
  • Texture filtering on the Screen tab: anisotropic filtering, applied while the game runs.
  • More settings take effect without a restart: HDR between off and the tone mapper (only the game's native HDR still
    waits for one), the camera's stick sensitivity, the speakers (stereo or 5.1), and the texture sharpness that goes
    with the DLSS or FSR 3.1 mode.
  • The setup checks every game file and stands in for damaged textures instead of failing later in play.
  • On processors whose two dies differ (AMD's two-die X3D models) the game runs on the die with the larger cache.
    cache_die = 0 in nx2navi.ini turns that off.

Linux

None of the following could be run by us: it comes from contributors' pull requests, compiled here on Windows only.
Tell us what works and what does not.

  • An AppImage with a window to install, update and play. An automated job builds it after this release is
    published and attaches it here when it succeeds. It includes NVIDIA's DLSS library, or downloads it beside the game
    on machines with NVIDIA's driver.
  • DLSS frame generation on Linux, 2x to 6x or dynamic, switched while the game runs.
  • Steam Deck: its own button prompts (prompts = steamdeck), and a profile with four virtual cores, BC3 for ASTC
    textures and a shorter spin hand-off.
  • Shadow storage (Linux and Proton): the black 3D world is fixed, each side copies only what it wrote, shaders can
    follow the game's pointers into shadow copies, and lighting no longer adds up frame after frame.
  • The recording thread gets a fast core and its sibling, the low-memory handling can read a memory limit, FSR 3.1 is
    offered only where its library can load, and NVIDIA's shader disk cache is set only with NVIDIA's driver.
  • A source checkout builds again (the runtime's shader headers are made before the game compiles), and the build reads
    the processor's level from /proc/cpuinfo when the compiler's own detection finds none.

Fixed

  • Ground, walls and characters that appeared and disappeared, black or unlit frames, and stalls of up to two seconds
    wherever something was shown for the first time (a new area, a cutscene). The graphics driver's cache had lost the
    shader libraries prepared at install, so every new pipeline compiled during play: after a driver update, or after
    an update of NX2navi that changes how the libraries are built (this one does on AMD RX 7000 and RX 9000 cards,
    where it also ends the 20 second start). The game now checks the driver's cache at every start and fills it again
    in the background by itself, an update fills it again before you play, draws wait a moment for a pipeline that only
    needs linking instead of being left out, and lighting passes are no longer left out at all.
  • A black or unlit frame, or a light or a piece of ground missing for a frame, when something new came on screen (a
    hit, a new effect, a new enemy). A draw whose pipeline was not ready in time was left out of that frame, a lighting
    pass among them once its 50 ms were spent, and the frame was shown without it. Such a frame is no longer shown:
    the previous picture stays for the frame or two it takes, while the game runs on (frame_hold_ms, 120 by default;
    0 shows every frame as before).
  • A dark or black flash when a DLSS or FSR 3.1 mode was picked in the settings menu. The game makes its scene images
    again at the new size and the first frames drawn into them came out dark or black; the previous picture now stays
    on screen for those few frames, with frame generation on as well.
  • The ground, walls and buildings drawn black for the first second or seconds after a load screen (longer on a busy or
    slower processor). An area's textures were made a few dozen a frame like textures that stream in during play; after a
    load they are now made at once, before the area fades in.
  • The performance overlay's VRAM line counted every program on the graphics card as if it were the game. It now
    shows the game's own share beside it (game 6.8 GB of 10.4 GB in use, in one measurement).
  • The performance overlay's frame rate, lows and frame-time graph are now those of the pictures as they reach the
    screen. They were measured at the game's present calls, which come in uneven steps although the pictures do not: in
    a village the calls came 36 and 9 ms apart in turn and the graph drew a sawtooth with a 1% low of 14 fps, while the
    pictures went out about 20 ms apart and changed by 4 ms from one to the next. A picture that arrives early now also
    waits until seven eighths of the recent interval have passed (pace_smooth, on by default; not with frame
    generation), which brought that change down to 3 ms at the same frame rate.
  • GPU frame prep on its own thread (replay_async, off by default): the shader constants of a frame are now
    copied when the game hands the frame over, not when the other thread gets to it up to a frame later, by which time
    the game had sometimes reused that memory (a shadow pass got another block's values about every 364 frames in one
    graveyard). The option can still show a dark or flickering frame: vertex, storage and index data are read late in
    the same way, and this game rewrites them without waiting for the GPU. The menu says so now. It gave 15 to 18
    percent more frames per second in a graveyard and a village.
  • Textures that turned dark or blank for a moment: textures out of view were dropped after 11 seconds at 165 fps (30
    seconds were meant) and came back as a stand-in for a few frames. The wait is two minutes of real time at any frame
    rate now, and the scene's textures are kept through a pause.
  • Black frames about once a second while the camera turned, and black frames when a picture's memory was handed to a
    new texture.
  • Red flashing on some screens: the picture the game's last pass really writes is shown.
  • The fog no longer leaves dark trails behind nearby objects.
  • Above 60 fps, moving platforms should no longer drop you and enemies should track you again: the physics solver's
    step count is rounded up and the game gets a steady step. Tell us where it still goes wrong.
  • A crash when opening the quick menu at very high frame rates: with the limit unlimited or higher, the game holds
    itself to 240 frames a second.
  • Crashes when switching between AMD's and NVIDIA's frame generation, and when picking a DLSS mode while FSR 3.1 runs.
    FSR 3.1 also keeps running when the render scale changes more than a few times.
  • DLSS and DLAA now start on installs whose registry does not say where NVIDIA's NGX library is.
  • A crash on Intel GPUs while the pipeline cache was saved.
  • A crash on draws with large mesh tables, a rare corruption of vector registers when a game thread was interrupted
    (processors without AVX use were unaffected), and seven smaller runtime faults a tester's report named.
  • Long sessions: the table of the game's memory addresses no longer runs out, and when the system's memory is nearly
    full the game frees textures it can get back instead of only its cache of released ones.
  • A movie frame is dropped, or a sound sample tried again, when memory runs out, instead of the game stopping.
  • A fault in an audio voice that was released twice.
  • A crash report written while the game was closing, although nothing had gone wrong.
  • An update over an install that began with 0.5.0 keeps the processor level the game was compiled for, Rebuild the
    Game
    compiles for the processor you have now, and the game's code is lifted again after Keep Build Cache was off.
  • Launcher downloads that end early are tried again.
  • Settings menu, mouse: a setting changes only on the two framed arrows beside its value, and the arrows stay in one
    place. Holding the button on an arrow repeats.
  • Linux: the SDL window honours the monitor setting, a Wayland fullscreen window reports where the compositor put it,
    NVIDIA's NGX is released before the device, the runtime library builds and installed tools refresh correctly, and
    NVIDIA's shader disk cache is kept beside the game with a limit that holds the prepared set (the driver builds its
    cache once more after this update).

Known issues

  • The first visit to an area after an install can still pause while the graphics driver builds what it has not seen.
  • When the system's memory is nearly full, towns re-upload many textures and the frame rate drops; closing other
    programs helps. Machines with 16 GB of RAM can run out of system memory in Hyrule Field.
  • Integrated AMD GPUs can fail at the title screen (their host memory heap is too small for the game's memory).
  • Opening the game's settings menu can crash on some AMD Radeon GPUs.
  • A rare crash in the game's particle code.
  • With Experimental FPS boost on (off by default) single frames of the scene can flicker.

For builders

  • The repository holds the runtime's own shaders as source only; the build compiles them (tools/build_shaders.py),
    so a build from source needs glslc and spirv-as (MSYS2 shaderc and spirv-tools).
  • New diagnostics: gpu_passes = 1 times what a submission spends on the GPU outside the game's passes, wb_probe = 1
    reports who reads what the GPU wrote back, wb_lazy_touch reads lazily written ranges on purpose, tex_disuse = 2
    tells the freeing of unsampled textures from their marking, and the profile report names the exe's functions from a
    GNU ld map too.
  • --boot and --seconds work on game 1.1.1, and the world clock starts there.
  • dlss_idle_free, compute_keep, lib_prebuild_big and wb_split are described in nx2navi.ini.example.

Thanks

Pull requests in this release came from ajcohn716, DeepDaddyTTV, epicmeme546, intellq, itaskaev2, jacc, Leyukaka,
loteran, mooki000, ordinarybob, peigongdsd, PlayerJV55, repparw, schoperena, spidercraft, theurbanninja1993-sketch,
TophC7 and twisted89, and JEDGIT18 tracked down the audio voice fault. Thanks to
everyone who sent logs, memory reports 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.

Don't miss a new NX2navi release

NewReleases is sending notifications on new releases.