85d2e93d05
The port needs an initial delay and a repeat interval and has shipped the mechanism with -1.0 rather than invent them. This builds the instrument and does not get the numbers. The vertex stream is the right instrument: C_PAD_DECODER has no timer on any direction path, so the repeat is in the layer above and cannot be read out of that function; a cursor move is a quad changing position, and the guest's vertex buffer carries that with no Canary processing in the path. tools/re-capture/menu_repeat_probe.sh arms the logger, drives the boot with pad-file presses and holds a direction. It ran its whole sequence. But the boot did not reach the menu: in the settled era every quad shape holds a constant y, and the shapes are near-full-screen rects rather than a button list. No cursor, so nothing to repeat. Two instrument errors worth more than the failed run. The first attempt ARMED NOTHING and said nothing -- xdotool search --class ... --window %1 F10 behind a || true. The run completed normally and only the ABSENT log revealed it. The working form looks the window up by name, activates it, and sends F10 to the window and globally; a missing window is now fatal rather than tolerated, because a silent arming failure is indistinguishable from a screen that draws nothing. My first cursor detector measured the wrong change: presents where the SET of quads changed, which fired on 157 of 161 adjacent pairs because during a build-in everything animates. Tracking one quad shape's POSITION instead correctly reports no motion. That is the play-test's own lesson landing on me -- an instrument that measures change can still measure the change of the wrong thing. Next run must not drive the boot blind: gate the presses on a classifier or join with boot_menu.sh, which reaches the menu but takes screenshots rather than draw logs. Blind was chosen because screenshots cost ~10 s each while xenia runs; wrong trade, since a mistimed press costs the whole run. Reach: the negative is about this run, not the game. F1 stays open and the port should keep its -1.0 constants. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
58 lines
2.6 KiB
Bash
Executable File
58 lines
2.6 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# F1 -- MEASURE THE MENU REPEAT RATE, as a count of presents between cursor moves.
|
|
#
|
|
# The human watched the real game: a held direction repeats. `C_PAD_DECODER` has
|
|
# no timer on any direction path (pad-decoder-double-tap-not-key-repeat.md), so
|
|
# the repeat is in the layer above and can only be MEASURED here.
|
|
#
|
|
# Instrument: the guest's own vertex stream via the UI draw logger -- the same
|
|
# instrument that settled the splash, and the one with no Canary processing in
|
|
# it. A cursor move shows up as the focused quad's NDC rect changing.
|
|
#
|
|
# ⚠️ Drives the boot BLIND on timings rather than classifying frames. That is
|
|
# deliberate: the classifier route costs a screenshot per poll, and screenshots
|
|
# cost ~10 s each while xenia runs. The draw log records what actually happened,
|
|
# so a mistimed press is visible in the result rather than silently assumed.
|
|
#
|
|
# menu_repeat_probe.sh [out_dir] [hold_button]
|
|
set -u
|
|
export HOME=/sylph-home/re SDL_AUDIODRIVER=dummy DISPLAY=:98
|
|
export XENIA_PAD_FILE=/tmp/xenia_pad.txt
|
|
OUT="${1:-/sylph-home/re/f1}"
|
|
HOLD="${2:-DOWN}"
|
|
mkdir -p "$OUT"; rm -f "$OUT"/xenia_re_ui_draws_*.log
|
|
|
|
pad() { printf '%s' "$1" > "$XENIA_PAD_FILE.tmp"; mv "$XENIA_PAD_FILE.tmp" "$XENIA_PAD_FILE"; }
|
|
tap() { pad "press=$1"; sleep 0.40; pad ""; sleep 0.30; }
|
|
|
|
pad ""
|
|
( cd "$OUT" && nohup run-canary --log_ui_draws=true \
|
|
--ui_draw_capture_frames=4000 --ui_draw_capture_max=900000 \
|
|
>"$OUT/canary.stdout" 2>"$OUT/canary.stderr" & )
|
|
sleep 8
|
|
# Arm the capture. ⚠️ Copied verbatim from ui_draw_capture.sh, which works.
|
|
# A first attempt used `xdotool search --class xenia_canary key --window %1 F10`
|
|
# and armed NOTHING -- it failed silently behind a `|| true`, the run completed,
|
|
# and only the ABSENT log revealed it. Window lookup is by NAME, the key goes to
|
|
# the window AND globally, and a failure is now fatal rather than tolerated.
|
|
win="$(xdotool search --name "Xenia-canary" | tail -1)"
|
|
[ -n "$win" ] || { echo "FATAL: no Xenia window to arm"; pkill -x xenia_canary; exit 1; }
|
|
xdotool windowactivate "$win" 2>/dev/null
|
|
xdotool key --window "$win" F10
|
|
xdotool key F10
|
|
echo "armed at ${SECONDS}s (win=$win)"
|
|
|
|
# The boot, driven blind. Splashes ~8 s, then the attract movie; A skips it.
|
|
sleep 12; tap A ; echo "A #1 (skip video) at ${SECONDS}s"
|
|
sleep 6; tap A ; echo "A #2 (reveal plate) at ${SECONDS}s"
|
|
sleep 3; tap A ; echo "A #3 (accept plate) at ${SECONDS}s"
|
|
sleep 5
|
|
echo "HOLDING $HOLD at ${SECONDS}s"
|
|
pad "press=$HOLD"
|
|
sleep 12
|
|
pad ""
|
|
echo "released at ${SECONDS}s"
|
|
sleep 3
|
|
pkill -x xenia_canary
|
|
echo "done at ${SECONDS}s; log:"; ls -la "$OUT"/*.log
|