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

Add some doubts on the obj format

Browse Source
This commit is contained in:
Nick Thomas
2018-03-19 11:42:57 +00:00
parent 213b2d3eb1
commit efedec4d82
2 changed files with 22 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
doc/formats/obj.md
View File

@@ -57,7 +57,7 @@ END OF FILE
Investigated by using strace on WH40K_TD.exe while starting up.
It opens and reads jungtil.obj ub 20 blocks, *after* reading jungtil.asn.
It opens and reads jungtil.obj in 20 blocks, *after* reading jungtil.asn.
Presumably each is a frame in some format or another, but seemingly *not* FLC.
Here's our list of reads:
@@ -226,4 +226,24 @@ Average bits per pixel seems to be less-than-1, e.g. for crates.obj:
So some form of compression? RLE?
How does WH40K_TD.EXE draw these?
Here's the WH40K_TD.EXE rendering:
![First first frames of jungtil.obj as rendered by WH40K_TD.exe](img/jungtil_drawn.png)
When it *does* draw them, they end up being 64x64 squares, so the possible
`width` (above) is definitely not.
A clue lies in the identical frames 0 and 12 in jungtil.obj - these are just 463
bytes, yet represent a 64x64 block (4096 bytes, assuming 1bpp). These are both
*empty frames*. One undamaged, one damaged, but identical pixel data when drawn
by WH40K_TD.exe
So a compression algorithm of some kind *must* have taken that 64x64x? block and
compressed it to just 463 bytes. But which one? `file` doesn't recognise any
magic bytes.
Perhaps there's a built-in assumption that these are all square, and 0x06 stores
the maximum X/Y coordinate (0 - 63 = 64). 0x04 then becomes something else - a
flag, perhaps? We see a stray 0x80 in the frame number sprite number field in
the .obj coordinate records; perhaps it says "this is an X type of sprite"?