From 45ee8c3a1bb8e28171f0345d1cfec96d397da8f9 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 19 Aug 2026 00:58:46 +0000 Subject: [PATCH] docs/re: the loading screen never boots, and no other build explains the order MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 | 45 ++++++++++++++++++++++++ tools/re-capture/loading_draw_capture.sh | 43 ++++++++++++++++++++++ 2 files changed, 88 insertions(+) create mode 100755 tools/re-capture/loading_draw_capture.sh diff --git a/docs/re/ui-title-paint-order-capture.md b/docs/re/ui-title-paint-order-capture.md index 54a23197..ddeb55ea 100644 --- a/docs/re/ui-title-paint-order-capture.md +++ b/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. diff --git a/tools/re-capture/loading_draw_capture.sh b/tools/re-capture/loading_draw_capture.sh new file mode 100755 index 00000000..b7cada8a --- /dev/null +++ b/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)"