Sylpheed/docs/re/data/title-sweep-drawn-at-rest.txt

# 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.

################################################################################
# ✅ SETTLED 2026-08-30 -- and the hypothesis in this file is REFUTED.
# See data/title-sweep-jp-draw-capture.txt and structures/plate-pulse-phase-lock.md.
#
# The leaves ARE drawn on the JP title -- same three ROT strips, same
# dimensions, at HIGHER alpha than English. There is no occlusion and no
# absence.
#
# The 0.32-vs-11.9 tension that motivated the hypothesis was not a fact about
# the game at all: both JP captures were shuttered on the plate pulse, which
# phase-locks the shutter to the animation (25-26 px apart on a ~1600 px
# traverse). 11.9 is the honest number; 0.32 is the gate.