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

Discover how frames are encoded, use that knowledge to (finally) get the viewport locked in

Browse Source
This commit is contained in:
Nick Thomas
2018-03-18 15:39:50 +00:00
parent 2f02c7bbf3
commit 961a213752
4 changed files with 53 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
doc/formats/maps.md
View File

@@ -287,7 +287,7 @@ Skipping the header we know about, we have data like this:
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
WH40K_TD.exe, I've had to start parsing these rows at `0x0110` instead. Still
tentative!
Total number of possible coordinates is 100x130x7 = 91,000 = 1,456,000 bytes.
@@ -379,8 +379,8 @@ 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
Here's an (out-of-date) side-by-side comparison of Chapter3.MAP, investigating
CellIndex=3 and Z index = 0.
![Map comparison](img/chapter_01_cell_index_3.png)
@@ -400,17 +400,15 @@ Investigation has so far suggested the following:
* 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[4]` Object 0 (Surface) Sprite + ???
* Bottom bits encode the sprite (frame number in the .obj file)
* 0x80 is set too. A flag?
* `Cell[5]` Object 1 (Left) Area (Sets/*.set lookup)
* `Cell[6]` Object 1 (Surface) Sprite + ???
* `Cell[7]` Object 2 (Right) Area (Sets/*.set lookup)
* `Cell[8]` Wide range of values, 0 - 159 observed.
* `Cell[6]` Object 2 (Right) Sprite + ???
* `Cell[9]` Object 3 (Center) Area (Sets/*.set lookup)
* `Cell[10]` Varies from 0 - 248. Unclear what for, broadly follows terrain
* `Cell[10]` Object 3 (Right) Sprite + ???
* `Cell[11]` all 255?
* `Cell[12]` all 0?
* `Cell[13]` all 0?
@@ -435,10 +433,6 @@ 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
Assuming the theory above is correct, we have trailer data starting at