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

re: withdraw the splash frame boundaries -- count the batch, not the logged quads

Browse Source 
The port refuted the boundaries in boot-splash-dwells-are-declared.md by
arithmetic: the two splash spans gave 2.237 and 2.414 units/frame, 7.9% apart on
one boot of one guest, which must be one number. They proposed the spans were
anchored on different elements.

The log says the cause is worse. The developer splash batches SIX quads into one
draw (indices=24) and the log dumps only the first two. While the three glows are
alive they occupy that prefix, so the three wordmarks are invisible to the log
until the glows stop being submitted at t=45. "Developer wordmarks first drawn at
frame 140" was the logging prefix shifting, not the game -- and the same defect
explains why palogo_anima never appeared at all.

The fix costs nothing: indices/4 is how many quads the draw actually holds, and
the 8-vertex cap cannot touch it. Its transitions land exactly where the declared
count of elements with alpha>0 changes, giving free calibration points:

  publisher   1->2 quads at frame 5.5 (t=15), 2->1 at 22.5 (t=45), ends 119.5 (t=255)
  developer   3->6 quads at frame 126.5 (t=15), 6->3 at 139.5 (t=45), ends 209.5 (t=210)

That yields 1.765 and 2.165 units/frame on the publisher, 2.308 and 2.357 on the
developer -- the developer's two independent segments agreeing to 2%, and the rate
rising 33% across the run. One cause for both the port's 7.9% inconsistency and
this page's open 4.1% publisher error, exactly as they predicted: the publisher
splash runs during the first seconds, where the rate is furthest from its later
value. It also means no single units-per-frame figure describes a run here, which
is the dwell-is-emulator-paced conclusion from a third direction.

The declared dwells (255 and 210 units) and the corpus's three-cold-boot
confirmation are untouched -- neither uses this draw log.

METHOD.md gains the general form: when an instrument truncates, the surviving
sample is not random, it is the first N, and what falls in the first N is itself a
moving function of the thing being measured. A truncated view looks like a
complete view of a smaller set.

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 21:34:51 +00:00
parent 89d90294b4
commit d8d834709f
2 changed files with 72 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
docs/re/structures/boot-splash-dwells-are-declared.md
View File

@@ -25,27 +25,54 @@ Three separate measurements of this container's rate — 13.1 fps, ~28 fps, and
one — say the same thing from another direction. A port that authors seconds is
authoring one run's pacing.
## The boundaries, from the draw stream
## 🔴 The boundaries — corrected, after the port refuted them
Read with the per-quad parser, this boot:
An earlier version of this page read element visibility off *which quads appear
in the log*. **That is wrong**, and the port caught it by arithmetic: the two
splash spans came out at 2.237 and 2.414 units/frame, 7.9 % apart on one boot of
one guest, which should be one number.
| event | frame |
|---|---|
| `palogo_sqex_eff` — the publisher's glow | 1 |
| `palogo_sqex` — the wordmark | **6** – 119 |
| no sprite drawn at all | 120 – 122 |
| `gamearts_eff` + `seta_eff` — the developer's glows | **123** – 139 |
| `palogo_gamearts` + `palogo_seta` — the wordmarks | 140 – 209 |
| intro video (a 640×360 pair per frame) | **216** – 563 |
Their diagnosis was that the spans were anchored on different elements — the
publisher's on its wordmark, the developer's on its glows. The log says the cause
is worse: **the developer splash batches SIX quads into one draw and the log dumps
only the first two.** While the glows are alive they occupy that prefix, so the
three wordmarks are invisible to the log until the glows stop being submitted.
"Developer wordmarks first drawn at frame 140" was the **logging prefix shifting**,
not the game.
The 3-frame black gap replicates the 4-frame gap measured in the earlier boot,
within the ±1 frame both are quantised to — consistent with the ~9 units in
[`boot-splash-gap-measured.md`](boot-splash-gap-measured.md).
✅ **The fix is to count the batch, not the logged quads.** `indices / 4` is the
number of quads the game is submitting, and the 8-vertex cap cannot touch it. The
count changes exactly where the declared set of elements with alpha > 0 changes:
⚠️ **`palogo_anima` never appears**, and that is almost certainly the 8-vertex cap
rather than a fact about the game: the developer bundle has 7 elements batched into
one draw, and only the first two quads are logged. This is the trap that produced
the `eff3` false negative, so it is named rather than reported.
| splash | transition | frame | t |
|---|---|---|---|
| publisher | 1 → 2 quads, the wordmark joins the glow | 5.5 | **15** |
| | 2 → 1, the glow ends | 22.5 | **45** |
| | last drawn | 119.5 | **255** |
| developer | 3 → 6 quads, three wordmarks join three glows | 126.5 | **15** |
| | 6 → 3, the glows end | 139.5 | **45** |
| | last drawn | 209.5 | **210** |
## ✅ And that explains the 4.1 %: the rate drifts through the run
| segment | units | frames | units/frame |
|---|---|---|---|
| publisher, t = 15 → 45 | 30 | 17 | **1.765** |
| publisher, t = 45 → 255 | 210 | 97 | **2.165** |
| developer, t = 15 → 45 | 30 | 13 | **2.308** |
| developer, t = 45 → 210 | 165 | 70 | **2.357** |
**Within the developer splash the two independent segments agree to 2 %.** Across
the run the rate rises from ~1.76 in the first seconds to ~2.36 — a **33 % drift**.
That is one cause for both the port's 7.9 % inconsistency and this page's open
4.1 % publisher error, which is what they predicted: *"I'd expect one problem
behind a 7.9 % inconsistency and a 4.1 % error on the same screen before I'd
expect two."*
⚠️ It also means **no single units-per-frame figure describes a run here**, which
is the same conclusion as the dwell being emulator-paced, arriving from a third
direction.
## 🔴 The instrument's resolution is one buffer flush, not one frame
@@ -68,10 +95,9 @@ estimates are not available and were withdrawn before being reported.
## What is still open
❔ The publisher's 4.1 % error against its declared 4.250 s is larger than the
developer's 1.1 %, across only three corpus boots plus this one. Whether that is
run-to-run pacing or something the publisher splash does differently is not
settled.
✅ The publisher's 4.1 % error against the developer's 1.1 % is **explained** by
the units/frame drift above — the publisher splash runs during the first seconds,
where the rate is furthest from its later value.
⚠️ The intro-video boundary (frame 216) is 7 frames after the developer splash's
last draw, but those 7 frames span **1.77 s** by the naive map — deep inside the