From c1c8aa428867bf7639b311338f133d3a14094bfb Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Tue, 1 Sep 2026 17:29:52 +0000 Subject: [PATCH] re: WITHDRAW 'the unit rate is per-GamePart' -- it was the emulator's frame rate 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. --- docs/re/INDEX.md | 3 +- docs/re/splash-declared-vs-captured.md | 15 +++- docs/re/splash-rate-withdrawn.md | 117 +++++++++++++++++++++++++ 3 files changed, 133 insertions(+), 2 deletions(-) create mode 100644 docs/re/splash-rate-withdrawn.md diff --git a/docs/re/INDEX.md b/docs/re/INDEX.md index f518f03f..3b8a93db 100644 --- a/docs/re/INDEX.md +++ b/docs/re/INDEX.md @@ -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 | diff --git a/docs/re/splash-declared-vs-captured.md b/docs/re/splash-declared-vs-captured.md index 72a86ba0..bb2783ef 100644 --- a/docs/re/splash-declared-vs-captured.md +++ b/docs/re/splash-declared-vs-captured.md @@ -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. diff --git a/docs/re/splash-rate-withdrawn.md b/docs/re/splash-rate-withdrawn.md new file mode 100644 index 00000000..068b635e --- /dev/null +++ b/docs/re/splash-rate-withdrawn.md @@ -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*.