From 15702d0d051cf955078e7078e29fe46146885d0e Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Tue, 1 Sep 2026 19:42:28 +0000 Subject: [PATCH] port: the game's clock is frame-based, ours is time-based, and 60 is finally supported MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The --framerate_limit=30 run refuted the time-based reading on every discriminating row, against its author's own expectation: modal alpha step stayed 17 where time-based predicts 34, units/second halved to 30.2, the publisher dwell doubled to 8.450 s. Both controls passed FIRST -- the limiter demonstrably took effect, and all 8 splash quad rects were identical, so nothing but the frame rate differed. 255 x 1 / 15 = 17 at 28.4, 51.4 and 54.8 presents/s alike. THE GAME ADVANCES 1 UNIT PER PRESENTED FRAME. This port advances `time_units += delta * units_per_second`. Two different mechanisms that agree at exactly one frame rate -- 60 Hz, the only rate the console ever asked the game to be right at. 🔴 DO NOT MAKE THE PORT FRAME-BASED TO MATCH THE GAME, and the reason is now in authored/timing.json so nobody "fixes" it. A time-based port reproduces a 60 Hz console on hardware that is not 60 Hz; a frame-based one drifts on every machine that is not -- and this port has measured ITSELF between 9.7 and 69.4 fps depending on the renderer. Matching the game's mechanism would import a fragility the game never had to survive, because the game only ever ran on one box. ⚠️ BUT IT SHARPENS WHAT 60 CLAIMS. If units/second IS the present rate, then `keyframe_units_per_second = 60` is no longer "the unit is 1/60 s". It is "the game presented these screens at 60 Hz on the console" -- a harder statement, and checkable. ✅ And supported for the first time. Canary unlimited presents at 51-55 Hz with a splash dwell of 4.30/4.60/4.37 s. A natively 30 Hz game would present at ~30 in Canary too -- the framerate_limit run proves it, since forcing 30 made that same splash take 8.45 s. It does not take 8.45 s unforced. So the game asks for ~60. Kept as `authored`, not promoted: this is inference over three measurements rather than a measurement of units per second. It becomes `measured` when someone reads the console's present rate for these screens directly. 🔴 AND IT CLOSES THE CONSTANT AS A CAUSE OF FINDING 3, in the direction that matters. Under the frame-based model the only alternative is a 30 Hz console, which puts the plate at 236/30 = 7.87 s -- LATER than the 3.93 s shipping, not earlier. There is NO console present rate that makes the plate arrive sooner than this port already shows it. The human reported it late; no value of this constant can produce that. The method note is theirs and it is the durable part: four positions on this number were inference over a measured quantity; this one changed an input and watched what moved. The opportunistic comparison -- two captures that happened to differ -- pointed exactly the wrong way, because nothing controlled what else differed between them. One designed capture settled it against its author's expectation. Not settled: finding 3, still with no surviving cause; the clock origin, which they are taking next and which every ratio and count in this account survives; the ~1.0-1.2 menu residual; the allowance's grep trigger. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX --- authored/timing.json | 45 ++++++++++- .../port/units-per-second-switch-readiness.md | 79 ++++++++++++++++++- 2 files changed, 121 insertions(+), 3 deletions(-) diff --git a/authored/timing.json b/authored/timing.json index e760bd1b..2d6b3bee 100644 --- a/authored/timing.json +++ b/authored/timing.json @@ -215,7 +215,50 @@ "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." + "correct: a path that does not resolve does not resolve.", + "", + "✅ 2026-09-01 (settled) — THE GAME'S CLOCK IS FRAME-BASED, 1 UNIT PER PRESENT.", + "Measured by the Decoder with a DESIGNED experiment rather than an inference:", + "`--framerate_limit=30` halved units/second to 30.2, doubled the publisher dwell", + "to 8.450 s, and left the modal alpha step at 17 where a time-based clock", + "predicts 34. Both controls passed first -- the limiter demonstrably took effect,", + "and all 8 splash quad rects were identical, so nothing but the frame rate", + "differed. `255 x 1 / 15 = 17` at 28.4, 51.4 and 54.8 presents/s alike.", + "", + "⚠️ THIS CHANGES WHAT 60 MEANS HERE, AND MAKES IT MORE FALSIFIABLE. If the game", + "advances 1 unit per present, its units/second IS its present rate. So", + "`keyframe_units_per_second = 60` is now equivalent to the claim:", + "", + " the game presented these screens at 60 Hz on the console.", + "", + "That is a sharper statement than 'the unit is 1/60 s' and it is checkable.", + "", + "✅ AND IT IS SUPPORTED, which the constant has not been until now. Canary", + "unlimited presents at 51-55 Hz and the splash dwell is 4.30/4.60/4.37 s over", + "three cold boots. A natively 30 Hz game would present at ~30 in Canary too --", + "which the framerate_limit run confirms, since forcing 30 made the same splash", + "take 8.45 s. It does not take 8.45 s unforced. So the game asks for ~60, not 30.", + "", + "🔴 AND THAT CLOSES THE CONSTANT AS A CAUSE OF 'THE PLATE IS LATE', for a NEW", + "reason and in the direction that matters. Under the frame-based model the only", + "alternative console rate is 30 Hz, which puts the plate at 236/30 = 7.87 s --", + "LATER than the 3.93 s the port ships, not earlier. There is no console present", + "rate that makes the plate arrive sooner than it already does here.", + "", + "⚠️ KEPT AS `authored`, NOT PROMOTED TO `measured`. The chain is inference over", + "three measurements (frame-based clock; Canary's unlimited present rate; the", + "dwell corpus) rather than a measurement of units per second. It becomes", + "`measured` the day someone reads the console's present rate for these screens", + "directly.", + "", + "📌 AND THE PORT'S OWN DESIGN IS DELIBERATELY NOT THE GAME'S, which is worth", + "stating so nobody 'fixes' it. The game is frame-based; this port is time-based", + "(`time_units += delta * units_per_second`). They agree at 60 fps, which is the", + "only rate the console ever asked the game to be right at. A time-based port", + "reproduces a 60 Hz console on hardware that is not 60 Hz; a frame-based port", + "would drift on every machine that is not -- and this port has measured itself at", + "9.7 to 69.4 fps depending on the renderer. DO NOT make the port frame-based to", + "match the game." ], "kind": "authored", "source": "docs/re/ui-keyframe-time-unit.md, docs/port/HANDOFF.md", diff --git a/docs/port/units-per-second-switch-readiness.md b/docs/port/units-per-second-switch-readiness.md index 4cb72b71..f6336708 100644 --- a/docs/port/units-per-second-switch-readiness.md +++ b/docs/port/units-per-second-switch-readiness.md @@ -1,7 +1,9 @@ # If 120 units/s is right, the switch is one constant — audited, and pre-registered -**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. +**Status:** ✅ **SETTLED by a designed experiment.** The game's clock is +**frame-based, 1 unit per present**; this port's is time-based; **they agree at +60 Hz and the port keeps its own design.** 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 @@ -279,3 +281,76 @@ established from this side rather than assumed. 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. + + +--- + +# ✅ Settled: the game is frame-based, the port is time-based, and that is correct + +`--framerate_limit=30` — the run this page asked for — refuted the time-based +reading on every discriminating row, **against its author's own expectation**: + +| | predicted if time-based | **measured at 30 fps** | +|---|---|---| +| modal alpha step | 34 | **17** (unchanged) | +| units/second | 60 | **30.2** (halved) | +| publisher dwell | 4.25 s | **8.450 s** (doubled) | + +Both controls passed *first*: the limiter demonstrably took effect (28.4 +presents/host-s against 51–55, interval mass moving to two vblanks, 422 of 468), +and all 8 splash quad rects were identical, so nothing but the frame rate +differed. **`255 × 1 / 15 = 17`** at 28.4, 51.4 and 54.8 presents/s alike. + +## What that changes for the port: nothing — but for a reason worth writing down + +The game advances **1 unit per presented frame**. This port advances +`time_units += delta * units_per_second`. **They are different mechanisms that +agree at exactly one frame rate: 60 Hz** — which is the only rate the console +ever asked the game to be right at. + +🔴 **Do not make the port frame-based to match the game.** A time-based port +reproduces a 60 Hz console on hardware that is not 60 Hz; a frame-based one would +drift on every machine that is not — and this port has measured *itself* between +**9.7 and 69.4 fps** depending on the renderer. Matching the game's mechanism +would import a fragility the game never had to survive, because the game only +ever ran on one box. + +## 🔴 But it sharpens what `60` is claiming, and makes it falsifiable + +If units/second **is** the present rate, then `keyframe_units_per_second = 60` is +no longer "the unit is 1/60 s". It is: + +> **the game presented these screens at 60 Hz on the console.** + +That is a harder claim and a checkable one. **It is also supported for the first +time:** Canary unlimited presents at 51–55 Hz and the splash dwell is +4.30 / 4.60 / 4.37 s over three cold boots. A natively 30 Hz game would present +at ~30 in Canary too — the `--framerate_limit` run proves it, since forcing 30 +made that same splash take 8.45 s. **It does not take 8.45 s unforced.** + +⚠️ Still `authored`, not promoted to `measured`: this is inference over three +measurements rather than a measurement of units per second. It becomes `measured` +when someone reads the console's present rate for these screens directly. + +## And it closes the constant as a cause of finding 3 — in the direction that matters + +| console rate | units/s | plate `t=236` | +|---|---|---| +| 30 Hz | 30 | **7.87 s** | +| **60 Hz (shipping)** | **60** | **3.93 s** | + +Under the frame-based model the only alternative is 30 Hz, and it puts the plate +**later**, not earlier. **There is no console present rate that makes the plate +arrive sooner than this port already shows it.** The human reported it arriving +late; no value of this constant can produce that. + +## The method note, and it is theirs + +> *Four of my positions on this number were inference over a measured quantity; +> this one changed an input and watched what moved.* + +The opportunistic comparison — two captures that happened to differ — pointed +**exactly the wrong way**, because nothing controlled what else differed between +them. One designed capture settled it against its author's expectation. That is +the difference between an observation and an experiment, and it cost this pair +five positions in a day to relearn.