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

Respect sprite X and Y offsets

Browse Source 
This makes menus display more correctly, and also fixes trees and other
objects on the main map, although it messes up bounds clipping (sigh).
This commit is contained in:
Nick Thomas
2020-03-21 00:56:35 +00:00
parent eb5c4430e8
commit 7a8e9dbd97
10 changed files with 109 additions and 55 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
doc/formats/obj.md
View File

@@ -202,15 +202,13 @@ in the CENTER position. Interesting.
| Offset | Purpose |
| ------ | ------- |
| 0x0000 | ?
| 0x0000 | x,y offset (16 bits each) |
| 0x0004 | x,y size (16 bits each) |
| 0x0008 | ? (blank in all cases so far)
| 0x000c | Size of remaining pixeldata |
| 0x0010 | Padding? |
| 0x0014 | Padding? |
We still don't know what the first 32 bits are all about.
The volume represented by a cell is a little odd. We see three faces of a fake
3D volume of size 64x64x32(ish). This is presented in an isomorphic fashion, so
the height is 32px at the leftmost and rightmost extents and 96 in the centre.
@@ -222,8 +220,9 @@ for instance.
Loading a constructed `palette.obj` containing 1x63 pixels, with 0x0000 for the
first 32 bits, caused WH40K_TD.exe to render the pixels far to the left and above
the cell the palette objects were being placed into. This suggests they
represent an x,y offset to draw to. Need to experiment more.
the cell the palette objects were being placed into. Menus have a `.obj` file
associated with them too, and the elements for `Main.mnu` draw in the correct
places if we treat it as such.
Considering sprites with a 1,1 x,y.