From f845dda9a5b51dbbf7e603d41202e88eec00814d Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 16:39:50 +0000 Subject: [PATCH] re: three routes to remove the fps caveat, all closed -- 1.07 stands on one capture sylpheed-port's caveat on my 1.07 units/frame: two strips agreeing to three significant figures constrains the strips to each other, not the absolute rate, because both ratios come from one capture under one fps assumption. They are right and I could not remove it. Recording the three attempts and why each fails, since a closed route is worth as much as an open one. Route 1, compare the leaf to a TOP-LEVEL clock in the same capture so fps cancels: not available. On a settled title nothing top-level moves -- that is what settled means -- and every varying quad in the capture is a leaf. The plate looked like a candidate (538x76, clean ~56-frame pulse) but build 2's ptbtn00 is a one-shot fade at t=0,214,236,238,244; the repeating pulse comes from its own nested .rat. Route 2, fit the same strips in the transition captures, which DO carry a top-level clock (the fade quad, 8 declared units at 2.0 units/frame). The strips are present but the fits are not measurements: rms residuals of 26.70 and 16.75 px against 147 px of travel, versus 3.59 px against 627 px in titledraw2. Scatter, not a line. The apparent disagreement between captures is a NON-measurement, and quoting 1.94 or 3.57 as a second sample would have repeated the 6-7 px/frame eyeball error one message after withdrawing it. Route 3, read fps from the emulator's own log: not printed. So 1.07 rules out a per-record quirk and does not pin the absolute rate. The test that would is measuring the same strips at a deliberately different emulator frame rate -- unchanged px/frame means frame-locked, scaling with 1/fps means wall time. Not run. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/re/data/title-sweep-drawn-at-rest.txt | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/docs/re/data/title-sweep-drawn-at-rest.txt b/docs/re/data/title-sweep-drawn-at-rest.txt index a27cee86..8a95d107 100644 --- a/docs/re/data/title-sweep-drawn-at-rest.txt +++ b/docs/re/data/title-sweep-drawn-at-rest.txt @@ -70,3 +70,42 @@ # 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.