From 4718e90c16c1e97448eb02d9f0adb0906cea5c67 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Mon, 31 Aug 2026 06:09:05 +0000 Subject: [PATCH] refuted: my own 0x8050 candidate (twice), and the port's frame sharpener 0x8050 dies disc-wide (38 sprites, high byte tracks the archive) and again on EXTRAS, where pteff21/22/23 share it with the frames. The port's 'neither frame has a fully-opaque pixel' is true and is not the discriminator: pteff10 has max alpha 130, no opaque pixel, and they measure it as nearly exact. Their direction survives -- the draw path did answer -- so what is refuted is the reason, not the conclusion. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/re/REFUTED.md | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md index 211336b8..6ea30aa2 100644 --- a/docs/re/REFUTED.md +++ b/docs/re/REFUTED.md @@ -857,3 +857,49 @@ if the disc census **excludes alternatives** — they measured *"of 32 readable **The claim survives and the exclusion is tighter than they stated**: no other bank carries *either* wave size, not merely not both. Their third leg is genuinely discriminating. + +### ❌ "`T8aD +0x08` selects the frames' blend mode" — MY OWN candidate, refuted twice (2026-08-31) + +`+0x08 = 0x8050` is the one header word where `ptframe1` and `ptframe2` agree on a +value no other **main-menu** sprite takes, and it was the only candidate the +declaration entry left. It is dead on two independent grounds. + +1. **Disc-wide** — 38 sprites carry `0x8050`, only 8 of them named `*frame*`, and + the **high byte tracks the archive**: `0x80xx` in `GP_TITLE`, `0xb1xx` in + `GP_OPTIONS`, `0xd8xx` in `GP_GAMEOVER`, `0xf0xx` in `GP_DIALOG`. An atlas word. +2. **On the second screen** — `EXTRAS` puts `pteff21`, `pteff22` and `pteff23` on + `0x8050` alongside `ptframe3`/`ptframe4`, so it does not even separate the + frames within one bundle. `data/frame-blend-field-hunt.txt`. + +⚠️ And the wider negative it belonged to is now **superseded in its conclusion**: +the mode is real and is **additive**, measured off the GPU +([`structures/ui-blend-mode-measured.md`](structures/ui-blend-mode-measured.md)). +The disc-side reach stands; what died is the instruction *"any blend you choose is +authored"*. + +### Refutation attempt on `sylpheed-port`'s frame sharpener — ❌ REFUTED (2026-08-31) + +**Target:** *"neither frame has a single fully-opaque pixel, against `ptbase`'s +99.1 %. For a wholly semi-transparent overlay the blend equation decides the +output"* — offered as what makes the frames special and why the draw-path route +looked live. + +**My attempt:** an alpha census of every `T8aD` sprite on both screens +(`examples/frame_alpha_census.rs`, `data/menu-sprite-alpha-census.txt`). + +| sprite | max alpha | fully-opaque pixels | the port's own accuracy | +|---|---|---|---| +| `ptbase` | 255 | 99.1 % | 1.31× | +| **`pteff10`** | **130** | **0** | **nearly exact** | +| `pteff12` / `pteff20` | 142 / 218 | 0 | not flagged | +| `pteff21`–`23` | 200 | 0 | not flagged | +| `ptframe1` / `ptframe2` | 173 / 174 | 0 | too dark | + +**The premise is true and it is not the discriminator.** `pteff10` has no opaque +pixel either and renders accurately, so "wholly semi-transparent" does not +separate the four frames from anything. + +⚠️ **What their conclusion did NOT depend on it, and survives:** the draw path was +the right place to look, and it answered — the frames are drawn additive, exactly +as their own two-background composite solve had ranked them. A wrong reason +attached to a right direction; only the reason is refuted here.