aa4ffafbc5
Last iteration left an unidentified full-screen untextured quad decaying 255->15 during a menu->title transition, which build 5's declaration does not account for. Hypothesis: it is the INCOMING screen's own pteff00, which opens at a255 and clears. 8 frames matching build 4's declared 16 units is a FIT, so the test was a transition whose incoming screen declares something else: title->menu brings in build 5, 0->12 = 12 units = 6 frames. Prediction recorded before the run. Measured: menu->title decay 8 frames (incoming build 4, declared 8), title->menu decay 5 frames (incoming build 5, declared 6). Different incoming screen, different decay, in the predicted direction. The second is one frame short of prediction, inside the documented +-1. The tell that clinches it: a screen contributes TWO primitives, pteff00 at 255 and pteff02 at 64. The settled menu's untextured set is [64]; at frame 34 it becomes [64, 255, 64] -- build 4's opening pair, which no single element explains. Bonus, and it closes the alpha puzzle: in capture 2 the outgoing quad ramps with no other untextured quad present -- 63, 127, 191, 255, steps of exactly 64, four frames, against build 4's declared 261->269 = 8 units = 4 frames. Exact and exactly linear. Capture 1's 102/127/255 was a composite of two overlapping quads, as sylpheed-port proposed. The thing neither of us predicted: the two directions are not the same shape. (A) title->menu is SEQUENTIAL with a real black interval of 5 frames (~10 units, against the port's authored 9). (B) menu->title is a CROSS-FADE with no black interval at all -- the incoming title starts drawing at frame 34, before the outgoing menu's quad begins ramping at 40. Authoring one hold for both directions inserts black that (B) does not have. Also fixed: fade_pair.py's automatic rising/decaying classifier worked on capture 1 and produced nonsense on capture 2, where the title has no full-screen primitive at rest and the heuristic latched onto a transient. It now prints and does not decide. Refutation attempted: sylpheed-port's structural prediction of a 6-frame decay for an incoming menu. Measured 5. Survives as direction, one frame short as duration; recorded as both. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
93 lines
4.1 KiB
Bash
Executable File
93 lines
4.1 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Decompose a screen transition's ~0.4 s fade-out into RAMP + HOLD, at the
|
|
# emulator's own frame granularity.
|
|
#
|
|
# docs/re/screen-transitions.md measures the fade-out as ~0.4 s (~24 units) while
|
|
# `pteff00.prm`'s final declared ramp is 70->80 = 10 units. The remainder is
|
|
# currently ARITHMETIC THAT FITS -- "the other 14 units must be the black hold"
|
|
# -- and that page says so itself. This measures it instead.
|
|
#
|
|
# The design point: arm the UI draw capture ON THE MAIN MENU, then press (B).
|
|
# One capture window then contains
|
|
# * the menu's fade-OUT -- the unknown, and
|
|
# * the title's fade-IN -- whose ramp IS decoded from the file (build 4's
|
|
# pteff00.prm, t=16 a=255 -> t=261 a=0, 245 units),
|
|
# so the run carries its own control: an instrument that cannot reproduce the
|
|
# known fade-in cannot be trusted on the unknown fade-out.
|
|
#
|
|
# Traps inherited from menu_draw_capture.sh, both already paid for:
|
|
# * F10 arms the capture AND opens the emulator menu bar; any Xenia UI makes
|
|
# IsUIActive() true and every later guest keystroke is swallowed. Click the
|
|
# game surface to dismiss before touching the pad.
|
|
# * a 0.12 s tap gets missed; hold (B) 0.5 s and confirm [RE-INPUT] delivery.
|
|
#
|
|
# WHERE=menu (default) arms on the main menu and presses (B) -> menu -> title.
|
|
# WHERE=title arms on the boot title and presses (A) -> title -> menu.
|
|
# The two transitions have DIFFERENT declared fade-ins for the incoming screen --
|
|
# build 4 is 0->16 (16 units, 8 frames), build 5 is 0->12 (12 units, 6 frames) --
|
|
# which is what makes the pair a discriminator rather than a fit.
|
|
#
|
|
# Usage: WHERE=title fade_decompose.sh [out_dir]
|
|
set -u
|
|
export HOME=/sylph-home/re SDL_AUDIODRIVER=dummy DISPLAY=:98
|
|
SD="$(cd "$(dirname "$0")" && pwd)"
|
|
OUT="${1:-/sylph-home/re/fadecap}"
|
|
mkdir -p "$OUT"; rm -f "$OUT"/xenia_re_ui_draws_*.log
|
|
alive(){ ps -o pid=,stat= -C xenia_canary 2>/dev/null | awk '$2 !~ /^Z/ {print $1}'; }
|
|
shot(){ screenshot "$1" >/dev/null 2>&1; }
|
|
screen(){ shot /tmp/fdc.png; python3 "$SD/screen_id.py" /tmp/fdc.png | awk '{print $1}'; }
|
|
|
|
( cd "$OUT" && nohup run-canary --mem_watch=false --log_ui_draws=true \
|
|
--ui_draw_capture_frames="${FRAMES:-260}" \
|
|
--ui_draw_capture_max="${MAXDRAWS:-400000}" \
|
|
--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)"
|
|
|
|
# 1. wait for the boot title; do not tap through the intro (a run that tapped
|
|
# every 4 s delivered 88 presses and ended on a black screen).
|
|
deadline=$(( SECONDS + 420 )); s=""
|
|
while [ $SECONDS -lt $deadline ]; do
|
|
s="$(screen)"; echo "t=${SECONDS}s $s"
|
|
[ "$s" = "title" ] && break
|
|
sleep 4
|
|
done
|
|
[ "$s" = "title" ] || { echo "NEVER REACHED THE TITLE"; exit 1; }
|
|
|
|
WHERE="${WHERE:-menu}"
|
|
if [ "$WHERE" = "menu" ]; then
|
|
# 2. one (A) on the boot title -> main menu; we arm THERE and press (B).
|
|
python3 "$SD/pad.py" tap A 0.5
|
|
for _ in 1 2 3 4 5 6; do
|
|
sleep 4; s="$(screen)"; echo " after A: $s"
|
|
[ "$s" = "menu" ] && break
|
|
done
|
|
[ "$s" = "menu" ] || { echo "NO MENU (screen=$s)"; exit 2; }
|
|
BTN=B
|
|
else
|
|
# arm on the title itself and press (A): the incoming screen is then build 5,
|
|
# whose declared fade-in is 12 units where build 4's is 16.
|
|
BTN=A
|
|
fi
|
|
shot "$OUT/armed-on-$WHERE.png"
|
|
|
|
# 3. arm the capture, dismiss the menu bar F10 opened, then press (B).
|
|
# Everything between F10 and (B) is spent inside the capture window, so keep
|
|
# it short: the window is FRAMES submitted frames, not seconds.
|
|
xdotool windowactivate --sync "$win"; sleep 1
|
|
xdotool key F10; sleep 0.6
|
|
xdotool mousemove 900 400 click 1; sleep 0.6
|
|
echo "-- ($BTN) at $(date +%S.%N) --"
|
|
python3 "$SD/pad.py" tap $BTN 0.5
|
|
sleep 12
|
|
shot "$OUT/after-press.png"; echo "screen after $BTN: $(screen)"
|
|
|
|
grep -c "RE-INPUT" "$OUT/canary.stdout" 2>/dev/null | sed 's/^/[RE-INPUT] lines: /'
|
|
ls -l "$OUT"/xenia_re_ui_draws_*.log 2>/dev/null || echo "NO CAPTURE LOG"
|
|
grep -i "UI-CAP" "$OUT/canary.stdout" | tail -3
|
|
echo "FADE CAPTURE DONE (emulator left running)"
|