The answers for the port's five screens were spread across a dozen documents and none of them said how good the result IS. Measured: screen build drawn corr vs capture alignment title 4 15/24 +0.9500 dy=0 dx=0 main menu 5 11/16 +0.9460 dy=0 dx=0 EXTRAS 6 13/18 +0.9440 dy=0 dx=0 publisher splash 10 2/3 +0.9600 dy=0 dx=0 developer splash 11 6/7 +0.9643 dy=0 dx=0 Every one aligns at exactly zero offset over a +/-2 px search in both axes, so placement and scale are right and the residual is tone and detail rather than geometry. The drawn/total counts are not slack. Each undrawn element has a reason already documented: kind & 0x4 ghost instances (4 on the title), .prm primitives off by default (2 per menu, 1 per splash), loop* animations off by default and off-screen at rest (2 per menu screen), and the 8AX name mismatch (1 per menu screen) whose art reaches the screen anyway via ptbase. 4+2+2+1 = 9, 2+2+1 = 5, 1. Nothing unexplained. The residual is ranked for a consumer: tone first (gamma 1.34-1.49, the game's own display ramp), then 8AX resolution, then one drawable paint-order tie on EXTRAS alone, then rotation-decoded-but-not-rendered which does not affect these five at rest. Reach stated: these are static composites at the resting pose against single frames, so nothing here speaks to animation, and a whole-frame correlation is a sanity figure rather than a per-element check.
3.2 KiB
3.2 KiB
✅ The five screens, end to end — what each one is actually worth
Status: ✅ measured, 2026-08-29. One page, because the answers for these five screens are otherwise spread across a dozen documents and none of them says how good the result is.
Rendered with sylpheed-cli screen render (adding --all --black for the two
splash halves) and correlated against the committed live captures.
| screen | build | elements drawn | corr vs capture | alignment |
|---|---|---|---|---|
| title | 4 | 15 / 24 | +0.9500 | dy=0 dx=0 |
| main menu | 5 | 11 / 16 | +0.9460 | dy=0 dx=0 |
EXTRAS |
6 | 13 / 18 | +0.9440 | dy=0 dx=0 |
| publisher splash | 10 | 2 / 3 | +0.9600 | dy=0 dx=0 |
| developer splash | 11 | 6 / 7 | +0.9643 | dy=0 dx=0 |
Every one aligns at exactly zero offset — searched ±2 px in both axes — so placement and scale are right and the residual is tone and detail, not geometry.
Every omission is accounted for
The counts are not slack; each undrawn element has a reason already documented:
| screen | not drawn | why |
|---|---|---|
| title | ptlogo1×2, ptlogo2×2 |
kind & 0x4 ghost instances — the draw capture shows one quad per wordmark |
pteff00.prm, pteff02.prm |
.prm primitives, off without --primitives |
|
ptloop01.rat, ptloop02.rat |
loop* animations, off without --animated; at rest both sit off-screen |
|
pteff04.t32 |
the 8AX name mismatch — the art is on screen, drawn via ptbase2 (8AX) |
|
main menu, EXTRAS |
2 .prm + 2 loop* + pteff05.t32 |
same three reasons |
| both splashes | palogo_eff0.prm |
.prm primitive |
4 + 2 + 2 + 1 = 9 on the title; 2 + 2 + 1 = 5 on each menu; 1 on each splash. Nothing is unexplained.
What the residual is, per screen
Ranked by what a port would notice:
- Tone. The capture is darker than the composite by a gamma of ≈1.34–1.49 (tone curve) — the game's own display ramp, not an emulator artefact. This is the largest single contributor to the 0.94–0.96 rather than higher.
8AXresolution. The background is drawn from the 640×360ptbaseupscaled 2×, where the game uses the native 1280×7208AX(measured, two screens at 68 % of ceiling).- Paint-order ties on
EXTRASonly. One drawable overlapping tie (ptframe3×ptframe4), and the capture is consistent with our order (check). The other four screens use orders measured from the game. - Rotation is decoded but not rendered — and does not affect any of these five at rest (rotation).
Reach
- These are static composites at the resting pose against single frames. Nothing here says the animation is right; Q1's interpolation law is settled but a multi-keyframe group's absolute timing is not (time unit).
- Correlation on a whole frame is dominated by large areas. It is a sanity figure, not a per-element check — the per-element work is in the documents linked above.