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

port: the title's sweeps loop, the black hold is 9 units, and one claim refuted

Browse Source 
THREE THINGS FROM THE DECODER, one of which I am not taking.

REFUTED: "the developer splash is one composited quad, the bounding box of the
three logos". The observed quad is 525x259 at (378,155). The three logos'
bounding box is 500x421 at (390,164) -- a 259-tall quad CANNOT contain them, and
palogo_anima alone starts at y=449, thirty-five pixels below that quad's bottom
edge. The observed quad matches the union of gamearts_eff and seta_eff, 521x261
at (379,154), to about four pixels in every dimension -- and both of those are
TRANSIENTS my own census flagged, dark by t=45, so a frame containing that quad
is a build-in frame rather than the settled screen. I cannot see their draw
stream, so I sent the arithmetic rather than a verdict, and the port keeps
drawing three: I will not stop drawing an element on a claim whose stated
identification excludes that element from its own bounding box.

THE BLACK HOLD IS 9 UNITS, NOT 12. I authored 12 from Q7's luminance plateau of
0.17-0.23 s, supported by the menus' transition quad. The Decoder counted
SUBMITTED QUADS instead -- luminance cannot separate the outgoing fade's tail
from true black. Four frames with no sprite quad at all, at 2.284 units/frame
derived from the disc as its own clock, gives 9.1 units = 0.152 s (6.9-11.4).
That overlaps the luminance figure only at the top, and the true black is SHORTER
still since both boundary frames carry picture. My 12 was supported by analogy --
a different screen's quad on a different path -- and a number that fits by
analogy loses to one measured in place. verify-dwell's bound moved with it; both
screens still agree.

THE TITLE'S SWEEPS LOOP. The oracle shows the quad oscillating over its whole x
range and resetting hard, one reset in the first title dwell and two in the
second. The loop-length field could NOT have settled it, correcting a hope I had
stated: both records declare exactly their last keyframe time, slack zero, and
"loops at 600" and "runs once for 600 and stops" write the identical header.
Verified on the two sweeps' LCM, since their periods differ: 600 and 720 realign
at 3600 units, mean diff 0, against 0.438 at half that.

Scoped to the title. The menus declare the same lengths but the oracle
measurement is of the title, and my own weak evidence points the other way there
-- best match with the sweeps off-screen, three times worse mid-screen, against a
73% on-screen duty cycle if they looped. Two weak signals in opposite directions
is a reason to scope, not to pick.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-29 20:44:56 +00:00
parent 8fb5ac8743
commit 39209eab05
6 changed files with 176 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

80
docs/port/DECISIONS.md
View File

@@ -4678,3 +4678,83 @@ off-screen**, which is evidence they run once and park.
— but it is the first evidence either way, and it points against looping. The
loop-length field the Decoder decoded (`+0x08` of a nested record's header) would
settle it outright; it is not in the pinned tag.
## Refuted — "the developer splash is one composited quad, the bounding box of the three logos"
The Decoder observed the game submitting **one 525×259 quad at (378, 155)** on
the developer splash and read it as the bounding box of the three logos, warning
that drawing three sprites there draws something the console does not. **The
arithmetic does not support it**, and the port keeps drawing three.
| | bounding box |
|---|---|
| the **three logos** | **500×421 at (390, 164)** |
| `gamearts_eff` + `seta_eff` | **521×261 at (379, 154)** |
| the observed quad | **525×259 at (378, 155)** |
**A 259-tall quad cannot contain the three logos**, which span y 164…585:
`palogo_anima` alone starts at y = 449, thirty-five pixels below that quad's
bottom edge. The observed quad matches the union of the two `_eff` **glows** to
about four pixels in every dimension.
⚠️ And those two are **transients** — my own census flagged them, dark again by
t=45 — so a frame containing that quad is a **build-in** frame, not the settled
screen. Consistent with a draw capture that starts early, which is exactly what
theirs does.
I cannot see their draw stream, so I have sent the arithmetic rather than a
verdict. What I will not do is stop drawing an element on a claim whose stated
identification excludes that element from its own bounding box.
## The black hold is 9 units, not 12 — measured in draws rather than luminance
I authored 12 from HANDOFF Q7's luminance plateau of 0.17–0.23 s, supported by
the menus' transition quad declaring black for 12. The Decoder counted **submitted
quads** instead, which is the better instrument: luminance cannot separate the
outgoing fade's tail from true black.
Frames 21–125 submit `palogo_sqex` fading to alpha 7; **frames 126–129 submit no
sprite quad at all**; 130–153 fade the developer splash in from alpha 34. Four
presented frames at 2.284 units/frame — a rate derived from the **disc as its own
clock**, because that run ran at 13.1 fps against 28 elsewhere — gives **9.1
units = 0.152 s**, ±1 frame 6.9–11.4.
⚠️ **It disagrees with the luminance figure and the disagreement is the point.**
0.114–0.190 s against 0.17–0.23 s overlaps only at the top, and the true black is
**shorter** than 9 even so: both boundary frames still carry picture. My 12 was
also supported *by analogy* — a different screen's quad on a different path,
where the boot splashes carry no quad at all. **A number that fits by analogy
loses to one measured in place.**
`verify-dwell`'s bound moved with it. Both screens still agree: publisher 4.42 s,
developer 3.78 s.
## The title's sweeps loop — measured, and the field could not have told us
The disc gives one pass (`ptloop01` t=0…600, `ptloop02` t=0…720), each ending
parked off-screen, and the port ran them once. **The oracle says they loop**:
across two title dwells the sweep quad oscillates over its whole x range and
resets hard to the same start — one reset in the first dwell, two in the second.
🔴 **And the loop-length field could not have settled it, which corrects a hope I
had stated.** Both records declare exactly their last keyframe time — **slack
zero** — and *"loops at 600"* and *"runs once for 600 and stops"* write the
identical header. 92.3 % of records on the disc are in that state, so the field
discriminates only where there **is** slack, as the plate's 105-in-120 had.
Implemented and verified on the two sweeps' **least common multiple**, since they
have different periods: 600 and 720 realign at **3600 units = 60 s**.
| separation | mean difference |
|---|---|
| **+3600 units (LCM)** | **0** |
| +1800 units | 0.438 |
| +600 units (`ptloop01` only) | 0.100 |
⚠️ **Scoped to the title**, because that is where it is measured. The menus
declare the same 600/720 and nothing on the disc distinguishes them, but my own
weak evidence points the other way there — sweeping the phase against
`live-main-menu.png`, the port matches best with the sweeps **off-screen**
(0.061 %) and three times worse mid-screen (0.183 %), and if they looped the
sweep is on screen for roughly 73 % of the cycle. **Two weak signals in opposite
directions is a reason to scope, not to pick.**