Files
Sylpheed/docs/re/ui-splash-addressing.md
Sylpheed RE agent 9ca1eb50fd re(ui): answer four of the port's five asks -- splash, fade-out, focus, gamma
1 SPLASH ADDRESSING (was blocking P3). No content predicate exists: design size
fails (every extra composable bundle sampled is 1280x720, like every screen) and
element count fails (fragments run 2..15, the splash halves are 3 and 7). But
GP_TITLE needs none -- `--all` adds exactly four bundles there and all four are
real screens, with the --all index equal to the pak entry index 1:1. And there
are TWO splash screens: 11/14 are the developer logos, 10/13 are the SQUARE ENIX
publisher wordmark, which the port did not have and which the boot shows first.

2 FADE-OUT (was blocking P3). It is (a), and it is bigger than the fade quad.
Every element ends on exactly ONE untimed keyframe, which rules out (b); that
block is where the screen plays out -- quad to a=255, buttons/labels/glows to
a=0, frames hold. (c) is refuted by a null test that discriminates: a black quad
alone holds the button/background brightness ratio constant, and through the
fade it falls 6.50 -> 1.94, 3.4x monotonic.

3 FOCUS (saves P5 rework). Over-vs-instead is unobservable -- the focused sprite
covers the base at 100.0% of base-visible pixels on three pairs once aligned
(true offset (7,7); the centre alignment reads a misleading 78-84%), and
compositing both ways differs by RMSE 1.1 inside the button rect. The real defect
is the focus record's SECOND element: ptbtn0Nf.rat declares ptbtneff01.t32 (a
42x46 glowing ring, focus only) plus the bright label, where the base declares
one sprite. That ring is the marker the port draws nowhere.

5 GAMMA. The capture is not neutral: capture ~ 255*(render/255)^g, g ~ 1.34-1.49,
and the chain says it is a ramp the GAME installed, not a capture artefact. So
RMSE against captures has a floor. Reach stated: the flat patches are all dark
(render ~0-60), so midtones and highlights are unconstrained.

4 ROTATION is a human's call and is recorded in MISSION, not acted on -- the port
rotating while the reference renderer does not would make verify-screen report a
large diff meaning "the port is right". The RE half is answered: rotation is
about the declared pivot, measured against a GPU capture.

The focus record's +20 element-count word is marked 🟡 not  -- read on GP_TITLE's
ten button records only; the disc-wide check is written and still running.
2026-08-29 08:19:23 +00:00

71 lines
3.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# ❔ How to address the developer-logo splash — no content rule, but `GP_TITLE` needs none
**Status:****undecodable as a general predicate, with reach** — and ✅
**exact for `GP_TITLE`**, which is the only archive in scope. Answers the port's
*"I need a predicate, not an index."*
## The ask
The splash has no `.rat` layout child, so `is_build` rejects it and it is
reachable only through `--all` / `is_composable`, which disc-wide also admits
~1 786 non-screen bundles. The port wanted a rule that admits the splash and not
those.
## ✅ In `GP_TITLE` the problem does not arise
```
$ sylpheed-cli screen list GP_TITLE.pak 12 builds — entries 0-9, 12, 15
$ sylpheed-cli screen list --all GP_TITLE.pak 16 bundles — entries 0-15
```
`--all` adds exactly **four** bundles: entries **10, 11, 13, 14**. All four are
real screens, and **not one fragment appears**. So within this archive
`is_composable` *is* the predicate — it is exact, with no filtering needed.
⚠️ And the renumbering worry is moot here: in `GP_TITLE` the `--all` index equals
the pak entry index **1:1 across all 16**. That is an accident of this archive
having 16 composable bundles at entries 0…15, not a general property — but it
means the port can address these by entry index without the index meaning
something different from elsewhere.
## ✅ And there are TWO splash screens, not one
Rendered with `screen render --all --build <n> --primitives`
([grid](captures/title-builds/splash-both-halves-rendered.png)):
| entry | elements | what it draws |
|---|---|---|
| **10** | 3 | **SQUARE ENIX** publisher wordmark, `™` |
| **11** | 7 | **GAME ARTS** / **SETA** / **studio anima** developer logos |
| **13** | 3 | SQUARE ENIX, `®` — the twin of 10 |
| **14** | 7 | the twin of 11 |
⚠️ **The port has 11/14 and is missing 10/13** — the publisher half, which is the
*first* thing the boot sequence shows. The two halves differ only by the
trademark glyph (`™` on 10, `®` on 13), which is the region/language split this
archive uses everywhere else.
All four draw every element they declare (3/3 and 7/7), so nothing is silently
dropped.
## ❔ The general rule: looked for, not found
Two candidate predicates, both dead:
* **Design size.** Every extra composable bundle sampled is **1280×720** — the
same as every screen. It does not separate anything.
* **Element count.** The "two-element fragment" story holds in
`GP_MISSION_SELECT` (10 extras, all 2 elements) and **fails elsewhere**:
`GP_OPTIONS`'s extras have 5 and 15 elements, `GP_SAVE_LOAD`'s have 4, 5, 6, 9
and 13. The splash's own halves have 3 and 7. The ranges overlap, so no
threshold separates them.
Reach: three archives sampled beyond `GP_TITLE`, chosen because they have
non-build composables. Not a disc-wide sweep. A rule may exist in a field not
looked at — the `.prm` fade quad is one candidate
([transitions](screen-transitions.md) shows overlays lack it), untested here.
**So: the port is authoring this.** Locating the splash by entry index is the
honest description, and `name_source` should say it was located by index and not
by a rule.