From d3e1475f64570d4c5ead596063dd73370395cfaf Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Mon, 12 Oct 2026 03:19:03 +0200 Subject: [PATCH] Characterise gameplay.bin as a flat pointer table, and record volumes as unlocated Range measured: the first 40 u32 and the whole file, on levels 0 and 1 -- 1872256 and 2006400 bytes. Result: the file is a flat array of u32, opening with a small count then a run of ascending offsets, terminating on a zero: level 0 336 797472 798832 799136 464 150672 150688 314800 479920 ... ... 1847600 1845456 797808 1829056 160 1849088 1249808 1847616 0 level 1 496 799904 800128 800432 624 151152 151168 315680 481456 ... ... 1984496 1982400 800112 1966000 160 1988160 1303456 1984512 0 Both levels carry the same shape. The sentinel 160 appears at u32 index 34 on both and the zero terminator at index 38 on both, with counts 336 against 496 and 464 against 624 at the head. The leading ~38 words are a structured header whose layout is level-independent apart from its sizes. The offsets cluster into groups -- near 800000, 150000, 1050000, 1800000 -- which is what a table of pointers into several buffers looks like. Not decoded: what the pointers point into, what 160 is, and why the zero terminator sits at the same index on both levels. No gc_formats module exists for this yet; it is characterised, not parsed. On volumes: nothing resembling volumes was found here. gameplay.bin is u32 pointers throughout and holds no float data in its first 64 words read as f32 -- 59 of 64 are denormals, i.e. small integers reinterpreted. Volumes remain unlocated on the disc; nothing in the regions examined so far presents itself as one. --- docs/plan/level-assets.md | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md index f72e3e2..12b5dd6 100644 --- a/docs/plan/level-assets.md +++ b/docs/plan/level-assets.md @@ -1635,3 +1635,36 @@ continuations land on boundaries and read as separate entries. `gc_formats` module for it. The `+0x18`/`+0x20` names are section names but their structure is not established, and it is not yet shown that they index anything. + +## gameplay.bin is a flat pointer table + +**Range measured:** the first 40 `u32` and the whole file, on levels 0 and 1 -- +1,872,256 and 2,006,400 bytes. + +**Result:** the file is a flat array of `u32`, opening with a small count and +then a run of ascending offsets, and **terminating on a zero**: + + level 0: 336 797472 798832 799136 464 150672 150688 314800 479920 ... + ... 1847600 1845456 797808 1829056 160 1849088 1249808 1847616 0 + + level 1: 496 799904 800128 800432 624 151152 151168 315680 481456 ... + ... 1984496 1982400 800112 1966000 160 1988160 1303456 1984512 0 + +**Both levels carry the same shape.** The same sentinel value, `160`, appears at +`u32` index 34 on both, and the zero terminator at index 38 on both, with counts +336 against 496 and 464 against 624 at the head. So the leading ~38 words are a +structured header whose layout is level-independent apart from its sizes. + +The offsets cluster into groups -- near 800,000, near 150,000, near 1,050,000, +near 1,800,000 -- which is what a table of pointers into several buffers would +look like. + +**Not decoded.** What the pointers point into, what `160` is, and why the zero +terminator sits at the same index on both levels. No `gc_formats` module exists +for this yet; it is characterised, not parsed. + +**On volumes.** Nothing resembling volumes was found here. `gameplay.bin` is +u32 pointers throughout and holds no float data in its first 64 words read as +`f32` (59 of 64 are denormals, i.e. small integers reinterpreted). Volumes remain +unlocated on the disc -- nothing in the regions examined so far presents itself +as one.