lupine/ordoor
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Add the view-map command and some exploration of results

Browse Source
This commit is contained in:
Nick Thomas
2018-03-18 03:35:03 +00:00
parent 60b2a416c4
commit d572a19352
7 changed files with 331 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

63
doc/formats/maps.md
View File

@@ -293,6 +293,8 @@ Total number of possible coordinates is 100x130x7 = 91,000 = 1,456,000 bytes.
Uncompressed file size is always 1,458,915 bytes, leaving 2,915 bytes over for
header and any trailing data.
How are the rows structured? `[z][y][x]`?
Looking at the data around 0x163890, we see:
```
@@ -328,6 +330,67 @@ So this looks like a good working theory.
Wherever they start, these rows must refer to the object sets somehow. We also
need to work out how they're arranged.
Disassembly of WH40K_TD.EXE suggests a file `Engine::CellInfo` at 0x4226F0. It
dumps the following information:
* Mission exit: true / false
* Smoke: true / false
* Sprite: true / false
* Vehicle: true / false
* Net start: true / false
* Spell: true / false
* Trigger: true / false
* Breadcrumb: true / false
* Door: true / false
* Lock: true / false
* Reactor: true / false
* Objective: true / false
* Canister number %d
* Cell visible %d
* Tile visible %d
* N0 - N7: true / false (seems to be a bitfield)
* Object 0 SURFACE: true / false
* Object area %d
* Curr sprite %d
* Object 1 LEFT: true / false
* Object area %d
* Curr sprite %d
* Object 2 RIGHT: true / false
* Object area %d
* Curr sprite %d
* Object 3 CENTRE: true / false
* Object area %d
* Curr sprite %d
Presumably at least some of these attributes come from the records identified
above. Will need to experiment to establish correlations. Items of interest:
* A cell can have 4 objects in it - a surface, a left, a right, and a centre.
* Presumably a surface is what we show on the ground, and it will be set for
"ground level" data.
Press "U" to get to the screen!
![Debug screen](img/cell-information-debug.png)
I've added a `view-map` command to explore the data graphically. Each of the 16
bytes in a cell row must have a function; comparing a known map to how it looks
in WH40K_TD.exe can help me to unravel that function.
Here's a side-by-side comparison of Chapter3.MAP, investigating CellIndex=3 and
Z index = 0
![Map comparison](img/chapter_01_cell_index_3.png)
Incrementing the Z index shows the building and terrain progressively changing
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.
## Trailer
Assuming the theory above is correct, we have trailer data starting at