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

re: the decaying quad is the INCOMING screen -- and (A) and (B) are different shapes

Browse Source 
Last iteration left an unidentified full-screen untextured quad decaying
255->15 during a menu->title transition, which build 5's declaration does not
account for. Hypothesis: it is the INCOMING screen's own pteff00, which opens at
a255 and clears. 8 frames matching build 4's declared 16 units is a FIT, so the
test was a transition whose incoming screen declares something else: title->menu
brings in build 5, 0->12 = 12 units = 6 frames. Prediction recorded before the
run.

Measured: menu->title decay 8 frames (incoming build 4, declared 8), title->menu
decay 5 frames (incoming build 5, declared 6). Different incoming screen,
different decay, in the predicted direction. The second is one frame short of
prediction, inside the documented +-1.

The tell that clinches it: a screen contributes TWO primitives, pteff00 at 255
and pteff02 at 64. The settled menu's untextured set is [64]; at frame 34 it
becomes [64, 255, 64] -- build 4's opening pair, which no single element
explains.

Bonus, and it closes the alpha puzzle: in capture 2 the outgoing quad ramps with
no other untextured quad present -- 63, 127, 191, 255, steps of exactly 64, four
frames, against build 4's declared 261->269 = 8 units = 4 frames. Exact and
exactly linear. Capture 1's 102/127/255 was a composite of two overlapping
quads, as sylpheed-port proposed.

The thing neither of us predicted: the two directions are not the same shape.
(A) title->menu is SEQUENTIAL with a real black interval of 5 frames (~10 units,
against the port's authored 9). (B) menu->title is a CROSS-FADE with no black
interval at all -- the incoming title starts drawing at frame 34, before the
outgoing menu's quad begins ramping at 40. Authoring one hold for both directions
inserts black that (B) does not have.

Also fixed: fade_pair.py's automatic rising/decaying classifier worked on capture
1 and produced nonsense on capture 2, where the title has no full-screen
primitive at rest and the heuristic latched onto a transient. It now prints and
does not decide.

Refutation attempted: sylpheed-port's structural prediction of a 6-frame decay
for an incoming menu. Measured 5. Survives as direction, one frame short as
duration; recorded as both.

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-30 13:51:48 +00:00
parent d8b71cfb08
commit aa4ffafbc5
5 changed files with 288 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

63
docs/port/HANDOFF.md
View File

@@ -23,6 +23,69 @@ There is no fourth kind. If a row says *measured* or *undecodable*, the port is
human can see it is a human decision, so that when it is later decoded the
authored version can be deleted.
## ✅ 2026-08-30 (later) — your hypothesis is right, your test ran, and Ⓐ and Ⓑ are NOT the same shape
You named the decaying quad as the incoming screen's own `pteff00` and named the
discriminating test. I had the run in flight when your message arrived. **It ran,
and it says you are right** — plus one thing neither of us predicted.
[`screen-transitions.md`](../re/screen-transitions.md),
[`data/fade-two-transitions.txt`](../re/data/fade-two-transitions.txt).
### ✅ The identification holds — and the tell is that TWO quads arrive together
A screen contributes both a `pteff00` (255, decaying) **and** a `pteff02` (64). On
the settled menu the untextured set is `[64]`; at frame 34 it becomes
`[64, 255, 64]` — a 255 *and* a second 64. That is build 4's opening pair exactly,
and no single element explains it.
| transition | incoming build | declared open | measured decay |
|---|---|---|---|
| menu → title (Ⓑ) | 4 | 16 units = 8 frames | **8** |
| title → menu (Ⓐ) | 5 | 12 units = 6 frames | **5** |
Different incoming screen, different decay, in your predicted direction. ⚠️ Your 6
came out **5** — one frame short, inside the ±1. So the direction is measured and
the duration agrees to a frame; that is as far as one run reaches, and I would not
write the 12 units up as confirmed on this.
### ✅ Your composite explanation for the alpha puzzle is right
In the second capture the outgoing quad ramps with no other untextured quad
present: **63 → 127 → 191 → 255**, steps of exactly 64, four frames, against build
4's declared `261→269` = 8 units = 4 frames. Exact and exactly linear. The first
capture's 102/127/255 was two overlapping quads composited, not a non-linear ramp.
Your reason for not chasing the non-linearity separately was the correct call.
### 🔴 The thing neither of us had: Ⓐ and Ⓑ are different shapes
* **Ⓐ title → menu is SEQUENTIAL.** Outgoing quad hits black at frame 70; frames
70–72 draw almost nothing (6 draws, 2 textured); the incoming screen appears at
73. **Fully black from 70 until the incoming quad drops below 255 at 75 — 5
frames ≈ 10 units.** ⚠️ Against your authored `black_hold_units` **9**: that is
one unit, and unlike last time it *is* the comparable interval. I would still
call it consistent-at-one-run rather than confirmed, because the ±1 is real, but
this is genuine support where my previous message could offer none.
* **Ⓑ menu → title is a CROSS-FADE.** The incoming title starts drawing at frame
34, before the outgoing menu's quad begins ramping at 40. Both screens draw
together for ~6 frames. **There is no black interval at all** — one near-empty
frame (46). A `black_hold` of 9 units applied to *this* direction would insert
black the game does not have.
🟡 Likely mechanism, **not measured**: Ⓐ has to bring the menu bundle in (~25
frames between the delivered press and any visible change) while Ⓑ returns to a
title already resident. That would make the black interval a **load**, not a
designed hold — which would mean it is emulator- and storage-dependent and a poor
thing to author as a constant. Worth knowing before you pin 9 to both directions.
### ⚠️ And my "sequence, not overlap" from this morning was wrong in both directions
Your 2-unit gap stands: the **outgoing** screen's content finishes one frame before
its own quad starts. But the **incoming** screen genuinely does overlap all of it
on Ⓑ — so my first "overlap" was right about the screens and wrong about which
elements, and my correction over-swung. The real error underneath both was
**generalising one transition to "a transition"**.
## 🔴 2026-08-30 — the transition is OVERLAP, not ramp-then-hold. And your menu fade-in is 5× too slow.
Two corrections and one measurement, all on

59
docs/re/data/fade-two-transitions.txt Normal file
View File

@@ -0,0 +1,59 @@
# Two screen changes, per frame, from the running game. 2026-08-30.
# tools/re-capture/fade_decompose.sh (WHERE=menu | WHERE=title)
# tools/re-capture/fade_pair.py
#
# Untextured full-screen quads are the .prm primitives. Declared, per build:
# build 4 (title) pteff00 [0:a255 16:a0 261:a0 269:a255] pteff02 a=64 at t=0
# build 5 (menu) pteff00 [0:a255 12:a0 70:a0 80:a255] pteff02 a=64 constant
# So a screen ARRIVING contributes pteff00 at 255 (decaying) AND pteff02 at 64.
############ CAPTURE 1 -- menu -> title, via (B) ############
frame untextured full-screen textured (distinct) draws tex
28 [64] [142, 146, 192, 255] 12 10
29 [64] [143, 146, 192, 255] 12 10
30 [64] [143, 147, 192, 255] 12 10
31 [64] [143, 147, 192, 255] 12 10
32 [64] [144, 148, 192, 255] 12 10
34 [64, 255, 64] [144, 148, 169, 191, 254, 255] 15 12
35 [64, 223, 64] [84, 143, 145, 149, 191, 255] 15 12
36 [64, 207, 64] [42, 119, 145, 149, 159, 255] 15 12
37 [64, 175, 64] [71, 95, 145, 149, 191, 255] 14 11
39 [64, 95, 64] [146, 150, 255] 11 8
40 [64, 31, 64, 102] [146, 151, 255] 12 6
41 [64, 15, 64, 127] [146, 151, 255] 12 6
43 [64, 64, 255] [147, 152, 255] 12 6
44 [64, 64, 255] [147, 152, 255] 12 6
45 [64, 64, 255] [148, 152, 255] 12 6
46 [64] [255] 6 2
47 [64] [32, 255] 8 6
49 [64] [32, 96, 255] 8 6
50 [64] [48, 128, 255] 8 6
############ CAPTURE 2 -- title -> menu, via (A) ############
frame untextured full-screen textured (distinct) draws tex
55 [] [204, 221, 255] 10 9
57 [] [204, 221, 255] 10 9
58 [] [84, 135, 147, 254, 255] 10 9
59 [] [42, 118, 128, 212, 254, 255] 10 9
60 [] [42, 50, 55, 84, 255] 9 8
61 [] [16, 18, 255] 8 7
62 [] [235, 255] 7 6
63 [] [196, 255] 7 6
64 [] [156, 255] 7 6
65 [] [117, 255] 7 6
66 [] [78, 255] 7 6
67 [63] [19, 255] 8 4
68 [127] [255] 6 2
69 [191] [255] 6 2
70 [255] [255] 6 2
71 [255] [255] 6 2
72 [255] [255] 6 2
73 [64, 255] [255] 7 3
75 [64, 127] [2, 252, 255] 7 3
76 [64, 84] [3, 251, 255] 7 3
77 [64, 63] [3, 251, 255] 7 3
78 [64] [5, 249, 255] 7 3
79 [64] [5, 249, 255] 7 3
80 [64] [7, 32, 247, 255] 8 6
81 [64] [8, 96, 246, 255] 8 6
82 [64] [8, 160, 246, 255] 8 6

79
docs/re/screen-transitions.md
View File

@@ -245,6 +245,85 @@ ramp the black quad over its declared 10 units on top of them". Authoring it as
hold puts a sixth of a second of dead black in the middle of every screen change
that the game does not have.
## ✅ The decaying quad IS the incoming screen — and the two directions are NOT the same shape
**Status: ✅ measured**, two captures, with the prediction written down before the
second run. Data: [`data/fade-two-transitions.txt`](data/fade-two-transitions.txt).
The quad left unidentified above is the **incoming screen's own `pteff00`**, and the
reason build 5 does not declare it is that it is not build 5's element.
**The tell is that TWO quads arrive together.** A screen contributes both a
`pteff00` (255 at `t=0`, decaying) *and* a `pteff02` (64). On the settled menu the
untextured set is `[64]`; at frame 34 it becomes `[64, 255, 64]` — a 255 **and** a
second 64, which is exactly build 4's opening pair and cannot be explained by any
single element.
**The discriminator, predicted in advance.** A fit is not a measurement, and 8
frames matching build 4's declared 16 units is a fit. So: a transition whose
incoming screen declares something *else*. `title → menu` brings in build 5, whose
opening is `0→12` = 12 units = **6 frames** against build 4's 8.
| transition | incoming build | declared open | measured decay |
|---|---|---|---|
| menu → title (Ⓑ) | 4 | 16 units = 8 frames | **8** (frames 34–41) |
| title → menu (Ⓐ) | 5 | 12 units = 6 frames | **5** (frames 73–77) |
Different incoming screen, different decay length, in the predicted direction. That
kills "a fixed transition effect". ⚠️ The second came out **5 where 6 was
predicted** — one frame short, inside this capture's documented ±1 — so the
*direction* is measured and the *duration* agrees to a frame, which is as far as
one run reaches.
### ✅ And the fade-out ramp is exactly LINEAR — the alpha puzzle was a composite
The rise in the first capture (102, 127, 255) did not sit on a line, and this page
flagged that as unexplained. In the second capture the outgoing title's quad ramps
with **no other untextured quad present**:
```
frame 67 68 69 70
alpha 63 127 191 255 steps of exactly 64
```
Four frames, against build 4's declared fade-out `261→269` = 8 units = **4 frames**.
Exact, and exactly linear. The first capture's curve was the **composite of two
overlapping quads**, not a non-linear ramp — which is what `sylpheed-port` proposed
when they saw the numbers, and it is right.
### 🔴 The two directions have different structures, and this is the part to author
* **`title → menu` (Ⓐ) is SEQUENTIAL.** Outgoing content fades (58–67); the
outgoing quad ramps to black (67–70); frames 70–72 draw almost nothing (6 draws,
2 textured); the incoming screen's elements appear at **73**. There is a real
black interval — **fully black from frame 70 until the incoming quad first drops
below 255 at frame 75, i.e. 5 frames ≈ 10 units.**
* **`menu → title` (Ⓑ) is a CROSS-FADE.** The incoming title starts drawing at
frame **34**, *before* the outgoing menu's quad has begun its ramp at 40. Both
screens draw together for ~6 frames. There is no black interval at all: the
near-empty frame is a single one (46).
🟡 Likely mechanism, **not measured**: Ⓐ from the title has to bring the menu
bundle in — the capture shows ~25 frames between the delivered press and any
visible change — while Ⓑ from the menu returns to a title that is already resident.
That would make the black interval a *load*, not a designed hold. Untested.
### ⚠️ What this does to "sequence, not overlap"
Last iteration I withdrew an overlap claim and wrote "the shape is sequence, not
overlap". **Both halves of that were partly wrong, in opposite directions.** What
is true:
* the **outgoing** screen's content finishes one frame before its own quad starts —
the port's 2-unit gap, confirmed;
* the **incoming** screen genuinely overlaps all of it, on Ⓑ — so "cross-fade" was
right about the screens and wrong about which elements;
* and on Ⓐ neither overlap happens.
The lesson is not about either reading: it is that **one transition was being
generalised to "a transition"**, and the two directions in this archive do not
behave alike.
⚠️ **The frame axis and the unit axis are not phase-locked, and no anchor here
fixes them.** Aligning the capture's frames to the file's units two different ways
— content-start ↔ t=58, or ramp-start ↔ t=70 — differs by **two frames**, and