ReaperOfVeriod/Going-Commando
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Correct: the gap between collision and moby is texture data

Browse Source 
The previous commit claimed ~6.2 MB of unidentified data sat between the
collision header and the first moby class, and speculated it might be
moby_anim. That was wrong, and it came from quoting a size before bounding
the thing it measured.

Looking at the bytes rather than only the offsets: the range is dominated by
8-bit indexed texture data. Byte-value concentration distinguishes them
cleanly -- a texture block draws on a small palette, code and collision data
does not. 18 of 21 sampled 4 KB blocks fall under 200 distinct byte values,
against 249 for tfrags and 209 for collision.

The real layout on level 0:

  collision  2615232 .. 3518544   (header plus its declared 903,248 payload)
  textures   3518848 .. ~8832192
  moby       8832192 ..

The texture table's data_offset values stop at 5326208, which is what made
the gap look genuine. Mip chains extend well past the last entry's offset,
so sizing a region from a table of first-level offsets understates the data
it points at.

Three of the 21 blocks are not texture-like, so something is mixed in that
is still unidentified. It is not 6.2 MB of moby_anim.

This is the third number this session that looked load-bearing and turned
out to rest on an unbounded measurement. The pattern is consistent enough
to be worth stating plainly: sizes derived from tables or offsets are not
evidence until the bytes underneath have been looked at.
This commit is contained in:
ReaperOfVeriod
2026-10-11 03:05:07 +02:00
parent 8b98d388f7
commit db414b3d5f
1 changed files with 23 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/formats/core-data-regions.md
+23 -12
View File
@@ -49,7 +49,7 @@ that nothing yet accounts for.
the disc test asserts it, so the gap stays visible rather than being papered the disc test asserts it, so the gap stays visible rather than being papered
over by clamping to the end of the lump. over by clamping to the end of the lump.
## Found by printing it: an unnamed region between collision and moby ## Correction: it is mostly texture data, not an unnamed region
Adding the region table to `gc-extract probe` made the gap visible Adding the region table to `gc-extract probe` made the gap visible
immediately, which is the point of printing it. immediately, which is the point of printing it.
@@ -64,16 +64,27 @@ but collision's own header declares a payload of 903,248 bytes. So the range
between the collision header and the first moby class is **6.2 MB**, and between the collision header and the first moby class is **6.2 MB**, and
almost none of it is collision. almost none of it is collision.
The successor rule is right -- a region does end where the next begins -- but The first conclusion drawn from this -- that ~6.2 MB of unidentified data sat
"the next" is not yet known here. `collision..moby` is really between collision and moby, possibly `moby_anim` -- **was wrong**, and it was
`collision + <something unnamed> .. moby`. The name is wrong, not the bound. wrong because of the same failure that produced the other two bad numbers this
session: quoting a figure before bounding it.
Candidate homes for those 6.2 MB, in rough order of likelihood: the moby and Checking the bytes rather than just the sizes: the range is dominated by 8-bit
tie model *animation* data that `moby_anim` would need, volume data, or indexed texture data. Byte-value concentration (a texture block uses a small
per-class runtime structures. The tfrag texture texels are already accounted palette; code and collision data does not) puts 18 of 21 sampled 4 KB blocks
for and sit earlier in the lump. under 200 distinct byte values, against 249 for tfrags and 209 for collision.
Until that region is named, any per-format probe reading between the collision So the real layout is:
header and the first moby class is reading something this table does not
describe. Worth resolving before starting `moby_anim`, since that format is the | region | start | end |
most likely tenant of the space. |------------|----------|------------------|
| collision | 2615232 | 3518544 |
| textures | 3518848 | ~8832192 |
| moby | 8832192 | first tie class |
The texture table's `data_offset` values only reach 5326208, which is why the
gap looked real: mip chains extend well past the last entry's offset. A region
sized from a table of first-level offsets understates the data it points at.
Three of the 21 sampled blocks are not texture-like, so something is mixed in
and is not yet identified, but it is not 6.2 MB of `moby_anim`.