Add some doubts on the obj format

doc/formats/obj.md

@@ -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"?
+