fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

refuted: my own 0x8050 candidate (twice), and the port's frame sharpener

Browse Source 
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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-31 06:09:05 +00:00
parent 5a16ce5aba
commit cf73cfcbcf
1 changed files with 46 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
docs/re/REFUTED.md
View File

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