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