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

re: the transition is overlap, not ramp-then-hold -- and the fade-in was 5x wrong

Browse Source 
screen-transitions.md carried a 14-unit "black hold" that the page itself
flagged as arithmetic rather than measurement. Measured it against the running
game; the guess was wrong, and finding the instrument to measure it turned up a
second, larger error in the same page.

1. fade_quads.py was STALE. It read each pose's time from blk+36 -- the next
record's time word -- the association the keyframe record-layout fix retired in
the crate. sylpheed-cli was rebuilt at the time; the Python helper was never
swept with it. Signature: it cannot time a group's last pose, so it printed a
trailing `t=-`. Fixed, controlled against the rebuilt `screen info` ([0 12 70
80] for build 5's pteff00.prm).

2. Through it, the page labelled the quad's CLEAR-hold as its fade-in and
published 0.87 s / 0.97 s / 4.08 s for a ramp that is 0.20 s / 0.20 s / 0.27 s.
A port pacing its menu fade-in off that would run it 5x too slow.

3. The measurement. fade_decompose.sh boots to the main menu, arms the UI draw
capture there, then presses (B), so one 260-frame window holds the whole screen
change. The fade quad is identified rather than guessed: a .prm carries no
tex[base=] and paints last, so it is the last full-screen untextured quad of a
frame. Control first -- the quad's ramp is decoded at 10 units = 5 frames, and
measures 4 submitted-frame steps with one unlogged frame in the span.

Result: content elements begin fading at frame 34; the black quad first appears
at 40 and is opaque by 43; the menu's last frame is 45; frame 46 has 6 draws
against 12. So the ~14 extra units are the content's own fade-outs OVERLAPPING
the quad's ramp, not a hold after it, and the inter-screen black is one frame.

Refutation attempted: sylpheed-port's entries 13/14 twins. Re-derived off the
disc -- 3.06 / 4.33 / 47.91, identical to two decimals. Recorded as confirming
their addressing and arithmetic, NOT as independent support: same renderer,
same disc, which is their own rule.

Reach: one transition, one run; the frame axis has gaps (232 headers over frames
3..260), so every span is +-1 frame.

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:35:56 +00:00
parent c364cde476
commit 4bcb35cef7
7 changed files with 370 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/re/METHOD.md
View File

@@ -189,6 +189,20 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
luck in one archive, not a property of the format, and it does not extend to the
screens the port has left to do.
* **A layout fix has to be swept across every READER of that layout, not just the
crate.** The keyframe record-layout fix (a pose's time precedes it) landed in
`ui_layout.rs`, and `sylpheed-cli` was found stale and rebuilt. **Two more
readers survived it**: `tools/re-capture/fade_quads.py`, which read each pose's
time from `blk+36` — the *next* record's time word — and therefore printed a
trailing untimed keyframe; and, through it,
[`screen-transitions.md`](screen-transitions.md), which labelled the quad's
**clear-hold** as its *fade-in* and published 0.87–4.08 s for a ramp that is
0.20–0.27 s. Both looked right: a shifted time series is still monotone,
plausible, and internally consistent. The tell is structural, not numeric — the
stale reader **cannot time the last pose**, so any output with a trailing `t=—`
or `-` is that bug's signature. Grep the corpus for readers of a structure
before calling its fix done.
## Runtime / emulator
* **Look at the PNG** — and check its dimensions.

43
docs/re/data/fade-envelope-menu-to-title.txt Normal file
View File

@@ -0,0 +1,43 @@
# Menu -> title transition, per-frame, from the running game.
# tools/re-capture/fade_decompose.sh -> log_ui_draws capture (260 frames)
# tools/re-capture/fade_envelope.py (the fade quad = last FULL-SCREEN
# UNTEXTURED quad in a frame: a .prm carries no tex[base=], and the fade
# quad paints last).
# Xenia VdSwap frame numbers. 2026-08-30.
#
# TIMING CHECK: F10 armed the capture at frame 1; the script sent (B) 1.2 s
# later. 1.2 s at 30 Hz is frame ~36. The fade begins at 34. The press and
# the transition agree without either being used to place the other.
#
# frame untextured full-screen quad alphas, in submission order
28 [[64]] draws= 12 tex= 10
29 [[64]] draws= 12 tex= 10
30 [[64]] draws= 12 tex= 10
31 [[64]] draws= 12 tex= 10
32 [[64]] draws= 12 tex= 10
34 [[64, 255], [64]] draws= 15 tex= 12 <- content starts fading
35 [[64, 223], [64]] draws= 15 tex= 12
36 [[64, 207], [64]] draws= 15 tex= 12
37 [[64, 175], [64]] draws= 14 tex= 11
39 [[64, 95], [64]] draws= 11 tex= 8
40 [[64, 31], [64], [102]] draws= 12 tex= 6 <- BLACK QUAD APPEARS
41 [[64, 15], [64], [127]] draws= 12 tex= 6
43 [[64], [64], [255]] draws= 12 tex= 6 <- fully black
44 [[64], [64], [255]] draws= 12 tex= 6
45 [[64], [64], [255]] draws= 12 tex= 6
46 [[64]] draws= 6 tex= 2 <- menu stops drawing (6 draws vs 12); ONE frame of black
47 [[64]] draws= 8 tex= 6
49 [[64]] draws= 8 tex= 6
50 [[64]] draws= 8 tex= 6
51 [[64]] draws= 8 tex= 6
52 [[64]] draws= 8 tex= 6
53 [[64]] draws= 8 tex= 6
54 [[64]] draws= 8 tex= 6
55 [[64]] draws= 8 tex= 6
56 [[73]] draws= 8 tex= 6
57 [[93]] draws= 8 tex= 6
58 [[113]] draws= 9 tex= 7
59 [[152]] draws= 12 tex= 10
60 [[172]] draws= 12 tex= 10
missing submitted frames in this span: 33->34, 37->39, 41->43, 47->49

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

@@ -27,16 +27,33 @@ The group is always four blocks, and always this shape:
Read with the corpus's rule that a keyframe is the *start* of a ramp
([`structures/ui-resting-pose.md`](structures/ui-resting-pose.md)).
🔴 **The table this section used to print was taken with a STALE READER, and both
its numbers were wrong (corrected 2026-08-30).** `fade_quads.py` read each pose's
time from `blk+36` — the *next* record's time word — so every time was shifted one
slot and the last pose came out untimed (`t=—`). That is the same association the
[record-layout fix](ui-keyframe-record-layout.md) retired in the crate; the Python
helper was never swept with it. Fixed, and controlled against the rebuilt
`screen info`, which prints `[0 12 70 80]` for the same element:
```
$ tools/re-capture/fade_quads.py 4 5 6 # GP_TITLE
build 4 (title) pteff00.prm t=16 α=255 t=261 α=0 t=269 α=0 t=— α=255
build 5 (main menu) pteff00.prm t=12 α=255 t= 70 α=0 t= 80 α=0 t=— α=255
build 6 (EXTRAS) pteff00.prm t=12 α=255 t= 64 α=0 t= 74 α=0 t=— α=255
build 4 (title) pteff00.prm t= 0 α=255 t= 16 α=0 t=261 α=0 t=269 α=255
build 5 (main menu) pteff00.prm t= 0 α=255 t= 12 α=0 t= 70 α=0 t= 80 α=255
build 6 (EXTRAS) pteff00.prm t= 0 α=255 t= 12 α=0 t= 64 α=0 t= 74 α=255
```
Under [Q1](ui-keyframe-time-unit.md)'s `1 unit = 1/60 s`: the screen holds black
for **0.20 s**, then fades in over **0.87 s** (`EXTRAS`), **0.97 s** (main menu)
or **4.08 s** (the title).
**Every pose is timed. There is no untimed keyframe**, and the fade-out ramp is on
the disc after all: `70 → 80` = 10 units for the main menu, `64 → 74` = 10 for
`EXTRAS`, `261 → 269` = **8** for the title.
⚠️ **And the fade-IN was mislabelled by the same shift.** This page used to say the
screen "holds black for **0.20 s**, then fades in over **0.87 s** (`EXTRAS`),
**0.97 s** (main menu) or **4.08 s** (the title)". Those spans are `T2 − T1` under
the stale pairing — the stretch where the quad sits at **α = 0**, i.e. the screen
fully visible and *not* fading at all. Read correctly the screen starts black at
`t = 0` and fades in over **12 units (0.20 s)** on the menu and `EXTRAS`, **16
units (0.27 s)** on the title. A port pacing its menu fade-in off the old number
would have run it **5× too slow**.
### ❔ The fade-OUT duration is not in this field
@@ -148,11 +165,65 @@ units ≈ 0.167 s**, not the ~24 units this page authored. That confirms the por
agent's reading; I tried to refute it against the bytes and could not.
🔴 **So the measured ~0.4 s is NOT the ramp alone** — 0.4 s is ~24 units against a
decoded 10. Something else occupies the other ~14 units. 🟡 That the remainder is
exactly the black hold is *arithmetic that fits* (14 units = 0.233 s, inside this
corpus's own 0.17–0.23 s plateau), **not a measurement** — and a fit that closes a
question without evidence is what this pair of agents has been catching all week.
The decomposition stays open.
decoded 10. Something else occupies the other ~14 units.
## ✅ What the other ~14 units are — MEASURED 2026-08-30, and it is not a hold
This page previously guessed: *"that the remainder is exactly the black hold is
arithmetic that fits (14 units = 0.233 s), **not a measurement**"*. It has now been
measured, and **the guess was wrong**. There is no black hold inside the fade-out.
**Instrument.** [`fade_decompose.sh`](../../tools/re-capture/fade_decompose.sh)
boots to the main menu, arms the UI draw capture there, then presses Ⓑ, so one
260-frame window contains the whole screen change.
[`fade_envelope.py`](../../tools/re-capture/fade_envelope.py) reads the fade quad's
alpha per submitted frame. The quad is **identified, not guessed at**: a `.prm`
primitive carries no `tex[base=…]`, and this element paints last
([paint-order key](structures/ui-paint-order-key.md)), so it is the last
full-screen *untextured* quad of a frame. Taking merely the last full-screen quad
picks up textured backdrops and gives a different answer.
**Control.** The quad's ramp is *decoded* (10 units), so the instrument can be
checked before it is believed. At Q1's 2 units per rendered frame, 10 units is 5
frames. Measured: the quad is absent at frame 39 and `α=255` at frame 43 — **4
submitted-frame steps**, with one unlogged frame inside the span. Agreement to
within that one frame. An instrument that could not reproduce the decoded ramp
could not be trusted on the undecoded remainder.
**The measurement** ([`data/fade-envelope-menu-to-title.txt`](data/fade-envelope-menu-to-title.txt)):
```
frame 34 content elements begin fading (a 255 quad appears and decays)
35..41 255 223 207 175 95 31 15 the content fade
frame 40 the BLACK QUAD first appears, α=102
41 α=127
43 α=255 fully black
45 last frame the menu draws
frame 46 6 draws (vs 12) — ONE frame of black
47+ the title's build starts
```
✅ **The ~14 extra units are the content elements' own fade-outs, which start six
frames BEFORE the quad's ramp and overlap it.** The blackout runs frame 34 → 43 =
**9 submitted frames ≈ 0.30 s at 30 Hz**, of which the quad's ramp is the last 4.
That is the same quantity the filmstrip measured as 0.367–0.400 s with coarser
timing, and it decomposes as **overlap, not sequence**.
✅ **The inter-screen black is ONE frame** (46), not ~14 units. The draw count
collapses from 12 to 6 for exactly one frame and the incoming build starts at 47.
📌 **For the port:** a transition is *not* "ramp the black quad for 10 units, then
hold black for 14". It is "start the content elements fading, and 6 frames later
ramp the black quad over its declared 10 units on top of them". Authoring it as a
hold puts a sixth of a second of dead black in the middle of every screen change
that the game does not have.
⚠️ **Reach.** One transition (main menu → title, via Ⓑ), one run. The frame axis
has gaps — 232 `--- frame` headers over frames 3…260, so ~10 % of submitted frames
carry no UI draw — which is ±1 frame on any span quoted here and is why the ramp is
given as 4 steps rather than a duration to three digits. Whether the six-frame lead
is constant across screens, or is a property of *these* elements' keyframes, is
**not** measured.
| elements | final untimed block | what it does |
|---|---|---|