1538c3e333
The frame-rate test sylpheed-port and I agreed was the only clean route left.
Same strips, same screen, --framerate_limit=15 against the default. The limit
demonstrably took effect: the title settled at 862 s against 241 s.
First, a gate this work should have had from the start. A slope is only a rate if
its residual is random, so count sign changes in the residual:
default 1299x1303 -4.348 rms 3.33 43/111 OK
883x1134 +4.284 rms 3.08 21/76 SYSTEMATIC
890x1134 +4.284 rms 3.19 15/54 SYSTEMATIC
limit 15 1299x1303 -2.032 rms 1.51 44/83 OK
883x1134 +2.003 rms 1.12 36/61 OK
890x1134 +1.999 rms 0.74 12/37 SYSTEMATIC
So one of the two strips I quoted as "agreeing to three significant figures"
FAILS the linearity gate at default fps: that agreement was between a rate and a
slope through a curve. The port had already caveated the claim for a different
reason; this weakens it further from my own side.
The result, on the one group passing the gate at both settings: -4.348 px/frame
at default against -2.032 at limit 15, a ratio of 2.14.
THE LEAF IS NOT FRAME-LOCKED. A fixed number of units per submitted frame
predicts px/frame unchanged; it changed by 2.14x. Dead.
A simple wall-clock model is dead too, in the other direction: fewer frames per
second means more wall time per frame, so a time-driven leaf should move MORE
px/frame at a lower limit. It moved LESS. Neither model fits and I have no third.
Reach: the effective frame rate was NOT measured. The timing instrument I added
polls for the capture log, which is created when the capture is ARMED rather than
when it finishes, so it reported 0.728 s and is void. The 3.6x boot slowdown says
the limit took effect, not that fps went 28 -> 15. The RATIO is measured; the
absolute rate still is not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
49 lines
2.5 KiB
Bash
Executable File
49 lines
2.5 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Does the game DRAW the sweep leaves (pteff03 / pteff03a) on a SETTLED title?
|
|
#
|
|
# ui-resting-pose.md records a tension: two renders one plateau-phase apart differ
|
|
# by RMSE 11.9 INSIDE the adjudication box, while two captures of that screen from
|
|
# different sessions differ by 0.32 there, and an --at sweep against a capture is
|
|
# flat to 1.2. A metric cannot be insensitive to an 11.9 change unless what
|
|
# changed is largely absent from what it is compared against.
|
|
#
|
|
# The leaves are a 400 px-wide strip at scale (100, 600) / (100, 800) -- 1080 and
|
|
# 1440 px tall, taller than the screen. If the game draws them and they free-run,
|
|
# the draw stream shows a tall strip whose x translates frame to frame. That is
|
|
# unmistakable, and the plate's own pulsing is the in-capture control that the
|
|
# instrument is seeing real variation rather than one frozen frame.
|
|
set -u
|
|
export HOME=/sylph-home/re SDL_AUDIODRIVER=dummy DISPLAY=:98
|
|
SD="$(cd "$(dirname "$0")" && pwd)"
|
|
OUT="${1:-/sylph-home/re/titledraw}"; mkdir -p "$OUT"; rm -f "$OUT"/xenia_re_ui_draws_*.log
|
|
. "$(dirname "${BASH_SOURCE[0]}")/ensure_single_emulator.sh"
|
|
ensure_single_emulator || exit 3
|
|
( cd "$OUT" && nohup run-canary --mem_watch=false --log_ui_draws=true \
|
|
--ui_draw_capture_frames="${FRAMES:-150}" --ui_draw_capture_max=400000 \
|
|
--framerate_limit="${FPSLIMIT:-0}" \
|
|
--logged_profile_slot_0_xuid=B13EBABEBABEBABE \
|
|
>"$OUT/canary.stdout" 2>"$OUT/canary.stderr" & )
|
|
sleep 10
|
|
ps -C xenia_canary >/dev/null 2>&1 || { echo "EMULATOR DID NOT START:"; tail -3 "$OUT/canary.stderr"; exit 4; }
|
|
until xdotool search --name "Xenia-canary" >/dev/null 2>&1; do sleep 1; done
|
|
win="$(xdotool search --name "Xenia-canary" | tail -1)"
|
|
python3 "$SD/wait_plate_pulse.py" 900 || exit 1
|
|
xdotool windowactivate --sync "$win"; sleep 1
|
|
# Time the capture window so the run MEASURES its own frame rate instead of
|
|
# assuming it. Without this, px/frame cannot be turned into px/second and the
|
|
# leaf-rate question stays fps-bound -- which is exactly the caveat that closed
|
|
# three earlier routes.
|
|
t0=$(date +%s.%N)
|
|
xdotool key F10; sleep 0.6
|
|
xdotool mousemove 900 400 click 1
|
|
for _ in $(seq 1 400); do
|
|
ls "$OUT"/xenia_re_ui_draws_*.log >/dev/null 2>&1 && break
|
|
sleep 0.1
|
|
done
|
|
t1=$(date +%s.%N)
|
|
echo "CAPTURE-WALL-SECONDS $(awk -v a="$t0" -v b="$t1" "BEGIN{printf \"%.3f\", b-a}")"
|
|
sleep 6
|
|
grep -i "UI-CAP" "$OUT/canary.stdout" | tail -3
|
|
ls -l "$OUT"/xenia_re_ui_draws_*.log 2>/dev/null || echo "NO CAPTURE LOG"
|
|
echo "TITLE DRAW CAPTURE DONE"
|