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

re: WITHDRAW 'the unit rate is per-GamePart' -- it was the emulator's frame rate

Browse Source 
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.
This commit is contained in:
sylph-decoder
2026-09-01 17:29:52 +00:00
parent 12952a87de
commit 1e7343e7ac
3 changed files with 133 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/re/INDEX.md
View File

@@ -137,7 +137,8 @@ files, which is how the same ground got covered twice.
| [`structures/stage-mission-tables.md`](structures/stage-mission-tables.md) | The stage table set — phases, routes, sub-objectives and AI parameters | ✅ the table set and how the stage record reaches it, validated across; **`AIParams` disc-wide: 23 objects, one shared 34-profile roster (782 records), loader `sub_8233C368`; `Type`→field-count holds except the two `_Test` templates** |
| [`structures/texture-color-k8888.md`](structures/texture-color-k8888.md) | Texture colour interpretation — `k_8_8_8_8` (32bpp UI/HUD textures) | — |
| [`ui-keyframe-time-unit.md`](ui-keyframe-time-unit.md) | What a keyframe time is worth, and what shape the ramp has | ✅ CONFIRMED from the running game's own draw stream — the ramp is **linear** (a declared 15-unit fade lands on `round(255·k/15)` for all seven samples) and the animation clock advances **2 time units per submitted frame**. 🟡 the seconds conversion (`1 unit = 1/60 s`) rests on a measured 27.6 present-frames/second |
| [`splash-declared-vs-captured.md`](splash-declared-vs-captured.md) | Does the declared keyframe timeline reproduce the captured splash, and is the unit rate global? | ✅ **YES, to ONE alpha level, 2026-09-01** — settles the R1-re-opened 🟡 `⟨our-reader⟩` entry with a disc-table-vs-vertex-stream comparison, **no renderer in the chain**. 50 captured alphas: 39 exact under truncation (30 under rounding), **max error 1 level in 255 (0.39 %)**, and all 11 non-exact are low by exactly 1 on falling segments. The old ❌ rested on an `a=32` that the fixed record layout puts at t=206, four units from the end. 🔴 **AND: the unit→seconds rate is PER-GAMEPART.** Title ~**57** units/guest-second; splash **~35–40**, confirmed two ways sharing no algebra — a 15-unit ramp *and* a **160-unit hold**, which has no `T` in it. The near-equal α/s across all four elements (650–679) is a coincidence: `T` 22-vs-15 and rate 57-vs-37 nearly cancel. ⚠️ A single `keyframe_units_per_second` is wrong; a splash played at 60 runs **1.5–1.7× too fast**. Classified **measured** — nothing on the disc states a rate. |
| [`splash-declared-vs-captured.md`](splash-declared-vs-captured.md) | Does the declared keyframe timeline reproduce the captured splash, and is the unit rate global? | ✅ **YES, to ONE alpha level, 2026-09-01** — settles the R1-re-opened 🟡 `⟨our-reader⟩` entry with a disc-table-vs-vertex-stream comparison, **no renderer in the chain**. 50 captured alphas: 39 exact under truncation (30 under rounding), **max error 1 level in 255 (0.39 %)**, and all 11 non-exact are low by exactly 1 on falling segments. The old ❌ rested on an `a=32` that the fixed record layout puts at t=206, four units from the end. ❌ **The per-GamePart RATE claim on this page is WITHDRAWN** — see [`splash-rate-withdrawn.md`](splash-rate-withdrawn.md). The three rates came from three regions of one run at 3.39 / 15.33 / 23.20 labels per guest second and order the same way; it is emulator pacing, already documented in `boot-splash-dwells-are-declared.md`. **60 units/s stands for every screen.** §1 above is untouched — it compares a disc table against vertex alphas at integer t and never divides by a duration. |
| [`splash-rate-withdrawn.md`](splash-rate-withdrawn.md) | Why my per-GamePart rate was the emulator's frame rate | ❌ **my claim, refuted within the hour** — by the Port's arithmetic (a 160-unit sub-interval cannot outlast the 210-unit group containing it) and then by my own capture: the three regions ran at **3.39 / 15.33 / 23.20 labels per guest second** and produced 35 / 40 / 57 units/s, monotonically. 🔴 **Instrument lesson:** the guest timebase does NOT remove the pacing artefact — the game's animation clock is frame-coupled, so a slow run advances less animation per guest second. My control verified that the timebase tracks real time, which is capability, not the configuration that mattered. **No rate measured on this emulator is the console's; all are biased low.** The best estimate stays the declared timeline against the fastest runs: **60 units/s**. |
| [`units-per-second-measured.md`](units-per-second-measured.md) + [pre-reg](units-per-second-preregistration.md) | Is the animation clock frame-counted or time-integrated, and at what rate | 🟡 **half-answered, 2026-09-01, one prediction HELD and one FAILED.** ✅ **The clock is NOT frame-counted**: the same animation takes 21 labels in one capture and 33 in another, and splash A's logo steps `+136,+34` in one and `+17,+51,+34,+34,+17,+17` in the other. Steps are always integer multiples of **17** (255/15 = one unit), so the clock advances in whole units at a rate set by frame duration. 📌 **This retires "2 units per submitted frame" as a MECHANISM** — 2 was that run's frame pacing, so `units = 2 × frames` computes an emulator artefact. ✅ **RESOLVED later the same iteration: 56.8 units per guest second**, on `ptbtn00`'s ramp with the clamped final step excluded, `T=22` attested by two readers with no clock in the chain — **inside the pre-registered 55–65 band; 30 and 120 both excluded**. Control passed at **1.15 %**: `ptcopyright` gives 650.4 α/s against the plate's 657.9, implying its own `T=22.25`. The earlier 29.9 was a borrowed `T=15` that does not apply to those elements (implied `T` there is 23–34). ⚠️ `60` is **not** refuted — 5.6 % away against ~5 % quantisation — so the port keeps it; but the unit constant is eliminated as a cause of a late plate (t=236 → 4.15 s vs the port's 3.93 s, i.e. fractionally *early*). Instrument: guest timebase (50 MHz, scalar 1.0), control passed — 123.24 guest s over ~118 wall s. |
| [`h3-units-per-frame-measured.md`](h3-units-per-frame-measured.md) | How many keyframe units elapse per guest frame, and which declared time the title's settle anchor is | ✅ **measured against a pre-registration, 2026-09-01. 2 units per guest frame**, on `ptbtn00`'s own declared ramp (`t=214→236`, T=22): three consecutive gap-free steps of **exactly 23** = 255×2/22, ramp span 10 labels against a predicted 11 (±1). The Port's inferred **5 is excluded by >2×**. 🔴 Why 5 appeared: **an alpha step is not a clock rate** — `Δα/frame = 255·(units/frame)/T`, so splash B's 34-with-T=15 and the plate's 23-with-T=22 are ONE clock. Also: the **title settle anchor is t≈160**, not t=118 — it is `ptcopyright`, the last build-in element and the only glyph one, full at label 5350 → t≈168–176. 🔴 **units/SECOND is NOT settled** and two of my own captures disagree ~2.9× on it; the gap is in frames→seconds, not units→frames. |
| [`h3-units-per-frame-preregistration.md`](h3-units-per-frame-preregistration.md) | The prediction, committed before the capture was read | ✅ kept as the control on the row above |

15
docs/re/splash-declared-vs-captured.md
View File

@@ -54,7 +54,20 @@ residual is one level and is named, not hidden. A candidate is that the clock is
fractional and α is floored, so a sample lands one low whenever the fraction is
small — untested.
## 2 🔴 The unit→seconds rate is **per-GamePart**, and I told the port otherwise
## 2 ❌ WITHDRAWN — "the unit→seconds rate is per-GamePart"
> 🔴 **This section is REFUTED and is kept only for the record.** See
> [`splash-rate-withdrawn.md`](splash-rate-withdrawn.md). The three "rates" below
> came from three regions of one run at **3.39 / 15.33 / 23.20 labels per guest
> second**, and the reported rates order the same way — 35 / 40 / 57. It is the
> emulator's pacing, not the `GamePart`. The corpus already documented the effect
> in `boot-splash-dwells-are-declared.md`; I re-derived it as a discovery and drew
> a false conclusion from it. **The rate is 60 units/s for every screen, and §1
> above is untouched.**
### the withdrawn text follows
#### (withdrawn) The unit→seconds rate is **per-GamePart**, and I told the port otherwise
This is the correction, and it matters more than the first result.

117
docs/re/splash-rate-withdrawn.md Normal file
View File

@@ -0,0 +1,117 @@
# 🔴 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*.