Stop saying that shader preparation keeps play from ever stopping to compile.

The preparation translates the game's shaders in their default bind state and builds their stage libraries and
compute pipelines into the driver's own cache. Variants met in play with another bind state are still translated then,
pipelines are still linked in play, and the driver cache is kept per executable and is lost when the driver clears
it. The launcher's step text, the README, make_game.py and docs/launcher.md now say it makes such stops far rarer.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

README.md

@@ -35,9 +35,10 @@ Report problems as issues, following [CONTRIBUTING.md](CONTRIBUTING.md).
   out of it, for about twice the frame rate on a fast display; in a window of another shape than the picture, frames
   are generated inside the picture only, so the black bars stay clean
 - HDR on HDR displays: the game's own native HDR, or its SDR picture tone mapped to the display's peak, with exposure, highlights, shadows, contrast, saturation and gamma in the menu
-- Every shader prepared when the game is built, and the pipelines met in play built again in the background at each
-  start, so play does not stop to compile them; a draw that must wait for its pipeline has it built on worker
-  threads, never on the game's drawing thread
+- The game's known shaders prepared when the game is built, and the pipelines met in play built again in the
+  background at each start, so play rarely stops to compile them; a shader or pipeline met for the first time can
+  still hold a frame, and a draw that must wait for its pipeline has it built on worker threads, never on the game's
+  drawing thread
 - In-game settings menu (F1, or Minus and Plus together on a gamepad) and performance overlay (F10)
 - Keyboard, mouse and gamepads with remapping, Nintendo or Xbox button layout, rumble and gyro; the game follows
   whichever connected gamepad you press

docs/launcher.md

@@ -88,8 +88,11 @@ A path the Windows ANSI code page cannot hold breaks the MSYS2 tools, so the too
      (it reads UCRT64's headers; `make_game.py` `fast_clang` checks that both report the same version and target).
    - The lifted code is compiled for the processor's own level, x86-64-v3 (AVX2, FMA) or v2 (`cpu_level`): the game
      runs on the PC that builds it, and a generic build would do every fused multiply-add of the game in software.
-3. **Prepare the Shaders**: make_game.py's last step translates every shader of the game into the game's shader
-   cache and the driver's own cache (`tools/prepare_shaders.py`), so play does not stop to compile them. Its bar
+3. **Prepare the Shaders**: make_game.py's last step translates every shader of the game, in its default bind state,
+   into the game's shader cache and builds its stage library or compute pipeline into the driver's own cache
+   (`tools/prepare_shaders.py`), so play stops for them far less often. Variants met in play with another bind state are
+   still translated then, full pipelines are still linked in play (quickly, from the cached parts), and the driver's
+   cache is kept per executable and is lost when the driver clears it. Its bar
    follows the game's own counts, printed every 2 s: the translation fills the first half, the build into the
    driver's cache the second. An update every 10 s keeps the step's text current while nothing is printed, and after
    3 minutes without a count moving it says so, and that the step is still running.

launcher/jobs.py

@@ -22,8 +22,8 @@ STEPS = {
     'compile': ('Compile', 'Compiling the translated code and the port into a Windows program.'),
     'compile_changed': ('Compile Changed Files', 'Compiling the files this version changed. Files that did not '
                                                  'change are kept from the last build.'),
-    'shaders': ('Prepare the Shaders', "Translating every shader of the game ahead of time, so play does not stop to "
-                                       'compile them.'),
+    'shaders': ('Prepare the Shaders', "Building the game's known shaders for your graphics card ahead of time, so "
+                                       'play stops for them far less often.'),
     'ready': ('Ready to Play', 'The game is built.'),
     'download': ('Download {ver}', 'Downloading the new version of NX2navi.'),
     'verify': ('Verify the Download', 'Checking the download against its checksum.'),

tools/make_game.py

@@ -16,7 +16,9 @@ Steps, each skipped when a run before finished it for the same inputs (state in
   5. compile  the lifted C and runtime/ with MSYS2's clang, linked into <out>/ocarina.exe; the MSYS2 DLLs it loads,
               the shader translator and romfs-index.bin beside it
   6. shaders  every shader in the game files (tools/prepare_shaders.py, default bind state) translated, and each one's
-              GPU driver build done once, so play does not stop to compile them (`ocarina.exe --prepare-shaders`)
+              GPU driver build done once into the driver's own cache, so play stops for them far less often
+              (`ocarina.exe --prepare-shaders`); variants met in play with another bind state are still translated
+              then, and the driver cache is per executable and is lost when the driver clears it
 
 The exefs and romfs steps depend only on the game files; lift and compile depend on this kit's code too. A newer kit
 therefore lifts and compiles again but keeps the unpacked game files, and --rebuild needs no game files at all. The