re: the DELTASABER plates are the loading screen, and the pak is packed EN-then-JP
This commit is contained in:
sylph-decoder
@@ -2,7 +2,11 @@
|
||||
|
||||
**Status:** ✅ `CONFIRMED` for the four screens the boot path actually shows
|
||||
(title art, `PRESS Ⓐ BUTTON`, main menu, `EXTRAS`); 🟡 `PROBABLE` for their
|
||||
Japanese twins; ❔ open for the two `DELTASABER` plates.
|
||||
Japanese twins.
|
||||
|
||||
✅ **2026-08-29 — the two "unidentified `DELTASABER` plates" are the LOADING
|
||||
SCREEN**, and the ❔ on them is withdrawn. See
|
||||
[below](#-the-deltasaber-plates-are-the-loading-screen-and-there-are-two-of-them).
|
||||
|
||||
Answers [MISSION Q2](../port/MISSION.md). The previous statement — *"build 4
|
||||
title, 5 main menu, 6/8/9 submenus"* — is **partly wrong** and is withdrawn:
|
||||
@@ -53,7 +57,7 @@ Contact sheet of every render:
|
||||
|
||||
| build | what it is | confirmed how |
|
||||
|---|---|---|
|
||||
| 0, 1 | a `DELTASABER / SYLPHEED A.I.` plate low-left on black, no background | ❔ **not observed running.** Never seen in the boot path, the main menu, `EXTRAS` or `MISSION SELECT` |
|
||||
| 0, 1 | ✅ **the LOADING screen**, plain — a `DELTASABER / SYLPHEED A.I.` plate low-left on black, no background. 7 elements, all named `pgloading_*` | ✅ **decoded from the declaration table**, not observed running |
|
||||
| **2**, 3 | the `PRESS Ⓐ BUTTON` plate — **an overlay build of its own**, not a state of build 4 | ✅ seen composited over build 4 on the live title, at the same rect our render puts it |
|
||||
| **4** | title art, English (`PROJECT SYLPHEED`, ™, `(C)2006,2007 SQUARE ENIX`) | ✅ [`live-title-press-a.png`](captures/title-builds/live-title-press-a.png) |
|
||||
| 7 | the same, Japanese | 🟡 renders as the JP twin of build 4; the container runs an English locale, so it was not seen |
|
||||
@@ -61,7 +65,96 @@ Contact sheet of every render:
|
||||
| 8 | the same, Japanese | 🟡 as above |
|
||||
| **6** | the `EXTRAS` submenu, English: MISSION SELECT / MOVIE THEATER / BACK, footer `Ⓐ : OK Ⓑ : Back` | ✅ [`live-extras.png`](captures/title-builds/live-extras.png) |
|
||||
| 9 | the same, Japanese | 🟡 as above |
|
||||
| 10, 11 | the same `DELTASABER` plate as build 0, over a dark circuit-line background | ❔ **not observed running** |
|
||||
| 10, 11 | ✅ **the LOADING screen**, dressed — the same plate over a dark circuit-line background. 10 elements, the same seven plus `pgloading_eff00.prm`, `pgloading_loop5.rat` and `pgloading_baseeff.t32` | ✅ **decoded from the declaration table**, not observed running |
|
||||
|
||||
## ✅ The `DELTASABER` plates are the LOADING screen, and there are two of them
|
||||
|
||||
**2026-08-29. Decoded — the authors' own element names, out of the declaration
|
||||
table.** No renderer, no capture, no inference. Every element of all four
|
||||
bundles is prefixed `pgloading_`:
|
||||
|
||||
| build | entry | elements |
|
||||
|---|---|---|
|
||||
| 0, 1 | 0, 1 | `pgloading_loop1.rat` `pgloading_loop3.rat` `pgloading_str.t32` `pgloading_line.t32` `pgloading_loop4.rat` `pgloading_eff01.t32` `pgloading_eff02.t32` |
|
||||
| 10, 11 | 12, 15 | the same seven, plus `pgloading_eff00.prm` `pgloading_loop5.rat` `pgloading_baseeff.t32` |
|
||||
|
||||
Reproduce:
|
||||
|
||||
```bash
|
||||
sylpheed-cli screen info --build 0 "$SYLPHEED_DISC/dat/GP_TITLE.pak"
|
||||
sylpheed-cli screen info --build 10 "$SYLPHEED_DISC/dat/GP_TITLE.pak"
|
||||
```
|
||||
|
||||
`DELTASABER / SYLPHEED A.I.` is the artwork on `pgloading_str.t32` — the loading
|
||||
screen's caption, not the screen's identity. Reading the picture named the plate;
|
||||
reading the file names the screen.
|
||||
|
||||
⚠️ This also removes the reason the pair was open. The previous row said *"never
|
||||
seen in the boot path, the main menu, `EXTRAS` or `MISSION SELECT`… a mission
|
||||
load is the remaining candidate"*. It is a **loading** screen: it is not supposed
|
||||
to appear on any of those, and the remaining candidate was right.
|
||||
|
||||
### 🟡 Which is `LOADING` and which is `LOADING2` — the executable names five
|
||||
|
||||
`sub_821C4EB0` builds `GamePart_Title` and asks its table for five sub-entries in
|
||||
this order, one `bl sub_821CEDF8` each, setting an error flag on any failure:
|
||||
|
||||
| call site | string | VA |
|
||||
|---|---|---|
|
||||
| `0x821C503C` | `TITLE_SCREEN` | `0x820A3D3C` |
|
||||
| `0x821C5068` | `BUTTON` | `0x820A339C` |
|
||||
| `0x821C5090` | `TITLE_MENU` | `0x820A3D30` |
|
||||
| `0x821C50BC` | `LOADING` | `0x820A214C` |
|
||||
| `0x821C50E4` | `LOADING2` | `0x820A3D24` |
|
||||
|
||||
✅ **Checked against the image, not just the database** — `/image/sylpheed.pe` at
|
||||
`0x821C503C`, `0x821C5090`, `0x821C50BC`, `0x821C50E4` reads `38aa3d3c`,
|
||||
`3baa3d30`, `38aa214c`, `38aa3d24`, exactly the `addi rX, r10, <lo16>` the
|
||||
database shows, with `r10 = 0x820A0000` set two instructions earlier.
|
||||
|
||||
That is five named title-side screens, and `BUTTON` is what the `PRESS Ⓐ BUTTON`
|
||||
overlay would be called — which the corpus had already isolated as a build of its
|
||||
own (pair B) on capture evidence alone.
|
||||
|
||||
🟡 **Two loading screens named, two loading bundles found — but nothing observed
|
||||
maps one to the other.** `LOADING` is the 7-element plain plate and `LOADING2`
|
||||
the 10-element dressed one *if* the suffix means "the second, richer variant",
|
||||
and that is a guess about a name. The port should treat the pairing as
|
||||
**undecided** and not carry either name into an asset path.
|
||||
|
||||
Also note the lookup is **not** by pak TOC hash: at `0x821C5118`–`0x821C512C` the
|
||||
game hashes `BASE_INFO` and `TITLE_MENU` with `sub_82455C78` (the same name-hash
|
||||
[`hash.rs`](../../crates/sylpheed-formats/src/hash.rs) implements) and splices
|
||||
the two 32-bit results into one 64-bit key. So these strings key a **sub-table
|
||||
inside the GamePart's own record**, not an archive entry — which is why
|
||||
`pak list` resolves none of `GP_TITLE`'s 16 names.
|
||||
|
||||
## 🟡 Which member of each pair is English — the archive is packed in two halves
|
||||
|
||||
The port asked which member of pairs A, B and H is which locale, since those
|
||||
three render byte-identically and no capture can tell them apart. The **data
|
||||
segment** can:
|
||||
|
||||
| | entries | data offset |
|
||||
|---|---|---|
|
||||
| first half | 0, 2, 4, 5, 6, 10, 11, 12 | 0 … 507 904 |
|
||||
| second half | 1, 3, 7, 8, 9, 13, 14, 15 | 6 078 464 … 10 868 736 |
|
||||
|
||||
Every one of the eight pairs has **exactly one member in each half**, and in all
|
||||
three pairs whose language is visible — C (4/7), D (5/8), E (6/9) — the English
|
||||
build is the one in the **first** half. `GP_TITLE.p00` is one locale's eight
|
||||
bundles followed by the other's; the TOC interleaves them only because it is
|
||||
sorted by name hash.
|
||||
|
||||
So: **first half = English**, i.e. builds 0, 2, 4, 5, 6, 10 are English and 1, 3,
|
||||
7, 8, 9, 11 are Japanese.
|
||||
|
||||
⚠️ 🟡 not ✅. The rule is 8/8 structurally consistent and 3/3 where it can be
|
||||
checked, but the three pairs it is *used* for are exactly the three it cannot be
|
||||
checked on. Reach of the negative: nothing in the bundle bytes themselves — the
|
||||
header, the declaration table, the element names — differs between the twins of
|
||||
pairs A, B and H at all; they render byte-identical PNGs. If a locale marker
|
||||
exists it is not in the bundle.
|
||||
|
||||
## ✅ The splash — the four "non-build" entries, rendered
|
||||
|
||||
|
||||
Reference in New Issue
Block a user