From efa085a668c7cdb05be09ee71b757a612c42dbb1 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Wed, 2 Sep 2026 16:27:10 +0000 Subject: [PATCH] port: H3 re-asked -- the plate is ON TIME, and it never blinks PLAYTEST-2026-09-02 asks for this re-ask by name, and the previous plate numbers were taken through the pose_at bug -- the same accident that manufactured H2's false green. Filmed a real boot and isolated the plate with its own sprite's transparent holes: same rect, same rows, interleaved at pixel scale, so the moving title sweep cancels. Two earlier isolations failed first and are recorded -- a rect that overlapped the developer splash, and a control band 55px away that could not cancel a sweep that MOVES. Onset: flat through ou=213.9, risen by 222.1, declared t=214 inside the bracket; 88% of lit by t=238 against declared full at 236. NOT late. But over 8.1 declared cycles (ou 6..1974) it never returns within 88% of dark, where the disc declares 0 from t=244. rest.t=236 is the PULSE PEAK and holding parks it there -- the exact family plate-arrival-halves.md named for transients and nobody had checked on the plate itself. Proposed, not changed: whether the guest pulses the plate is the Decoder's. --- .../plate-arrives-on-time-but-never-blinks.md | 120 ++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 docs/port/plate-arrives-on-time-but-never-blinks.md diff --git a/docs/port/plate-arrives-on-time-but-never-blinks.md b/docs/port/plate-arrives-on-time-but-never-blinks.md new file mode 100644 index 00000000..6aaa168d --- /dev/null +++ b/docs/port/plate-arrives-on-time-but-never-blinks.md @@ -0,0 +1,120 @@ +# H3 re-asked after the animation fix: the plate is **on time**, and it **never blinks** + +**Status:** ✅ **the "arrives late" observation does not reproduce as a timing +error** — measured on the current build, and the plate's onset sits on its +declared keyframe. 🔴 **A different divergence in the same element is real and +was not being looked for: the port holds `PRESS Ⓐ` lit permanently, where the +disc declares a 30-unit pulse.** Written 2026-09-02 by the Port at `6263686`. + +`PLAYTEST-2026-09-02.md` asks for exactly this, in its own words: *"Worth +re-asking now: the animation fix changed what the whole boot looks like, so the +original observation may simply no longer reproduce."* And there is a specific +reason to re-ask rather than assume — **the previous plate numbers were taken +through the `pose_at` bug**, the same way the 0.01 % that manufactured H2's false +green was. + +## What the disc declares + +`export/screens/title/press_start.json`, one element `ptbtn00`: + +``` +0:0 214:0 236:255 238:255 244:0 rest [383,550], sprite 513x50 +``` + +Invisible until **214**, full at **236–238**, **gone by 244**. A 30-unit pulse. + +## The instrument, and the two controls it went through first + +Filmed a real boot (`--skip-at=1 --linger=8 --film-interval=0.05`), no `--time`, +no pinning. Then **two attempts at isolating the plate failed before one worked**, +which is the part worth keeping: + +1. 🔴 **A rect around the plate.** Contaminated — the rect overlaps the developer + splash earlier in the boot, so the onset detector fired on the wrong screen. +2. 🔴 **A control band 55 px above the plate.** Still wrong. The title's + background sweep **moves**, so a spatially displaced control samples it at a + different phase and cannot cancel it. It showed a "rise" that was the sweep. +3. ✅ **The plate sprite's own transparent holes.** Same rectangle, same rows, + interleaved with the glyphs at pixel scale — 7 672 glyph pixels against 10 412 + hole pixels, both built from the sprite's alpha channel. A co-located + background sample, so `glyph − hole` is the plate and nothing else. + +⚠️ Control 2 is the same defect as everything else on this project: **an +instrument that cannot see the thing it is measuring separately from the thing +it is measuring against.** It produced a plausible curve. The tell was that the +"plate" and the background rose together in phase. + +## Result 1 — the arrival is correct + +`glyph − hole`, dark baseline **0.003**: + +| overlay units | 205 | **214** | **222** | 230 | **238** | 246 | +|---|---|---|---|---|---|---| +| plate | 0.005 | **0.005** | **0.222** | 0.434 | **0.586** | 0.601 | + +**Flat through 213.9 and risen by 222.1.** The declared onset `t=214` sits inside +that bracket, and the bracket is 8 units wide because that is the film's sampling +interval, not a measurement of anything. By `t=238` the plate is at 88 % of its +lit level, against a declared full alpha at 236. + +**The plate is not late.** Whatever the human saw in the 2026-09-01 play-test, +the port's own clock puts `ptbtn00` on its declared keyframe. + +## Result 2 — 🔴 and it then stays lit forever + +The declared ramp returns to **0 at t=244**. It does not: + +| | | +|---|---| +| dark baseline, `t < 214` | **0.003** | +| minimum at any point after `t = 250` | **0.587** (at `ou` 342) | +| maximum after `t = 250` | **0.664** | +| span measured | `ou` 6 → **1974** — **8.1 declared cycles** | + +Over eight cycles of its own declared timeline the plate **never returns within +88 % of dark**. The 11.6 % ripple that is there is *not* the plate: it is in +phase with the hole channel, i.e. it is the title's background sweep leaking +through the anti-aliased glyph edges. + +### Why, and it is a failure mode this port already wrote down + +`ptbtn00`'s `rest.t = 236` and its settle instant is `t=236` — **the peak of the +pulse**. `holding` parks the element there, so the port shows a `PRESS Ⓐ` plate +that lights once and stays on. + +`plate-arrival-halves.md` names this exact class already, about a different +element: + +> *"It is still wrong for transients — `ptlogo_back2eff1` is a two-frame flash +> (0 at t52, `0xff` at t54–56, 0 by t58) and its `rest.t = 54` is the flash +> **peak**, so `rest()` leaves five of these burning at once."* + +**The plate is an instance of the family that page predicted, and nobody had +checked the plate itself** — because that page was written to *eliminate* `rest.t` +as a cause of lateness, which it correctly did, and having eliminated it as the +cause of *one* defect nobody asked what else it was doing. + +## What I have NOT changed, and why + +Nothing. The port still holds the plate. + +Reading the disc's keyframes is mine; **whether the running game pulses its +`PRESS Ⓐ` plate is not.** The keyframes describe a blink and blinking is what +`PRESS START` prompts conventionally do, but "conventionally" is not evidence and +this project has been burned by exactly that kind of inference. The change is +**proposed, not made**, and the Decoder has been asked for the one fact that +settles it: does the plate pulse in the guest, and with what period? + +⚠️ **This is not a regression from the animation fix.** Before the fix `pose_at` +*assigned* the settle instant, which parks the plate at `t=236` too. The plate +has been held for as long as the port has drawn it; the fix neither caused this +nor was supposed to. + +## What this does not claim + +* That finding 3 was wrong when it was made. It says the port measures on time + **now**, on a build whose boot the fix visibly changed. +* That holding is wrong. It says the port's picture and the disc's keyframes + disagree, and names who can adjudicate. +* Anything about the plate's **absolute** alpha or position. Onset timing and + whether it extinguishes, only.