Some more map progress

doc/formats/maps.md

@@ -248,11 +248,11 @@ We're specifying a viewport on a statically-defined area with a width of 130,
 and a length of 100. The viewport is centered on the middle of that area and
 anything outside it is clipped away.
 
-## Per-coordinate data
+## Per-cell data
 
 All .MAP files are the same size once uncompressed, regardles of width and
 length parameters, suggesting that they each have fixed-sized records for every
-possible coordinate, regardless.
+possible cell.
 
 Skipping the header we know about, we have data like this:
 
@@ -285,8 +285,10 @@ Skipping the header we know about, we have data like this:
 000001F0   38 00 00 00  88 01 00 00  00 00 00 FF  00 00 00 00  8...............
 ```
 
-It would be very neat if the per-coordinate data started at 0x100 and took 16
-bytes per coordinate.
+It would be very neat if the per-cell data started at 0x100 and took 16 bytes
+per coordinate, but to get objects in my map to line up properly with cells in
+WH40K_TD.exe, I've had to start parsing these rows at `0x0120` instead. Still
+tentative!
 
 Total number of possible coordinates is 100x130x7 = 91,000 = 1,456,000 bytes.
 
@@ -387,9 +389,55 @@ as expected, so this is a good hint that the data is actually arranged in
 `[z][y][x][16]` blocks and that I either have the right offset, or I'm out by a
 well-aligned amount.
 
-Trying to constrict to the viewport currently cuts off much of this displayed
-map, suggesting that I've got something wrong in the calculation somewhere. Need
-to dig into that more.
+Investigation has so far suggested the following:
+
+* `Cell[0]` seems related to doors and canisters. Observed:
+    * Imperial crate: 0x28
+    * Door: 0xB8
+* `Cell[1]` seems related to special placeables (but not triggers). Bitfield. Observed:
+    *  0x01: Reactor
+    *  0x20: Door or door lock?
+    *  0x40: Animated object
+* `Cell[2]` hasn't been seen with a value > 0 yet
+* `Cell[3]` Object 0 (Surface) Area (Sets/*.set lookup)
+* `Cell[4]` Unsure at present, but it varies between a narrow range of values.
+  I've seen 128 - 147. Broadly matches the terrain layout.
+* `Cell[5]` Object 1 (Left) Area (Sets/*.set lookup) **ASSUMED**.
+    * It's in the right place, and there seems to be correspondence, but not as
+      neatly as the other 3 columns. Often off-by-1
+* `Cell[6]` Wide range of values, 0 - 161 observed. Seems to have identity with
+   some blood splatters, etc
+* `Cell[7]` Object 2 (Right) Area (Sets/*.set lookup)
+* `Cell[8]` Wide range of values, 0 - 159 observed. 
+* `Cell[9]` Object 3 (Center) Area (Sets/*.set lookup)
+* `Cell[10]` Varies from 0 - 248. Unclear what for, broadly follows terrain
+* `Cell[11]` all 255?
+* `Cell[12]` all 0?
+* `Cell[13]` all 0?
+* `Cell[14]` all 0?
+* `Cell[15]` shows squad positions, MP start positions, etc, as 0x04
+
+Mapping the altar in Chapter01 to the map01 set suggests it's a palette entry
+lookup, 0-indexed. `U` debug in WH40K_TD.exe says the cell's `Object 3-Center`
+has `Area 67` and `Sprite 1`. In `Sets/map01.set`, entry 67, zero-indexed and
+ignoring non-palette data, is an altar.
+
+The data of that cell is:
+
+```
+maps.Cell{
+    0x18, 0x0, 0x0, 0x2, 0x99, 0x1, 0x0, 0x0,
+    0x0, 0x43, 0x81, 0xff, 0x0, 0x0, 0x0, 0x0
+}
+```
+
+So `CellIdx == 9` points to the center object's Area, looked up in the set file!
+
+![Pinning down cell index 9](img/chapter01_cell_index_9.png
+
+I still see weird artifacts on middle Z-layers making me think I'm off the
+stride or perhaps there's a data block partway through or something. Or maybe
+the data's just born that way.
 
 ## Trailer
 
@@ -459,4 +507,4 @@ Around 001841A0: mission objectives!
 ```
 
 Since all the files are exactly the same length uncompressed, I'm going to
-assume these are all a fixed number of fixed-size records when looking into it.
+assume these are all a fixed number of fixed-size records when looking into it.