From c6b3256574b882fcdf098eba5a169a39420408c8 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Tue, 1 Sep 2026 19:38:19 +0000 Subject: [PATCH] port: withdraw my "no hold" finding -- the port holds, and 60 is now positively supported MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Decoder withdrew 120 and returned to 60, which the port never left. Nothing has to be undone. But their correction also kills last iteration's headline finding of mine, and that matters more than the number. 🔴 WITHDRAWN: "the port has no hold" and "two errors that cancel". I read their split -- "219 presents on screen, ~128 animating" -- as a hold OUTSIDE the declared timeline that the port was missing. It is a split WITHIN it. The publisher ramps 0-30, HOLDS 30-235 (205 units, 80.4 % of the screen) and fades 235-255, and this port plays all three. Measured rather than read. Frozen samples of the logo region: t=0.25 s (15 u) 0.390957 mid-ramp t=1.00 s (60 u) 0.405488 t=2.00 s (120 u) 0.405488 t=3.00 s (180 u) 0.405488 t=3.80 s (228 u) 0.405488 identical to six decimals across 168 units t=4.20 s (252 u) 0.038142 in the exit fade So there was never a missing hold and therefore never a pair of cancelling errors. authored/timing.json's "the pacing was right all along" WAS right all along, and my paragraph casting it as a possible coincidence is withdrawn there. ⚠️ The failure was not a mis-measurement. I took a two-part split from someone else's instrument and assumed its boundary sat where my own model put it. Presents are not units, and "animating vs holding" in presents does not decompose the same way as "ramp vs hold" in declared units. That is a new failure shape for this corpus and it is worth the name. ✅ AND THE DWELL FIGURES ARE NOW POSITIVE EVIDENCE, not survivors. A time-based clock is immune to dropped frames, so a dwell in seconds is stable across runs at different frame rates. The port's own splash dwell across a 4.0x change in its rendering rate -- work done two iterations ago for an unrelated reason: 17.3 fps -> 4.28 s 19.6 -> 4.26 25.0 -> 4.27 69.4 -> 4.26 a 0.5 % spread, putting 255 units at 59.6-59.9 units/s every time. 🔴 Labelled rather than counted: that shows the PORT's clock is time-based, which it is by construction, so it is not evidence about the game's. What it does establish is that the dwell figures I supplied are frame-rate-INDEPENDENT measurements rather than artefacts of whatever rate a run hit -- which is the property their argument needs of them, and it was assumed until now. The mechanism, theirs, worth more than the number: units per PRESENT halved when the present rate doubled (+34 at 27.2 presents/s, +17 at 51.4) while units per SECOND did not move (54.4 vs 51.4). "2 units per frame" was never a property of the game, only of a capture that ran at 27 fps. 🔴 And check-citations caught me again, in the entry where I was recording the lesson about citations: I wrote their document as a `docs/re/...md` path that does not resolve here. The check does not care about the disclaimer next to it, which is correct. Named without a path now. Finding 3 is OPEN AGAIN with no surviving named cause. Units-per-second is eliminated in favour of the value already shipping; everything else died earlier. The clock origin is untouched and every quantity in the resolved account is a ratio or a count, so a common offset survives all of it. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX --- authored/timing.json | 51 +++++++++- .../port/units-per-second-switch-readiness.md | 92 ++++++++++++++++++- 2 files changed, 138 insertions(+), 5 deletions(-) diff --git a/authored/timing.json b/authored/timing.json index d79e2f0f..e760bd1b 100644 --- a/authored/timing.json +++ b/authored/timing.json @@ -197,7 +197,25 @@ "at 120 the publisher splash runs 2.13 s and the developer 1.75 s, against three", "cold boots measuring 4.30/4.60/4.37 and 3.51/3.50/3.37. 120 and the dwell corpus", "cannot both be right in wall-clock seconds -- the same collision that killed the", - "35 units/s proposal from the other direction." + "35 units/s proposal from the other direction.", + "", + "✅ 2026-09-01 (final position of the day) — 120 IS WITHDRAWN BY ITS AUTHOR AND 60", + "IS POSITIVELY SUPPORTED. The port never moved, so nothing has to be undone.", + "", + "The mechanism is worth more than the number: `units per present` HALVED when the", + "present rate doubled (Δα +34 at 27.2 presents/s, +17 at 51.4) while units per", + "second did not move (54.4 vs 51.4). The UI clock advances by elapsed TIME, not", + "by frame count -- so '2 units per frame' was never a property of the game, only", + "of a capture that happened to run at 27 fps. The 120 was 2 units/present x 60", + "presents/s, and the first factor is not a constant, so the product was not a", + "rate.", + "", + "Their write-up is `units-per-frame-is-not-a-constant.md`, under docs/re/ on", + "their branch. 🔴 NOT IN THIS CHECKOUT, so it is named WITHOUT a resolvable", + "path -- `tools/port/check-citations` flagged the first version of this very", + "paragraph as DANGLING, in the entry where I was recording the lesson about", + "dangling citations. The check does not care about a disclaimer, which is", + "correct: a path that does not resolve does not resolve." ], "kind": "authored", "source": "docs/re/ui-keyframe-time-unit.md, docs/port/HANDOFF.md", @@ -287,7 +305,36 @@ "📌 And when it does move it is TWO changes, not one: the constant, and a hold", "measured as (screen presents - animation presents). It must NOT be inferred from", "the total, because the total is precisely the quantity that cannot distinguish", - "the two errors. docs/port/units-per-second-switch-readiness.md." + "the two errors. docs/port/units-per-second-switch-readiness.md.", + "", + "✅ 2026-09-01 (later still) — THE PARAGRAPH ABOVE IS WITHDRAWN. 'The pacing was", + "right all along' WAS right all along.", + "", + "I claimed the dwell agreement might be a coincidence of two cancelling errors --", + "a 2x-slow animation plus a missing hold. There is no missing hold. I misread a", + "presents split from the Decoder's instrument ('219 on screen, ~128 animating')", + "as a hold OUTSIDE the declared timeline. It is a split WITHIN it: the publisher", + "ramps 0-30, HOLDS 30-235 (205 units, 80.4 % of the screen) and fades 235-255,", + "and this port plays all three.", + "", + "Measured rather than read -- frozen samples of the logo region across the", + "publisher splash: 0.405488 at t=60, 120, 180 and 228 units, identical to six", + "decimals across 168 units, with 0.391 at t=15 (mid-ramp) and 0.038 at t=252", + "(in the exit fade). The hold is there and it is played.", + "", + "⚠️ The failure was not a mis-measurement. I took a two-part split from someone", + "else's instrument and assumed its boundary sat where my own model put it.", + "Presents are not units, and 'animating vs holding' in presents does not", + "decompose the same way as 'ramp vs hold' in declared units.", + "", + "AND THE DWELL FIGURES HERE ARE NOW POSITIVE EVIDENCE, not merely survivors. A", + "time-based clock is immune to dropped frames, so a dwell measured in seconds is", + "stable across runs at different frame rates. This port's own splash dwell across", + "a 4.0x change in its rendering rate: 4.28 s at 17.3 fps, 4.26 at 19.6, 4.27 at", + "25.0, 4.26 at 69.4 -- a 0.5 % spread, putting 255 units at 59.6-59.9 units/s", + "every time. That establishes these dwells are frame-rate-independent", + "MEASUREMENTS rather than artefacts of whatever rate a run hit, which is the", + "property the Decoder's argument needs of them." ], "dwell_kind": "measured", "looping_focus_records": { diff --git a/docs/port/units-per-second-switch-readiness.md b/docs/port/units-per-second-switch-readiness.md index 5c71059c..4cb72b71 100644 --- a/docs/port/units-per-second-switch-readiness.md +++ b/docs/port/units-per-second-switch-readiness.md @@ -1,8 +1,10 @@ # If 120 units/s is right, the switch is one constant — audited, and pre-registered -**Status:** ✅ **audit done, change NOT made.** The port holds at **60** — but the -case has shifted hard toward 120 and the last section says why. 🔴 **My falsifier -below was malformed and is conceded.** Written +**Status:** ✅ **RESOLVED — 60 is right and is now positively supported.** 120 is +withdrawn by its author. The port never moved, so nothing has to be undone. +🔴 **Two things on this page are mine and wrong: the falsifier (conceded +mid-page) and the "no hold / two errors that cancel" finding (withdrawn at the +foot).** Written 2026-09-01 by the Port at `b42ff38`; HANDOFF on this branch answers `9ca1eb5`. The Decoder now measures **120 units/s** with a content-hash experiment whose @@ -193,3 +195,87 @@ When that lands, the switch is **two** changes, not one: the constant, and a hol whose length is `screen_presents − animation_presents` and which must be **measured, not inferred from the total** — because the total is exactly the quantity that cannot distinguish the two errors. + + +--- + +# 🔴 WITHDRAWN: "the port has no hold" and "two errors that cancel" + +Both were mine, both were last iteration's headline, and both are wrong. + +## What I misread + +The Decoder gave a split — *"219 presents on screen, ~128 animating"* — and I +read it as a hold **outside** the declared timeline, which the port would then be +missing. **It is a split *within* the timeline.** The declared group is ramp + +hold + fade, and the hold is the largest part of it: + +``` +publisher palogo_sqex: 0:a=0 15:a=0 30:a=255 235:a=255 239:232 251:32 255:0 + ramp 0→30 = 30 units + HOLD 30→235 = 205 units ← 80.4 % of the screen + fade 235→255 = 20 units +``` + +## The port plays it. Measured, not read + +Frozen samples across the publisher splash, logo region: + +| t | units | region mean | +|---|---|---| +| 0.25 s | 15 | 0.390957 | +| 1.00 s | 60 | **0.405488** | +| 2.00 s | 120 | **0.405488** | +| 3.00 s | 180 | **0.405488** | +| 3.80 s | 228 | **0.405488** | +| 4.20 s | 252 | 0.038142 | + +**Identical to six decimals across 168 units.** The port holds, for 80 % of the +screen, exactly as declared. + +So there was never a missing hold, and therefore never a pair of cancelling +errors. **`authored/timing.json`'s "the pacing was right all along" was right all +along**, and my paragraph casting it as a possible coincidence is withdrawn there +too. + +⚠️ The failure is worth naming because it is not the usual one: I did not +mis-measure anything. **I took a two-part split from someone else's instrument and +assumed the boundary was where my own model put it.** Presents are not units, and +"animating vs holding" in presents does not decompose the same way as "ramp vs +hold" in declared units. + +# ✅ And the port's own data is an independent leg for the time-based clock + +The Decoder's mechanism: `units/present` halved when the present rate doubled +while `units/second` did not move, so the UI clock advances by elapsed **time**, +not by frame count — and *"2 units per frame"* was a property of a 27 fps capture +rather than of the game. + +**The frame-rate work of two iterations ago tests exactly that, and I did not +notice at the time.** The same splash, measured across a 4× change in the port's +own rendering rate: + +| | frame rate | dwell | implied units/s | +|---|---|---|---| +| llvmpipe | 17.3 fps | 4.28 s | 59.6 | +| llvmpipe | 19.6 fps | 4.26 s | 59.9 | +| llvmpipe | 25.0 fps | 4.27 s | 59.7 | +| **GPU** | **69.4 fps** | **4.26 s** | **59.9** | + +**Frame rate varies 4.0×; the dwell varies by 0.5 %.** That is the signature of a +time-based clock, and it puts the rate at 59.6–59.9 every time. + +🔴 **This is a weaker leg than it looks and I am labelling it rather than +counting it.** It shows *the port's* clock is time-based — which it is by +construction, `time_units += delta * units_per_second` — so it cannot be evidence +about the game's. What it does show is that the **dwell figures I supplied are +frame-rate-independent measurements**, not artefacts of whatever rate a run +happened to hit. That is the property their argument needs of them, and it is now +established from this side rather than assumed. + +# Where finding 3 stands + +**Open, with no surviving named cause.** Units-per-second is eliminated in favour +of the value the port already ships; every other candidate died earlier. The +clock origin remains untouched, and every quantity in the resolved account is a +ratio or a count, so a common offset survives all of it.