From 864ab45a1e7b45349e4b035564c2b98b9dfa96d2 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Tue, 1 Sep 2026 18:55:50 +0000 Subject: [PATCH] re: the blend bit was challenged on pteff10 and SURVIVES; finding 3 loses its second candidate The port isolated main_menu's 10.88 -> 13.02 regression to pteff10 and asked whether the per-draw log shows it alpha-over, which would be a counter-example to ui-blend-mode-decoded.md. It does not. blend-bit-vs-oracle.txt has pteff10 ADDITIVE on entry 5 (main menu) AND entry 6 (extras), both labels read out of the guest command stream, and HANDOFF states it from three independent menu sessions, every frame. The premise came from a stale coverage table of mine that the same HANDOFF entry had already corrected in place. Recording that: a correction which leaves the wrong table visible upstream of it has not landed. And the regression was predicted on this exact element before adoption -- HANDOFF flagged pteff10 as the one row the port's renderer would not corroborate, because for a dim wholly-semi-transparent glow (max alpha 130) over a dark background additive and alpha-over nearly coincide. A renderer metric getting worse while the render gets more correct is the standing rule with a number on it. Separately, the port answered my finding-3 candidate: a frozen sweep of the plate region rises monotonically across the declared 214->236, so the port fades rather than pops and its t=236 is a completion. That kills the onset branch. Two of the play-test's four named candidates for finding 3 are now dead -- units/s (measured at 60) and the ramp. Finding 3 has no surviving named cause. The clock origin is the one to take next, because every measurement so far is a DIFFERENCE between two events and a difference cannot detect a common offset. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t --- docs/re/guest-frame-rate-measured.md | 18 ++++++++ docs/re/structures/ui-blend-mode-decoded.md | 49 +++++++++++++++++++++ 2 files changed, 67 insertions(+) diff --git a/docs/re/guest-frame-rate-measured.md b/docs/re/guest-frame-rate-measured.md index 448cc7a1..b5fdb281 100644 --- a/docs/re/guest-frame-rate-measured.md +++ b/docs/re/guest-frame-rate-measured.md @@ -144,6 +144,24 @@ when it *starts*. port raising the plate at `t = 236`; whether that is its onset or its completion is the port's to check. What is decoded here is the disc fact and the arithmetic. +### πŸ”΄ ANSWERED same day, and this branch is dead too + +The port checked and reports a frozen sweep of the plate region across the +declared ramp β€” `210u β†’ 0.1457`, `216u β†’ 0.1573`, `222u β†’ 0.1727`, `228u β†’ +0.1900`, `236u β†’ 0.2142`. **A clean monotone rise across `214 β†’ 236`: the port +fades, it does not pop**, and its `t = 236` is its completion, not its onset. + +So the onset branch is eliminated as well. Of the four candidates the play-test +named for finding 3 β€” the unitβ†’seconds constant, the clock origin, `rest.t`, the +record layout β€” **two are now dead**: units/s is measured at 60 here, and the +plate's ramp is being drawn. **Finding 3 has no surviving named cause.** + +The remaining two are the **clock origin** (does the port's shared clock start +when the game's does?) and **`rest.t`**, and the origin is the one worth taking +first: everything measured so far is a *difference* between two events, and a +difference is exactly what cannot detect a common offset. `REFUTED.md` already +records that believing `rest.t` put a port's plate **3.97 s late once**. + ## Reach ⟨capture⟩ over **one** boot, English locale, one machine, and the movie region of diff --git a/docs/re/structures/ui-blend-mode-decoded.md b/docs/re/structures/ui-blend-mode-decoded.md index c4ab77ca..234a9230 100644 --- a/docs/re/structures/ui-blend-mode-decoded.md +++ b/docs/re/structures/ui-blend-mode-decoded.md @@ -118,3 +118,52 @@ that it is **not** "the name contains `eff`" (`P(eff|set) = 0.468` against `P(eff|clear) = 0.144`) and **not** premultiplied-alpha storage β€” both refuted disc-wide, and both remain refuted. Those were readings of the bit's *meaning*; this is its *effect*. + +## Challenged 2026-09-01 as a possible counter-example β€” and it SURVIVES + +The port reported that adopting the bit moved `main_menu` **10.88 β†’ 13.02** +against its oracle capture, isolated the only newly-additive top-level element as +**`pteff10`**, and asked whether the per-draw log shows `main_menu`'s `pteff10` +drawn **alpha-over** β€” which would put a counter-example on one element. + +**It does not. The oracle measures it ADDITIVE on that screen.** + +``` +data/blend-bit-vs-oracle.txt + 5 pteff10.t32 +0x04 = 00008832 bit 0x02 = true ADDITIVE + 6 pteff10.t32 +0x04 = 00008832 bit 0x02 = true ADDITIVE +``` + +Entry 5 is the main menu and entry 6 is `EXTRAS`; the element is additive on +**both**, and every label there is an `RB_BLENDCONTROL0` value read out of the +guest command stream. `HANDOFF.md` states it directly and from three sessions: +*"Is `pteff10` additive on the MAIN MENU too? β€” **YES.** … additive, **in all +three menu sessions, every frame**."* + +⚠️ **The premise came from a stale table of mine.** The port's *"your own map +lists `pteff10` additive on `extras` and not on `main_menu`"* is reading a +coverage table that the same HANDOFF entry had already corrected in place β€” +*"My coverage table listing `pteff10` as uncovered on the menu is corrected."* +A correction that leaves the wrong table visible upstream of it is a correction +that has not landed. + +### πŸ“Œ The regression was PREDICTED, on this exact element, before adoption + +`HANDOFF.md`, flagged as 🟑 at the time the port was told to take the bit: + +> *"One flag on `pteff10` before you adopt it. You measure it as nearly exact +> under alpha-over, and the game draws it additive. Both can be true for a dim +> wholly-semi-transparent glow (max alpha 130) over a dark background, where the +> two nearly coincide β€” but it is the one row here your renderer does **not** +> independently corroborate."* + +So `main_menu` getting *worse* on a renderer metric while getting *more correct* +against the GPU is the flagged case arriving on schedule, not a new fact. It is +the corpus's standing rule with a number attached: **a claim resting on our +renderer is a claim about our renderer**, and here the renderer and the oracle +disagree on the one element where the two blends are known to nearly coincide. + +The port shipped the decoded bit anyway and recorded the movement as a known +regression. That was the right call for a better reason than the one it used: +not merely that `+2.14` sits inside the screen's `Β±3.78` capture-phase term, but +that the oracle had already adjudicated this element, three sessions deep.