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

More .obj investigating. 0x80 seems to be a special value

Browse Source
This commit is contained in:
Nick Thomas
2018-03-24 21:47:34 +00:00
parent 6ba93486a1
commit 4d4c4da892
10 changed files with 269 additions and 99 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
doc/formats/img/altar_sprite_0.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 32 KiB

BIN
doc/formats/img/altar_sprite_0_paletted.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 42 KiB

52
doc/formats/obj.md
View File

@@ -242,30 +242,6 @@ Investigating the sprite data a little more, it seems that we tend to have Y
null-separated records: 1 record for sprites with a height of 1, 100 for those
with a height of 100, etc.
The first byte of each record seems likely to specify format - it's mostly
invariant (always 1 for the 1x1 examples, almost always 0x80 for the altar
sprites and the majority of other .obj files). Some other values appear too, but
not a wide distribution.
Number of bytes per row varies. `altar.obj` is diamond-shaped, and the widths
are also diamond-shaped, so perhaps 0x80 means "center the data around the X
origin and assume anything unspecified is transparent"?
Result, with my rendering according to those rules on the left and WH40K_TD.exe
on the right:
![Altar sprite 0 rendering attempt](img/altar_sprite_0.png)
Hurrah!
"Borrowing" the 256-colour palette from `Pic/wh40k.pcx`, I get:
![Altar sprite 0 with borrowed palette](img/altar_sprite_0_paletted.png)
It's still not perfect. Comparing the records in sprite 0 (blank) with those in
sprite 1 (diamond)....
Blank:
```
0x0000 d1 00 42 01
@@ -277,8 +253,8 @@ Blank:
jungtil sprite 0 (blank, draws nothing to screen
0x0018 80 3e 04 1f 80 3e 00 = row 1
80 3c 08 1f 80 3c 00
0x0018 80 3e 04 1f 80 3e 00 128 062 004 031 128 062 000
80 3c 08 1f 80 3c 00 128 060 008 031 128 060 000
80 3a 0c 1f 80 3a 00
80 38 10 1f 80 38 00
80 36 14 1f 80 36 00
@@ -307,9 +283,9 @@ jungtil sprite 0 (blank, draws nothing to screen
80 08 70 1f 80 08 00
80 06 74 1f 80 06 00
80 04 78 1f 80 04 00
80 02 7c 1f 80 02 00
7f 1f 01 1f 00 = row 32
80 02 7c 1f 80 02 00
80 02 7c 1f 80 02 00 128 002 124 031 128 002 000 = row 31
7f 1f 01 1f 00 127 031 001 031 000 = row 32
80 02 7c 1f 80 02 00 128 002 124 031 128 002 000 = roe 33
80 04 78 1f 80 04 00
80 06 74 1f 80 06 00
80 08 70 1f 80 08 00
@@ -349,7 +325,8 @@ Sprite 1:
0x0008 00 00 00 00 5a 11 00 00
0x0010 00 00 00 00 00 00 00 00
0x0018 80 3e 84 6d 6c 6e 1e 80 3e 00
0x0018 80 3e 84 6d 6c 6e 1e 80 3e 00 128 062 132 109 108 110 30 128 062 000
80 3c 88 bf 76 6e 6d 6e 76 76 6e 80 3c 00
0x0030 80 3a 84 bf 76 6e 76 04 6d 84 6e 76 7d 97 80 3a 00
80 38 86 6d 76 6e 76 6e 87 04 6d 86 6e 97 1e 6e 6e 97 80 38 00
@@ -365,13 +342,18 @@ Sprite 1:
80 24 81 76 03 97 b4 6e 97 97 6e 97 6e 97 97 1d 97 7f 6e 97 6e 1c 6e 97 6e 1e 76 7f bf 6e 97 1e 76 6e 6e 1e 97 6d 6e 97 1e 97 6e 97 6d 97 be 6e 87 6e 97 1c 97 1d 97 97 6c 97 6d 80 24 00
80 22 b7 bf 1e 6d 6d 6e 97 97 96 76 5f 1c 87 97 97 1e 97 6e 4f 1e 76 97 1e 97 1e 7e 97 1c 1e 1e 6c 6d 97 6d 76 6e 97 1e 1e 7e 1e 97 6d 76 6e ad 87 1c 6d 87 97 1d 87 97 be 97 03 6d 82 6e 97 80 22 00
80 20 81 bf 03 97 83 6e 97 6e 03 97 b6 1c 1c 6d ad 6e 97 1e 6e 97 76 6c 8f 6d 6c 96 97 1e 97 1d 97 1e 76 6e 6d 76 6e 6d 97 1e bf 1d 76 6e 97 6e 76 87 6e 87 97 96 97 6e 97 6d 6e 6e 76 6e 87 6c 6d 6d 6e 80 20 00
0x298 ...
80 1e c4 6c 87 76 6e 97 97 6e 1c 97 97 6d 97 97 6e 97 1e 97 1e 1c 6d 6d 87 76 6d be 76 6d 97 1c 97 1e bf 76 7d 97 1d 76 96 6e 6e 97 1e 97 97 6e 97 87 6e 97 97 87 76 87 6e 1c 97 6e ad 1e 6e 97 6c 76 6d 87 6d 1c 76 80 1e 00
80 1c c8 bf 97 76 97 76 ad 6e 6d 97 97 6e 6e 76 6e 97 97 1e 1c 97 97 4f 1e 76 6d 6d be 6d 6d be 7d
```
So the first *and last* two bytes in each record are invariant between the two
tiles, but the interstitial data differs. So we can make a first pass at
improving matters by just ignoring those extra bytes for now. Do they say what
the Y offset is? Why repeat it?
The first byte of each record seems width-related. Mostly matches sprite width,
at least in the cases I've looked at so far. Not in the 0x01 case, but certainly
in the 0x80 case, we then get a byte that seems to specify an offset for the
following pixeldata, and then a trailing pair of bytes with the same value.
For these tiles, the central (widest) row has 0x7f instead of 0x80.
## Debugger