2298abe33e
Four models for how the game advances the sweep leaf, four refutations. Frame-locked predicts px/frame unchanged under --framerate_limit; measured -4.348 -> -2.032. Wall-clock predicts px/frame LARGER at a lower limit; it got smaller. sylpheed-port's alternative -- that my samples might be at a fixed wall-clock rate while guest time slows, which would reproduce the direction -- checked rather than assumed: every capture reports 150 frames spanning 1..149, so the capture is indexed by guest VdSwap submissions. And per UI-drawing frame, which matters because at limit 15 only 99 of 150 frames carry draws against 131 at default, gives -5.773 vs -3.687, ratio 1.57, not invariant either. Three measures of one slowdown -- 3.58x on the boot, 2.14x per submitted frame, 1.57x per appearance -- and no two agree. The clock is none of the four and the absolute rate stays unpinned. Recorded as undecodable with the reach stated. Two things the same data does establish. The rotation is confirmed FROM THE ORACLE. The port's export carries rotation_deg +30 on pteff03 and -45 on pteff03a, read from the file. The AABB height of a rotated quad predicts from the declared scale alone: 400x1080 at +30deg -> 1135.3 against 1134 observed (0.12 %), and 400x1440 at -45deg -> 1301.1 against 1303 (0.15 %). Two angles, two scales, both under 0.2 %. Which makes their inversion real. Height 1134 IS pteff03 -- the leaf whose declared track is perfectly linear at +4.0000 px/unit across both segments -- and that is the strip my sign-change gate FAILS. Height 1303 is pteff03a, the slightly non-uniform one, and it passes. The curvature is in the strip whose source is exactly straight, so it is not in the disc: it is in the measurement or in how the game advances the record. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
199 lines
11 KiB
Plaintext
199 lines
11 KiB
Plaintext
# Does the GAME draw the sweep leaves on a SETTLED title? 2026-08-30.
|
|
# tools/re-capture/title_draw_capture.sh -> log_ui_draws, 150 frames.
|
|
# Gated on the plate pulse (glyph in [500,2500] held 12 samples); fired at 325.3 s.
|
|
# Exactly ONE emulator, verified by count through ensure_single_emulator.sh.
|
|
#
|
|
# The question came from a tension in ui-resting-pose.md: two renders one
|
|
# plateau-phase apart differ by RMSE 11.9 inside the adjudication box, while two
|
|
# captures of a (JP) title from different sessions differ by 0.32 there. I
|
|
# hypothesised the game might not draw these leaves at rest.
|
|
#
|
|
# ANSWER: IT DOES, AND THEY FREE-RUN. Two quads TALLER THAN THE SCREEN, present
|
|
# in every frame of 132, sweeping in OPPOSITE directions:
|
|
#
|
|
# strip A h=1134 ROT 132 appearances x -109 -> +518 step +6..7 px/frame
|
|
# strip B h=1303 ROT 112 appearances x +486 -> -154 step -6..7 px/frame
|
|
#
|
|
# x over frames, strip A: 1:-109 2:-109 3:-102 4:-102 6:-90 7:-90 8:-90 9:-83
|
|
# 10:-77 11:-70 12:-64 13:-58 ...
|
|
# x over frames, strip B: 1:486 2:480 3:480 4:474 6:467 8:461 9:454 12:442
|
|
# 13:435 14:429 15:422 18:410 ...
|
|
#
|
|
# ✅ THE RATE MATCHES THE DISC. The declared x track is -639..1521 = 2160 px over
|
|
# a 600-unit cycle = 3.6 px/unit, and Q1 gives 2 units per rendered frame, so
|
|
# 7.2 px/frame predicted against 6-7 measured.
|
|
#
|
|
# ⚠️ Both are flagged ROT -- rotated, which is why their axis-aligned bounding
|
|
# boxes come out ~885 and ~1300 px wide where the declared quad is 400. Consistent
|
|
# with ui-keyframe-rotation.md placing rotation in leaf records, and with
|
|
# `screen render` being axis-aligned only.
|
|
#
|
|
# 🔴 SO MY OWN HYPOTHESIS IS REFUTED by the oracle, and sylpheed-port's reading of
|
|
# their `title` curve -- that the sweep is PRESENT in a title capture -- is
|
|
# confirmed.
|
|
|
|
################################################################################
|
|
# 🔴 BOTH HALVES OF THE "RATE MATCHES THE DISC" LINE ABOVE ARE WITHDRAWN.
|
|
#
|
|
# The PREDICTION was wrong. sylpheed-port pointed out that the final segment
|
|
# HOLDS, so a cycle length is not a motion duration. Verified from the disc:
|
|
# pteff03 motion ends t=540 of a 600-unit cycle -> 4.000 px/unit (not 3.600)
|
|
# pteff03a motion ends t=630 of a 720-unit cycle -> 4.063 px/unit (not 3.556)
|
|
#
|
|
# The MEASUREMENT was also wrong, and that error is mine alone. "6-7 px/frame"
|
|
# came from eyeballing deltas between consecutive APPEARANCES, but the capture
|
|
# skips frames -- so a delta of 7 often spans two frames, not one. A least-squares
|
|
# fit of x against frame over the whole capture gives:
|
|
# strip A +4.287 px/frame (132 pts, frames 1..149, rms resid 3.59 px)
|
|
# strip B -4.348 px/frame (112 pts, frames 1..149, rms resid 3.33 px)
|
|
#
|
|
# ⚠️ So the confirmation was two errors that happened to overlap: a prediction
|
|
# 20 % too low meeting a measurement 50 % too high. Neither number was right and
|
|
# the agreement was an artefact of both being wrong.
|
|
#
|
|
# 📌 WHAT THE CORRECTED NUMBERS SAY -- and it is a bigger claim than the one
|
|
# withdrawn:
|
|
#
|
|
# strip A / pteff03 measured 4.287 px/frame / declared 4.000 px/unit
|
|
# strip B / pteff03a measured 4.348 px/frame / declared 4.063 px/unit
|
|
# -> 1.072 and 1.070 units/frame
|
|
#
|
|
# Two independent strips, different cycle lengths and different declared rates,
|
|
# agree on 1.07 units per submitted frame to three significant figures. Q1
|
|
# establishes 2 units per rendered frame for TOP-LEVEL elements
|
|
# (ui-keyframe-time-unit.md). 🟡 So either a NESTED leaf record advances at about
|
|
# HALF the top-level rate, or Q1's factor does not apply to nested records. This
|
|
# is measured, not explained, and Q1 is load-bearing enough that it deserves its
|
|
# own iteration rather than a note here.
|
|
#
|
|
# 🟡 One candidate worth recording: if the leaf advances 1 unit per 1/30 s of game
|
|
# time while VdSwap frames arrive at the ~28.1-28.5 fps this corpus measures for
|
|
# the idle title, the ratio is 30/28.5 = 1.053 -- close to the observed 1.07.
|
|
# Untested.
|
|
|
|
################################################################################
|
|
# CAN THE fps ASSUMPTION BE REMOVED? Three routes, all closed. 2026-08-30.
|
|
#
|
|
# sylpheed-port's caveat: two strips agreeing to three significant figures
|
|
# constrains the strips TO EACH OTHER, not the absolute rate -- both ratios come
|
|
# from ONE capture under ONE fps assumption, and a systematic error there scales
|
|
# both identically. Correct, and I could not remove it.
|
|
#
|
|
# ROUTE 1 -- compare the leaf against a TOP-LEVEL clock in the same capture, so
|
|
# fps cancels in the ratio. NOT AVAILABLE: on a settled title nothing top-level
|
|
# moves; that is what settled means. Every varying quad in the capture is a leaf.
|
|
# The plate looked like a candidate at 538x76 with a clean ~56-frame pulse, but
|
|
# build 2's ptbtn00 is a one-shot fade (0,0,255,255,0 at t=0,214,236,238,244) --
|
|
# the repeating pulse comes from its own nested .rat, so it is a leaf too.
|
|
#
|
|
# ROUTE 2 -- fit the same strips in the TRANSITION captures, which do contain a
|
|
# top-level clock (the fade quad, 8 declared units measured at 2.0 units/frame).
|
|
# The strips are present, but the fits are not measurements:
|
|
#
|
|
# capture strip A slope rms resid x travelled
|
|
# fadecap4 +1.943 px/f 26.70 px 147 px over 44 frames
|
|
# fadecap2 +3.566 px/f 16.75 px 147 px
|
|
# titledraw2 +4.287 px/f 3.59 px 627 px over 148 frames
|
|
#
|
|
# An rms residual of 17-27 px against 147 px of travel is scatter, not a line.
|
|
# Only titledraw2 -- 627 px of travel at rms 3.6 -- is a real fit. The apparent
|
|
# disagreement between captures is a NON-measurement, not a contradiction, and
|
|
# quoting 1.94 or 3.57 as a second sample would have been the same error as the
|
|
# 6-7 px/frame eyeball.
|
|
#
|
|
# ROUTE 3 -- read the emulator's fps from its own log. Not printed.
|
|
#
|
|
# 🟡 SO: 1.07 units/frame stands on ONE capture, exactly as sylpheed-port said. It
|
|
# rules out a per-record quirk (two strips, different cycles, same ratio) and it
|
|
# does NOT pin the absolute rate. The test that would is measuring the same strips
|
|
# at a deliberately different emulator frame rate -- if px/frame is unchanged the
|
|
# leaf is frame-locked, if it scales with 1/fps the leaf runs on wall time. That
|
|
# has not been run.
|
|
|
|
################################################################################
|
|
# THE FRAME-RATE TEST. 2026-08-30. The one clean route left.
|
|
#
|
|
# Same strips, same screen, two emulator frame rates. `--framerate_limit=15`
|
|
# against the default. That the limit took effect is visible in the boot: the
|
|
# title settled at 862 s against 241 s, 3.6x slower.
|
|
#
|
|
# ⚠️ FIRST, A GATE THIS SHOULD HAVE HAD FROM THE START. A slope is only a rate if
|
|
# the residual is random. Counting sign changes in the residual:
|
|
#
|
|
# default fps 1299x1303 slope -4.348 rms 3.33 sign-changes 43/111 OK
|
|
# 883x1134 slope +4.284 rms 3.08 sign-changes 21/76 SYSTEMATIC
|
|
# 890x1134 slope +4.284 rms 3.19 sign-changes 15/54 SYSTEMATIC
|
|
# limit 15 1299x1303 slope -2.032 rms 1.51 sign-changes 44/83 OK
|
|
# 883x1134 slope +2.003 rms 1.12 sign-changes 36/61 OK
|
|
# 890x1134 slope +1.999 rms 0.74 sign-changes 12/37 SYSTEMATIC
|
|
#
|
|
# 🔴 So one of the two strips I quoted as "agreeing to three significant figures"
|
|
# FAILS the linearity gate at default fps. The agreement was between a rate and a
|
|
# slope through a curve. sylpheed-port had already caveated that claim for a
|
|
# different reason; this weakens it further, from my own side.
|
|
#
|
|
# 📌 THE RESULT, on the one group that passes the gate at BOTH settings:
|
|
#
|
|
# default -4.348 px/frame
|
|
# framerate_limit=15 -2.032 px/frame ratio 2.14
|
|
#
|
|
# ✅ **THE LEAF IS NOT FRAME-LOCKED.** A fixed number of units per submitted frame
|
|
# predicts an unchanged px/frame. It changed by 2.14x. That hypothesis is dead.
|
|
#
|
|
# 🔴 AND 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 simple model fits
|
|
# and I do not have a third.
|
|
#
|
|
# ⚠️ REACH. The effective frame rate was NOT measured -- the instrument I added to
|
|
# time the capture window is broken: it polls for the log file, which is created
|
|
# when the capture is ARMED rather than when it completes, so it returned 0.728 s.
|
|
# The 3.6x boot slowdown says the limit took effect; it does not say fps went from
|
|
# 28 to 15. So the RATIO is measured and the ABSOLUTE rate still is not.
|
|
|
|
################################################################################
|
|
# ❔ THE LEAF'S CLOCK: UNDECODABLE, WITH REACH. Four models, four refutations.
|
|
#
|
|
# 1. FRAME-LOCKED (fixed units per submitted frame). Predicts px/frame unchanged
|
|
# under --framerate_limit. Measured -4.348 -> -2.032, a 2.14x change. REFUTED.
|
|
#
|
|
# 2. WALL-CLOCK (fixed units per real second). Predicts px/frame LARGER at a lower
|
|
# limit, since more wall time passes per frame. It got SMALLER. REFUTED by
|
|
# direction.
|
|
#
|
|
# 3. FIXED WALL-CLOCK SAMPLING -- sylpheed-port's suggestion that my samples might
|
|
# be taken at a constant real-time rate while guest time slows, which would
|
|
# reproduce the observed direction. CHECKED, NOT ASSUMED: every capture reports
|
|
# `done: ... over 150 frames` and spans frame 1..149, so the capture is indexed
|
|
# by guest VdSwap submissions in all three runs. REFUTED.
|
|
#
|
|
# 4. PER UI-DRAWING FRAME. At limit 15 only 99 of 150 frames carry UI draws
|
|
# against 131 at default, so "submitted frame" and "UI update" diverge with the
|
|
# limit. Refitting against the strip's own appearance index instead:
|
|
# default -5.773 px/appearance limit 15 -3.687 ratio 1.57
|
|
# Not invariant either. REFUTED.
|
|
#
|
|
# 🔴 AND THE TWO SLOWDOWNS STILL DISAGREE: the boot slowed 3.58x (title at 862 s
|
|
# against 241 s) while the rate ratio is 2.14 per submitted frame or 1.57 per
|
|
# appearance. Three measures of one slowdown, no two of which agree. Whatever the
|
|
# leaf's clock is, it is none of the four above, and the absolute rate stays
|
|
# unpinned.
|
|
#
|
|
################################################################################
|
|
# ✅ TWO THINGS THE SAME DATA DOES ESTABLISH.
|
|
#
|
|
# THE ROTATION IS CONFIRMED FROM THE ORACLE. sylpheed-port's export carries
|
|
# rotation_deg +30 on pteff03 and -45 on pteff03a, read from the file. The AABB
|
|
# height of a rotated quad predicts, from the DECLARED scale alone:
|
|
# pteff03 400x1080 at +30deg -> 1135.3 observed 1134 (0.12% off)
|
|
# pteff03a 400x1440 at -45deg -> 1301.1 observed 1303 (0.15% off)
|
|
# Two angles, two scales, both to better than 0.2 %. A file-side field confirmed
|
|
# by the running game, and it fixes which strip is which.
|
|
#
|
|
# 🔴 WHICH MAKES sylpheed-port's INVERSION REAL. Height 1134 IS pteff03 -- the leaf
|
|
# whose declared track is PERFECTLY linear, +4.0000 px/unit over both segments --
|
|
# and that is the strip my sign-change gate FAILS. Height 1303 is pteff03a, the
|
|
# slightly non-uniform one (-4.0667 then -4.0625), and it PASSES. So the curvature
|
|
# is in the strip whose source data is exactly straight: it is not in the disc, and
|
|
# it is either in the measurement or in how the game advances the record.
|