From 348e5d8281befece1600ec11f5c3cd0d2d023d4f Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 17:07:16 +0000 Subject: [PATCH] re: the leaf's clock is undecodable with reach -- and the rotation is confirmed 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) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/re/data/title-sweep-drawn-at-rest.txt | 46 ++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/docs/re/data/title-sweep-drawn-at-rest.txt b/docs/re/data/title-sweep-drawn-at-rest.txt index 05c53384..93625a29 100644 --- a/docs/re/data/title-sweep-drawn-at-rest.txt +++ b/docs/re/data/title-sweep-drawn-at-rest.txt @@ -150,3 +150,49 @@ # 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.