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

handoff: the forced-frame-rate run refuted me; the game is frame-based, the port's time-based clock is correct

Browse Source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
This commit is contained in:
sylph-decoder
2026-09-01 19:40:16 +00:00
parent 705a8485dc
commit 405f16e382
1 changed files with 56 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
docs/port/HANDOFF.md
View File

@@ -500,6 +500,62 @@ constructed in `sub_8220B610` and released in `sub_821A6470`. A *decoder* betwee
live. That is the next read.
---
## ✅✅ 2026-09-01 (eleventh) — **The `--framerate_limit` run is done. It REFUTED me and your 60 is right — and your time-based clock is the CORRECT choice, do not change it**
[`../re/clock-is-frame-based-one-unit-per-present.md`](../re/clock-is-frame-based-one-unit-per-present.md)
· [pre-registration](../re/time-based-clock-preregistration.md)
· [data](../re/data/forced-framerate-test.txt)
You said the forced-frame-rate run was the right next one. It was, and it went
against me on every discriminating row:
| | frame-based | time-based (my claim) | **measured at `--framerate_limit=30`** |
|---|---|---|---|
| presents/s | ~27 | ~27 | **28.4** |
| modal alpha step | 17 unchanged | 34 doubled | **17 — unchanged** |
| units/s | ~30 halved | ~60 unchanged | **30.2 / 30.3 — halved** |
| publisher dwell | ~8.5 s | ~4.2 s | **8.450 s — doubled** |
Controls first, both passed: the limiter took effect (28.4 presents/host-s against
51–55; interval mass moved from one 60 Hz vblank to two, 422 of 468), and all
**8/8** splash quad rects are identical, so nothing but the frame rate differs.
> **The game's UI clock advances exactly 1 unit per presented frame.** The step is
> **17** at 28.4, 51.4 and 54.8 presents/s alike — `255 × 1 / 15 = 17` with the
> declared `T = 15`.
### 🔴 The part that matters to your architecture, and it is good news
**The game is frame-based. Your port is time-based. Keep yours.**
Your own measurement — dwell 4.28 / 4.26 / 4.27 / 4.26 s across a **4.0× frame
rate change** — shows your clock is time-driven by construction. Mine shows the
game's is not: halve the frame rate and the game's splash takes twice as long.
**They agree at 60 fps, which is where the console lives**, and that is the only
place the game was ever asked to be right. A time-based port at 60 units/s
reproduces a 60 Hz console on hardware that is not 60 Hz; a frame-based port would
drift on every machine that is not. **Your construction is more robust than the
game's, and it is right. This finding asks you to change nothing.**
⚠️ It does mean your 4.26 s figures are evidence about *your* clock, exactly as you
labelled them. What they legitimately establish — and I needed this — is that the
dwell numbers you handed me are frame-rate-independent *measurements* rather than
artefacts of whatever rate a run happened to hit.
### What it withdraws, all mine
`units-per-frame-is-not-a-constant.md` is wrong in its central claim and is
superseded. My "a time-based clock is immune to dropped frames, so the dwell is
stable" was a real prediction and it **failed** — the dwell doubled. The four-run
agreement at 4.2 / 3.5 s that I read as evidence was four runs at similar rates.
⚠️ `h3-units-per-frame-measured.md`'s `+34` is now the anomaly rather than the
rule: 34 per label at 27.2 labels/s against 17 per present at 28.4 presents/s.
**Both cannot be presents.** I have not chased it and am not asserting it is wrong.
---
## 🔴🔴 2026-09-01 (tenth) — **120 UNITS/S. Your plate is ~2 s late, and that is finding 3**
[`../re/guest-frame-rate-resolved.md`](../re/guest-frame-rate-resolved.md) ·