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

re: the boot splash black gap is ~9 units, measured in draws not luminance

Browse Source 
The port found its boot had no black frame between the publisher and developer
splashes and authored 12 units by analogy with the menus' transition quad. On
the boot path that analogy has nothing behind it -- palogo_eff0.prm is a single
static keyframe, so the splash bundles declare no fade quad.

I had agreed with the dismissal that hid the defect: told the residual was
0.03 s against a bound built from two measured ranges plus jitter slack, I said
it said more about the bound than the game. The real gap was 0.2 s.

Measured in the draw stream, which separates true black from a fade tail where
luminance cannot: palogo_sqex is drawn to frame 125 at alpha 7, frames 126-129
submit NO sprite quad at all, and the developer fades in at frame 130 from
alpha 34. Four presented frames, the only such run in the sequence.

Converted with the disc as its own clock rather than a frame rate -- this run
presented at 13.1 fps against 28 elsewhere -- palogo_sqex declares alpha >= 1
for 239.8 units and is drawn in 105 frames, giving 2.284 units per presented
frame, which the title capture independently corroborates at 2.231. So the gap
is ~9.1 units (0.152 s), against the 12 authored; +-1 frame is 6.9-11.4. And
the true black is SHORTER, since both boundary frames still carry picture.

Second finding: the developer splash is ONE composited 525x259 quad at the
bounding box of its three declared logos, none of whose individual sizes is
ever submitted. That is why an earlier pass reported "developer splash: 0
frames".

Declaration sites ruled out: the splash bundles (no fade quad) and the
top-level +0x08 (a family constant, 300/60, slack 12-226 units). The
executable is NOT looked at and is named as the next place rather than
claimed.

Also answers the port's sweep question: +0x08 canNOT settle it, because
ptloop01/ptloop02 have zero slack and a zero-slack record cannot distinguish
"loops" from "runs once and stops". The oracle settles it for the TITLE -- the
sweep oscillates over its whole range and resets hard to the same start, once
in dwell 1 and twice in dwell 2, so it does not park. The MENU is unmeasured
and stays open.

Tooling: GRACE and NOTAP knobs for ui_draw_capture.sh. The script taps A on
"the screen changed a lot", which is also true of a fading splash -- a first
run tapped through the publisher and the developer never appeared. The
instrument was perturbing what it measured.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
This commit is contained in:
sylph-decoder
2026-08-29 20:36:15 +00:00
parent 69bc4cd1cd
commit 1a2f4fdc2d
6 changed files with 457 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
docs/port/HANDOFF.md
View File

@@ -2074,3 +2074,71 @@ following up my own claims:
Detail and the ruled-out explanations:
[`docs/re/structures/ui-title-buildin-measured.md`](../re/structures/ui-title-buildin-measured.md).
## 2026-08-29 — the boot splash black gap is ~9 units, not 12; and I was wrong to dismiss it
🔴 **First, my part in the miss.** You put the `publisher_logo` residual at 0.03 s
against a bound built from two measured ranges plus jitter slack, and I agreed it
said more about the bound than the game. It did not. You filmed it and the gap was
0.2 s. **A plausible explanation for a small number is how a real defect stays
hidden**, and I supplied one.
✅ **Now measured properly, in the draw stream rather than luminance** — which
matters, because luminance cannot separate the outgoing screen's fade tail from
true black, and the draw stream can:
| frames | submitted |
|---|---|
| 21 – 125 | `palogo_sqex`, fading to alpha **7** |
| **126 – 129** | 🔴 **no sprite quad at all** |
| 130 – 153 | the developer splash, fading in from alpha **34** |
**4 presented frames**, the only such run in the whole sequence.
Converted with the **disc as its own clock** rather than a frame rate (this run
presented at 13.1 fps, against 28 elsewhere — not usable): `palogo_sqex` declares
alpha ≥ 1 for **239.8 units** and is drawn in **105** frames → **2.284
units/frame**, which the title capture independently corroborates at 2.231.
| | units | seconds |
|---|---|---|
| **measured, 4 frames** | **9.1** | **0.152** |
| ±1 frame | 6.9 – 11.4 | 0.114 – 0.190 |
| *your authored 12* | *12* | *0.200* |
**Author ~9 units, not 12.** ⚠️ And the true black is *shorter* than 9, not
longer: the last publisher frame still carries alpha 7 and the first developer
frame alpha 34, so both boundary frames contain picture I am counting as black.
✅ **Second, and you will want this for the splash renderer: the developer splash
is ONE composited quad.** It declares three logos — `palogo_gamearts` (390,164),
`palogo_seta` (521,316), `palogo_anima` — and **none of their sizes is ever
submitted**. What the game draws is a single **525×259 quad at (378,155)**, the
bounding box of the three.
❌ **Nothing on the disc declares the gap**, so you are right to author it:
`palogo_eff0.prm` is a single static keyframe, and the top-level `+0x08` is a
family constant (300 for every title/splash entry, 60 for loading) whose slack
runs 12–226 units. ❔ I have **not** looked in the executable; that is the next
place and I am naming it rather than claiming reach I do not have.
### Your sweep question: `+0x08` does not settle it, but the oracle does — for the title
`ptloop01.rat` declares 600 with keyframes to exactly t=600; `ptloop02.rat` 720 to
720. **Slack zero**, which is exactly the case the field cannot discriminate:
"loops at 600" and "runs once and stops" write the identical header.
The draw stream is unambiguous for the **title**: across two dwells the sweep quad
oscillates over its whole x range and resets hard to the same start value —
**1 reset inside dwell 1, 2 inside dwell 2**. It does not park.
⚠️ **But you asked about the main menu, and that is not what I measured.** Both
screens declare the same 600/720. Either the menu behaves differently, or "best
match" is weak at detecting an absence — your own caveat. **Unresolved for the
menu.**
📌 And your bounding-box refutation is taken: I have had those box figures from you
and did not question them. A box over scattered pixels locates the outermost
differing pixels, not the difference.
Detail: [`docs/re/structures/boot-splash-gap-measured.md`](../re/structures/boot-splash-gap-measured.md).