c1c8aa4288
The Port's arithmetic was right: a 160-unit sub-interval cannot outlast the 210-unit group containing it, and my hold (4.514 s) outlasted three cold-boot measurements of the whole group (3.37/3.50/3.51 s). My own capture says why, once asked the right question. The three numbers I quoted came from three regions of ONE run, and I never asked how fast the emulator was going in each: splash B (the hold) 3.39 labels/guest-second -> I reported 35.4 splash A (publisher) 15.33 -> I reported 40.0 the title (the plate) 23.20 -> I reported 56.8 Monotonic. The 'per-GamePart rate' is the pacing of the region it was measured in. Splash B was captured at 3.4 fps, an eighth of the title region. And the corpus already had this. boot-splash-dwells-are-declared.md says in its own words that the wall-clock dwell is an emulator-pacing artefact that varies run to run, with a no-input boot 15-20% long on the same declared timeline. I re-derived a documented artefact as a discovery and drew a false conclusion from it. The instrument lesson, which is the part worth keeping: I believed the guest timebase removed the artefact. It does not. The game's animation clock is not the guest timebase -- it is frame-coupled -- so a slow run advances less animation per guest second and no clock can see that from inside. My control asked 'does this timebase track real time', which is capability. The question that mattered was 'is the quantity I divide by coupled to the frame rate', and nothing I ran asked it. That is PROTOCOL's own warning, which I quoted at the other agent two iterations ago and then walked into. Restated: the clock is neither purely frame-counted (21 vs 33 labels for one animation) nor purely time-integrated (rate scales with frame rate). Consistent with a clamped per-frame delta, untested, and now the real open question. Consequence: no rate measured on this emulator is the console's; all are biased low. Best estimate stays the declared timeline against the fastest runs -- 60 units/s, 1.1% on the developer splash. The port keeps 60 for every screen and nothing needs averaging. Untouched: section 1 of splash-declared-vs-captured.md. It compares a disc table against vertex alphas at integer t and never divides by a duration, so the pacing artefact cannot reach it.
118 lines
5.5 KiB
Markdown
118 lines
5.5 KiB
Markdown
# 🔴 WITHDRAWN — "the unit rate is per-GamePart". It was the emulator's frame rate, and the corpus already said so
|
||
|
||
**Status: ❌ my claim, refuted within the hour, by the Port's arithmetic and then
|
||
by my own data.** 2026-09-01. Instrument: ⟨capture⟩ — the same capture that
|
||
produced the claim.
|
||
|
||
Withdraws the second half of
|
||
[`splash-declared-vs-captured.md`](splash-declared-vs-captured.md) and the
|
||
`35–40 units/s` figure I put in `HANDOFF.md`. **§1 of that page — the declared
|
||
timeline reproducing the capture to one alpha level — is untouched and stands.**
|
||
|
||
---
|
||
|
||
## The challenge that was right
|
||
|
||
The Port pointed out that my 160-unit hold is **inside** the developer splash's
|
||
declared 210-unit group, and that
|
||
|
||
| | measured | implies |
|
||
|---|---|---|
|
||
| the 160-unit hold (mine, 1 run) | 4.514 guest s | 35.4 units/s |
|
||
| the 210-unit group containing it | 3.37 / 3.50 / 3.51 s, 3 cold boots | 60.7 units/s |
|
||
|
||
**A sub-interval cannot outlast the interval containing it.** That is not a
|
||
preference, it is arithmetic, and it is correct.
|
||
|
||
## What my own capture says when asked the right question
|
||
|
||
The three numbers I quoted came from three different regions of one run. I never
|
||
asked how fast the emulator was running in each:
|
||
|
||
| region the number came from | **labels / guest second** | "rate" I reported |
|
||
|---|---|---|
|
||
| splash B — the hold | **3.39** | 35.4 |
|
||
| splash A — the publisher ramp | **15.33** | 40.0 |
|
||
| the title — the plate | **23.20** | **56.8** |
|
||
|
||
**Monotonic. The "rate" I measured is a function of how fast the emulator was
|
||
going, not of which `GamePart` was running.** Splash B was captured at 3.4
|
||
frames per second — roughly an eighth of the title region — and that is the
|
||
entire "per-GamePart" effect.
|
||
|
||
## The corpus already had this, and I re-derived it as a discovery
|
||
|
||
[`boot-splash-dwells-are-declared.md`](https://git.mc02.dev/fabi/Sylpheed) (on
|
||
`auto/no-disc-and-menu-captures`) says it in its own words:
|
||
|
||
> A fresh no-input boot … puts the same two dwells at **5.10–5.61 s** and
|
||
> **3.83–4.30 s** — 15–20 % longer than both the declared values and the corpus's
|
||
> three runs, on the same disc and the same declared timeline. **So the wall-clock
|
||
> dwell is an emulator-pacing artefact that varies run to run.**
|
||
|
||
My developer-splash group took **5.189 guest seconds** against a declared 3.500.
|
||
That is the same artefact, further out because my run was slower still. **I turned
|
||
a documented artefact into a new finding**, which is precisely what INDEX's
|
||
"re-deriving a ✅ row is not a finding" exists to stop — and worse than a
|
||
duplicate, because the conclusion was false.
|
||
|
||
## 🔴 The instrument lesson, which is the part worth keeping
|
||
|
||
**I believed the guest timebase removed the pacing artefact. It does not.**
|
||
|
||
`Clock::QueryGuestTickCount()` is the right instrument for *"how much time passed"*
|
||
and I control-verified it: 123.24 guest seconds across ~118 wall seconds. That
|
||
control was sound and it verified the wrong thing. **The game's animation clock is
|
||
not the guest timebase** — it is frame-coupled, so a slow run advances less
|
||
animation per guest second, and no clock measurement can see that from inside.
|
||
|
||
This is `PROTOCOL.md`'s own warning, which I quoted at another agent two
|
||
iterations ago and then walked into:
|
||
|
||
> ⚠️ **A control verifies CAPABILITY, not CONFIGURATION.**
|
||
|
||
My control asked *"does this timebase track real time?"*. The question that
|
||
mattered was *"is the quantity I am dividing by coupled to the frame rate?"*, and
|
||
nothing I ran asked it.
|
||
|
||
## What is actually true about the clock, restated
|
||
|
||
Two observations that both stand, and they are not the same thing:
|
||
|
||
* **Not purely frame-counted** — the same animation occupied 21 labels in one
|
||
capture and 33 in another.
|
||
* **Not purely time-integrated** — the effective rate scales with the run's frame
|
||
rate, 3.39 → 15.33 → 23.20 labels/s giving 35 → 40 → 57 units/s.
|
||
|
||
🟡 **Consistent with a per-frame delta that is limited or clamped**, which is also
|
||
what the earlier "long frames advance less than a constant rate predicts"
|
||
residual looked like. **Untested**, and it is now the actual open question.
|
||
|
||
📌 **Consequence: no rate measured on this emulator is the console's.** Every one
|
||
of them is biased **low**, by an amount set by that run's pacing. The best estimate
|
||
is therefore *not* a capture at all — it is the **declared timeline against the
|
||
fastest, most nearly real-time runs**, which is the corpus's existing result:
|
||
**60 units/s**, developer splash 3.500 s declared against 3.51/3.50 measured,
|
||
**1.1 %**.
|
||
|
||
## What the port should do
|
||
|
||
**Keep 60 units/s, for every screen.** Unchanged from before I raised this.
|
||
|
||
* The `35–40` figure is withdrawn.
|
||
* The structural claim *"one rate cannot cover every screen"* is **not
|
||
established**. The title's 56.8 is 5 % from 60 and biased low by its own pacing;
|
||
that is inside the artefact, not evidence against a single rate.
|
||
* Nothing needs splitting or averaging. There was one number.
|
||
|
||
## What survives
|
||
|
||
* ✅ **§1 of `splash-declared-vs-captured.md`** — the declared timeline reproduces
|
||
the captured splash to **one alpha level in 255**. That test compares a disc
|
||
table against vertex alphas at *integer t* and never divides by a duration, so
|
||
the pacing artefact cannot touch it. It is why the Port's splash keyframes are
|
||
confirmed right.
|
||
* ✅ The `T` values read off the disc — plate 22, splash logos and glows 15.
|
||
* ✅ The method notes on `units-per-second-measured.md`: drop the clamped final
|
||
step, and the guest timebase is the right instrument *for elapsed time*.
|