fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

port: the game's clock is frame-based, ours is time-based, and 60 is finally supported

Browse Source 
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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
This commit is contained in:
Sylpheed port agent
2026-09-01 19:42:28 +00:00
parent c6b3256574
commit 15702d0d05
2 changed files with 121 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
authored/timing.json
View File

@@ -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",

79
docs/port/units-per-second-switch-readiness.md
View File

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