docs/re: the loading screen never boots, and no other build explains the order

Two routes closed, both cheaply.

The loading screen was the best discriminator reachable WITHOUT navigation — its
full-screen element is declared 7th of 10, so the two candidate orders would look
completely different. It does not appear during the boot at all: 23 captures
armed across an entire boot are all intro-movie frames, two full-screen quads
apiece. It belongs to a content load, which is behind the main menu, which is
behind the (A) that works half the time.

And a loophole this document had left open is shut: the title's sprites were
matched to build 4 BY SIZE, so the game might have been running some other build
whose table lists them in the captured order. Only two bundles in GP_TITLE.pak
contain all seven sprites, and neither is ascending in the captured order.

Recorded rather than glossed: one sub-order is genuinely ambiguous, because
ptlogo_back2eff and ptlogo_back2eff5 decode to the same 1133x280 and sit at
declaration 20 and 18, either side of ptlogo_back2 at 19. The UI quad carries a
k_8_8_8_8 colour attribute the hook does not log yet, and the two rest at
different fade alphas — logging it would name them apart.

docs/re/ui-title-paint-order-capture.md

@@ -313,3 +313,48 @@ So there is now a **reliable route to the main menu** — wait for the first tit
 after boot, tap Ⓐ once — which is what the second screen's capture needed, and it
 is written into `tools/re-capture/`. Why the attract title stops accepting input
 is still unexplained.
+
+## Two more routes closed (2026-08-19)
+
+### The loading screen does not appear during the boot
+
+`GP_TITLE`'s 10-element loading build is the best *unnavigated* discriminator on
+the disc: its full-screen element `pgloading_baseeff` (640×360 at 200 %) is
+declared **7th of 10**, behind the spinner and the "NOW LOADING" text, so which
+of the two orders the game uses would be plain to see.
+
+It never shows up. Arming a capture every ~6 s across an entire boot — 23
+captures, `tools/re-capture/loading_draw_capture.sh` — yields **zero** loading
+sprites: every capture is the intro movie compositing two full-screen quads per
+frame. The loading screen belongs to a *content* load (a mission, the hangar),
+which is behind the main menu, which is behind the Ⓐ that works half the time.
+
+### No other build's table produces the observed order either
+
+A loophole this document left open: the title's sprites were matched to build 4
+by size, so perhaps the game runs a *different* build whose table happens to
+list them in the captured order. Checked against every RATC bundle in
+`GP_TITLE.pak`:
+
+```
+entry 4  (a60fcb85) n=24  all 7 sprites present, ascending=False
+   ptbase2:9  ptlogo_back2eff:20  ptlogo_back2:19  ptlogo1:0
+   ptlogo_tm:7  ptlogo2:1  ptcopyright:21
+entry 7  (b483e6e6) n=30  all 7 sprites present, ascending=False
+```
+
+Only two bundles contain all seven, and **neither lists them in the captured
+order**. So the disagreement is not an artefact of picking the wrong build.
+
+### One sub-order is genuinely ambiguous, and how to fix it
+
+`ptlogo_back2eff` and `ptlogo_back2eff5` decode to the **same 1133×280**, so the
+capture cannot say which of them the first quad of that draw is — and they sit at
+declaration 20 and 18, on opposite sides of `ptlogo_back2` (19). The pair is the
+one place the observed order might still be locally ascending.
+
+It is resolvable: the UI quad's second vertex attribute is a `k_8_8_8_8` colour
+(`6@12` in the capture's attribute list), and the two elements rest at different
+fade alphas (`back2eff5` ends at α=192, `back2eff` at α=255). Logging that colour
+would name them apart — a small addition to the hook, and worth doing before any
+further ordering hypothesis rests on that pair.

tools/re-capture/loading_draw_capture.sh

@@ -0,0 +1,43 @@
+#!/usr/bin/env bash
+# Capture the LOADING screen's draw order. No navigation and no pad input at all:
+# the loading screen appears on its own during the boot, which matters because
+# (A) at the title only works about half the time.
+#
+# Why this screen: GP_TITLE's 10-element loading build declares its FULL-SCREEN
+# element (`pgloading_baseeff`, 640x360 at 200%) SEVENTH of ten, behind the
+# spinner and the "NOW LOADING" text. So it can tell "declaration order" apart
+# from "background first" — which the main menu could not, because its
+# background sits at index 1.
+#
+# F10 arms the capture (unconditionally, since 2026-08-19) and also opens the
+# emulator's menu bar, so each press is followed by a click on the game surface.
+set -u
+export HOME=/sylph-home/re SDL_AUDIODRIVER=dummy DISPLAY=:98
+SD="$(cd "$(dirname "$0")" && pwd)"
+OUT="${1:-/sylph-home/re/loadcap}"
+mkdir -p "$OUT"; rm -f "$OUT"/xenia_re_ui_draws_*.log
+shot(){ screenshot "$1" >/dev/null 2>&1; }
+alive(){ ps -o pid=,stat= -C xenia_canary 2>/dev/null | awk '$2 !~ /^Z/ {print $1}'; }
+
+( cd "$OUT" && nohup run-canary --mem_watch=false \
+    --ui_draw_capture_frames=4 --ui_draw_capture_max=6000 \
+    --logged_profile_slot_0_xuid=B13EBABEBABEBABE \
+    >"$OUT/canary.stdout" 2>"$OUT/canary.stderr" & )
+sleep 8
+until xdotool search --name "Xenia-canary" >/dev/null 2>&1; do
+  [ -n "$(alive)" ] || { echo "EMULATOR GONE"; exit 4; }; sleep 1
+done
+win="$(xdotool search --name "Xenia-canary" | tail -1)"
+xdotool windowactivate --sync "$win"; sleep 1
+
+for i in $(seq 1 "${PRESSES:-28}"); do
+  shot "$OUT/frame-$(printf '%02d' "$i").png"
+  xdotool key F10; sleep 1
+  xdotool mousemove 900 400 click 1
+  s=$(python3 "$SD/screen_id.py" "$OUT/frame-$(printf '%02d' "$i").png" | awk '{print $1}')
+  echo "press $i at ${SECONDS}s (screen=$s)"
+  [ "$s" = "title" ] && { echo "title reached; stopping"; break; }
+  sleep 5
+done
+ls "$OUT"/xenia_re_ui_draws_*.log 2>/dev/null | wc -l
+echo "LOADING CAPTURE DONE (emulator left running)"