fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: the splash .prm measured -- and its paint order is a sequence, not depth

Browse Source 
ui-prm-primitives recorded that where a .prm paints on a screen without a
measured order is unsolved. For the developer splash it is now measured.

Every frame opens with two full-screen draws before any sprite. The
second is untextured in all 212 frames with a constant vertex colour of
FF000000 -- opaque black -- matching palogo_eff0.prm's declaration
exactly: kind 0x10, pivot (640,360) -> 1280x720, one keyframe, a = 255.
So the splash backdrop is an opaque black full-screen quad from the
bundle itself, painted behind every sprite, which is why a splash render
needs --black rather than the default backdrop.

Not a general rule, and said so: the measured main-menu order puts
pteff02.prm at position 4 and pteff00.prm LAST, the latter being the
screen-transition fade.

And a correction to an existing row. measured_paint_order returns
[0, 2, 4, 6, 1, 3, 5] for the splash, described as "the .prm, then all
three glows, then the three logos". But the glows and the logos never
appear in the same frame -- 0 overlapping frames in 235 -- and two
elements that never co-occur have no observable relative depth. Between
those halves the vector records the order they were SEEN IN, not a
front-to-back relationship.

That does not make the render wrong, and element 0 is a real depth
observation since the .prm co-occurs with everything. But the type of the
claim matters: reading the vector as depth invites compositing all seven
elements at once, which is exactly what does not reproduce the screen.

METHOD: two things that never co-occur have no observable relative order;
when recording an order, note which pairs actually appeared together.
This commit is contained in:
Sylpheed RE agent
2026-08-29 05:06:37 +00:00
parent 7988f52ce7
commit 2532c056be
4 changed files with 80 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
docs/re/structures/ui-prm-primitives.md
View File

@@ -174,3 +174,54 @@ have never been measured, so they are not in the table.
* ❔ **The 8 non-full-screen ones**, including two with a zero dimension.
* 🟡 `kind = 0x3010` (38 elements) is `0x10` plus `0x3000`, the button-record
bits — a primitive that is part of a button. Unexamined.
---
## ✅ Measured on the splash: the `.prm` paints FIRST, full-screen, opaque black
**2026-08-29.** This page recorded that where a `.prm` paints "on a screen
without a measured order is unsolved". For the developer splash it is now
measured, from the 235-frame draw capture.
Every frame begins with two full-screen draws before any sprite:
```
f120: [1280x720] [1280x720] [499x241] …
^clear ^this one
```
The second is **untextured** in all **212** frames, with a constant vertex colour
of **`FF000000`** — opaque black. That matches `palogo_eff0.prm`'s declaration
exactly:
| declared | observed |
|---|---|
| `kind = 0x10` (the primitive marker) | untextured draw |
| pivot (640,360) → **1280×720** | 1280×720 quad |
| **one** keyframe, `a = 255` | constant across 212 frames |
| — | vertex colour `FF000000` |
So the splash's backdrop is an **opaque black full-screen quad from the bundle
itself**, painted behind every sprite — not a clear colour, which is why our
splash renders need `--black` to match.
⚠️ **Not a general rule.** The measured *main menu* order puts `pteff02.prm` at
position 4 and `pteff00.prm` **last** — that one is the screen-transition fade.
A `.prm` paints where its screen's order says; the splash's happens to be first.
## ⚠️ And the splash's "measured paint order" is a SEQUENCE, not a depth order
`measured_paint_order` returns `[0, 2, 4, 6, 1, 3, 5]` for the splash, commented
*"the full-screen `.prm`, then all three glows, then the three logos"*.
The draw capture shows the glows and the logos **never appear in the same frame**
— 0 overlapping frames in 235 ([group start time](ui-group-start-time.md)). Two
elements that never co-occur have **no observable relative depth**. What that
vector records between its glow half and its logo half is the *temporal* order
they were seen in, not a front-to-back relationship.
🟡 This does not make the render wrong — compositing them in that order is
harmless, and the ✅ for element 0 (the `.prm` first) *is* a real depth
observation, since it co-occurs with everything. But the type of the claim
matters for a consumer: **treating the vector as depth invites compositing all
seven elements at once, which is exactly what does not reproduce the screen.**