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

More .obj investigation. Looking for records in sprite data

Browse Source
This commit is contained in:
Nick Thomas
2018-03-21 21:26:07 +00:00
parent 2af6a4a500
commit 1ea123a201
2 changed files with 64 additions and 46 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
doc/formats/obj.md
View File

@@ -251,16 +251,24 @@ d: 116 * 100 = 11600. 7368 - 24 = 7344. 5.1 bits / pixel
We still don't know what the first 32 bits are all about. Perhaps they can help
to explain the differences in putative bpp.
0x002-0x003 changes in step with total number of pixels?
0x002-0x003 changes in step with total number of pixels, but that doesn't seem
to account for the difference.
| ID | 0x2-0x3 | dec LE | Number of pixels |
| -- | ------- | ------ | ---------------- |
| a | 61 01 | 353 | 1 |
| b | 25 01 | 293 | 3312 |
| d | 19 01 | 281 | 11600 |
| c | 16 01 | 278 | 11948 |
Considering sprites with a 1,1 x,y.
```
u0 u1 u2 u3 X Y pixeldata
bgtree_m 24 : ee 00 5e 01 01 01 01 1f 00
blank 0 : 10 01 61 01 01 01 01 fd 00
transpix 0 : 11 01 3c 01 01 01 01 ae 00
```
Sprites seem to end with a \x00 byte in-general, but we *only* see 0x01 in the
first byte of data for these 1x1 tiles.
Sprites with `X= 128 Y=63` *almost always* seem to have a u0..u3 of
`d1 00 42 01` with a few exceptions, e.g. `treemac{1,2}.obj`
Not clear what it means. If anything!
WH40K_TD.exe loops around "ReadInMissionFLCs", incl. address 0x0041dd10, where
it loads in all the .asc and .obj files in a set.