From 575d1a5bdd42adb1ab4a3ae53aad6db9f3206dee Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Mon, 12 Oct 2026 03:17:50 +0200 Subject: [PATCH] Correct the overlay strings from a table to a pool The previous commit described a "debug string table on 16-byte alignment". It is not a table. Dumping the 32 bytes before each run shows most are the tail of the previous string: +3104 "host0:r:/rc2/shock/wavetable.bin" 32 chars +3120 "ck/wavetable.bin" its own tail +3152 "/i5/shock/wavetable1.bin" +3168 "ble1.bin" its own tail and the 32-byte prefixes are 327 distinct out of 332 -- essentially all different, because they are just the preceding string's bytes. There is no per-record header here. It is one contiguous pool of debug text, and the 16-byte alignment is a property of how the pool was laid out, which makes continuations land on boundaries and read as separate entries. The count of 332 "strings" was therefore inflated by the same effect: it counts continuations as entries. The substance is unchanged and still useful -- the pool carries the game's own debug text, including "Camera_CollPrimTest WARNING! - grid out of bounds! (RAR)", which is direct evidence for reading the collision payload's two leading u16 as grid dimensions, and the wavetable.bin paths, which bear on the sound bank framing. Only the framing was wrong. The pool is located and counted but not parsed, and there is no gc_formats module for it. The +0x18/+0x20 names are section names but their structure is not established, and it is not shown that they index anything. --- docs/plan/level-assets.md | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md index da9e79b..f72e3e2 100644 --- a/docs/plan/level-assets.md +++ b/docs/plan/level-assets.md @@ -1595,7 +1595,7 @@ now has one: a header naming two sections, and a string table. `u32@+0x00` is **1,735,808 on all three levels**, `+0x08` is `1`, and the bytes at `+0x18` and `+0x20` spell **"crap"** and **"system misc"**. -**Result 2 -- a debug string table on 16-byte alignment.** 332 such strings on +**Result 2 -- a debug string pool, 16-byte aligned.** 332 printable runs on level 0, 362 on level 1, 351 on level 2, the first at `+0x20` and the last between 1.3 MB and 2.5 MB. They are the game's own debug text: @@ -1616,8 +1616,22 @@ are worth continuing to treat as grid dimensions despite not sizing the payload. The `wavetable.bin` paths also confirm the sound bank is loaded from named files, which bears on the `SBlk`/`DAW` framing. -**Not done.** The string table is located and counted but not parsed -- the -records preceding each string have not been identified, so there is no -`gc_formats` module for it yet. The `+0x18`/`+0x20` names are section names but +**Correction to the framing above.** This was first written up as a *string +table* of records. It is not. Dumping the 32 bytes before each run shows most of +them are the tail of the previous string: + + +3104 "host0:r:/rc2/shock/wavetable.bin" (32 chars) + +3120 "ck/wavetable.bin" -- its own tail + +3152 "/i5/shock/wavetable1.bin" + +3168 "ble1.bin" -- its own tail + +and the 32-byte prefixes are **327 distinct out of 332**, i.e. essentially all +different, because they are just the preceding string's bytes. There is no +per-record header here. It is one contiguous pool of debug text, and the +16-byte alignment is a property of how the pool was laid out, which makes +continuations land on boundaries and read as separate entries. + +**Not done.** The pool is located and counted but not parsed, and there is no +`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.