NX2navi Performance and FPS Troubleshooting

01 /

Classify the NX2navi performance problem first

FPS measures a rate, while frame time describes how long each frame takes. A steady 60 FPS corresponds to about 16.7 ms per frame by arithmetic; occasional much longer frames can still create a visible hitch. This is an explanation of units, not a benchmark measured on this website.

A game can have an acceptable average frame rate while delivering individual frames unevenly. A brief pause on first entry to an area is different from consistently slow movement through the same route. A crash is a separate failure that needs its log preserved before another launch.

Start by describing what you see: persistent low FPS, periodic stutter, one transition pause, long build time or a process exit. Compilation speed during installation is not runtime FPS. If the game never completes its build, use installation errors, rather than changing graphics parameters that have not run yet.

02 /

Create a repeatable baseline before changing settings

Open the game settings with F1/Esc and use F10 or the more detailed performance panel. Choose a save, camera direction and route you can repeat. Record the port version, supported game version, OS, GPU and driver, along with display mode and background workload.

For graphics, record game_res, game_aspect, the reconstruction/upscaling choice, frame-generation state and frame cap. For OoT, output_res and render_scale are not substitutes for the applicable game-specific image settings. The graphics guide explains why a visually similar window can still use a different internal workload.

Disable frame generation for the initial comparison where applicable. Otherwise a displayed total can conceal a low underlying rendered rate. A good baseline includes both a first visit and a repeat run, rather than one screenshot of an unusually easy scene.

1. Keep the starting INI

   Back up the known-working file and record explicit overrides. A profile alone does not describe all active settings.

2. Repeat the same workload

   Use the same save/route and comparable power/background conditions. Avoid changing the driver in the middle of a settings comparison.

3. Change one relevant variable

   Compare a documented rendering height or supported reconstruction mode, then restore it before trying a different hypothesis.

4. Record pacing as well as FPS

   Note where long frames occur and whether they repeat. Describe a visible pause instead of inventing a percentile you did not measure.

03 /

First-visit stutter is not always shader compilation

The project describes graphics preparation, pipeline work and first-use resource costs. Even after shaders have been translated in advance, a new scene can still require resource/pipeline preparation or texture decoding. Calling every pause shader compilation hides those differences.

v0.8.0 notes improvements to memory-protection queuing, GPU-query batching and pipeline caching, while retaining a known first-area texture-decoding pause. That means a release can improve repeated stutter without eliminating every initial long frame. Compare the scene against the specific release note rather than treating a version number as a promise of perfect pacing.

Do not begin by clearing caches. The documented NVIDIA cache can reduce repeat preparation; removing it can make the next launch or route slower and invalidate the baseline. Keep logs describing repeated warm-up or preparation before deciding whether a particular cache operation is relevant.

04 /

Check RAM, VRAM and system memory pressure

The official requirements list a 16 GB RAM starting point, but the release notes also describe memory pressure in some areas. When system memory is nearly exhausted, repeated texture transfers can degrade performance. Close unrelated memory-heavy applications and compare the same scene before changing advanced engine options.

System RAM, GPU VRAM and the operating system's commit budget are different resources. A VRAM number alone does not establish that the whole system has enough memory headroom. Keep relevant memory/commit information from the log with the scene description.

The building documentation contains a Windows page-file suggestion for a particular 16 GB RAM scenario. It should not become a universal best-setting instruction for every machine. Begin with resource observation, enough disk space and ordinary background-work reduction; system memory-policy changes require understanding the actual environment and the matching guidance.

05 /

Tune workload without mistaking a cap for capability

A frame cap is a maximum request, not a minimum performance guarantee. Setting 120 FPS or choosing the Deck profile's 40 cap cannot make a slow scene reach that target. Rates above 60 are experimental in the reference and should be assessed with the documented timing conditions.

Compare the applicable internal height first, then a supported upscaling mode, keeping the scene unchanged. If a lower workload helps, that is evidence for that comparison, not proof of one universal bottleneck across the whole game. If nothing changes, check the effective value, cap and other resource limits before drawing a conclusion.

Frame generation can add smooth-looking display frames while preserving the underlying rendered rate. v0.8.0 counts the limiter in game-rendered frames, with generated output added. Observe image artifacts and input feel separately; this website has not measured end-to-end latency.

06 /

Version-matched developer results

The following figures are reported in the official v0.8.0 release notes for an RTX 5090 at 1440p, comparing v0.7.1 with v0.8.0. They are not this website’s measurements, do not describe every scene, and should not be transferred to another GPU or a handheld.

07 /

Read published benchmarks with their conditions

The v0.8.0 developer notes include RTX 5090 figures at 1440p comparing particular scenes with v0.7.1. They also include a Radeon RX 7900 XT example with a stated driver, resolution, reconstruction choice and lazy-writeback caveat. These are developer-reported examples, not tests from this website or expected results for other GPUs.

Do not rank two ports using unrelated FPS tables with different GPUs, routes or settings. The Hookshot comparison compares documented workflows and evidence limits instead of declaring a speed winner without a common protocol.

When reporting a remaining NX2navi performance problem, include the repeatable route, effective settings, first/repeat behavior and resource context. If possible, say what one-variable comparison changed. Keep game files, keys and generated data out of a public report.

COMMON QUESTIONS

Frequently asked questions