More investigation into .obj, document sprite composition in .set

doc/formats/obj.md

@@ -174,7 +174,49 @@ start of the second sprite in `pillar.obj`:
 0x0078 1b 1b 4d 9e 1b 4c 1b 4d     |   M  L M |  27  27  77 158  27  76  27  77 
 ```
 
-The first 24 bytes look quite different to the remainder of this file, lending
-weight to the 24-byte header theory.
+Total size is 3340. The first 24 bytes look quite different to the remainder of
+this file, lending weight to the 24-byte header theory.
+
+Line-by-line comparison:
+
+a 0x0000 10 01 61 01 01 00 01 00     |   a      |  16   1  97   1   1   0   1   0
+b 0x0000 fa 00 25 01 2e 00 48 00     |       H  | 250   0  37   1  46   0  72   0
+
+a 0x0008 00 00 00 00 03 00 00 00     |          |   0   0   0   0   3   0   0   0
+b 0x0008 00 00 00 00 f4 0c 00 00     |          |   0   0   0   0 244  12   0   0
+
+a 0x0010 00 00 00 00 00 00 00 00     |          |   0   0   0   0   0   0   0   0
+b 0x0010 00 00 00 00 00 00 00 00     |          |   0   0   0   0   0   0   0   0
+
+Assuming a 24-byte header, 0x0c matches "remaining pixeldata" size in both cases
+- 3 and 3316.
+
+It's odd that the last 8 bytes of this putative header are empty in both cases.
+I need to see if I can find any examples that store it.
+
+0x04 makes sense as height & width, 2 16-bit values, in `blank.obj` where we
+*know* it's 1x1 pixel.
+
+It makes less sense as such for `pillar.obj` where the individual sprites fit
+into the 64x64x64 volume of a cell:
+
+![pillar.obj as individual sprites](img/pillar_6_sprites.png)
+
+WH40K_TD.exe crashes trying to load a set referencing `pillar` in it unless it's
+in the CENTER position. Interesting.
+
+Next: keep adding cases to the header comparison above until I make sense of it
+all. Since `pillar.obj` is composable, it's not the best example I could have
+picked. Need more non-composable ones, in case that makes a difference.
+
+
+| Offset | Purpose |
+| ------ | ------- |
+| 0x0000 | ?
+| 0x0004 | ?
+| 0x0008 | ?
+| 0x000c | Size of remaining pixeldata |
+| 0x0010 | Padding?
+| 0x0014 | Padding?
 
 

doc/formats/sets.md

@@ -64,6 +64,17 @@ The `.MAP` files reference these tiles as palette entries. Each cell in the map
 has an object index and frame number. I *suspect* the object index is relative
 to the correct section of the palette. TODO: check this.
 
+The references to objects can be qualified like `_N`. When pointing to an object
+with multiple sprites in it, this seems to instruct WH40K_TD.exe to assemble the
+sprites into one logical sprite with some height.
+
+Example: pillar.obj. Only referred to as `pillar_2` in .set files. It has 6
+frames: 2x bottom, middle and tops of pillars. All 6 sprites are shown
+individually when referenced as `pillar`, but only 2 sprites, with a blue
+height indicator (presuambly), are shown when referenced as `pillar_2`:
+
+| ![pillar.obj as pillar](img/pillar_6_sprites.png) | |[pillar.obj as pillar_2](img/pillar_2_sprites_meta.png) |
+
 ## Remaining questions
 
 Do positions in the palette have special meaning? e.g. is a particular range