Posted: Tue Oct 28, 2014 11:18 am Post subject:
Voxel File Format Research
While spending time mapping out more of the TS engine, I started to map out the area of the game's code where the Voxels are processed etc.
When mapping out how the Voxel files are loaded, using 'http://xhp.xwis.net/documents/VXL_Format.txt' as a base, I noticed there is two unknown variables in the file header...
Code:
struct vxl_header
{
char filetype[16]; /* ASCIIZ string - "Voxel Animation" */
long unknown; /* Always 1 - number of animation frames? */
long n_limbs; /* Number of limb headers/bodies/tailers */
long n_limbs2; /* Always the same as n_limbs */
long bodysize; /* Total size in bytes of all limb bodies */
short int unknown2; /* Always 0x1f10 - ID or end of header code? */
char palette[256][3]; /* 256 colour palette for the voxel in RGB format */
};
The point of interest is the first "unknown" variable, it is a DWORD Boolean. It is actually the boolean flag for handling the internal palette. When set to false/0 or true/1, it allows reading of the Palette section that is located at the tail of the header from what I read. I'm not 100% sure what option represents what yet and if the game uses the internal palette of the Voxel file or the VPL yet.
I can not find any reference to the second "unknown2" variable.
Just thought I would share this, hopefully this could spark another Voxel discovery... QUICK_EDIT
unknown2 and palette do not belong to the header. unknown is the number of palettes included, which follow the header directly. Each palette is 770 bytes long, 256 colors with 3 byte components equalling 768 bytes, and two bytes other data preceeding the colors. This is what unknown2 is, consisting of 2 separate bytes.
Thus, unknown is not guaranteed to be always 1. Which means that you can't assume the header is this big at all: a header with 0 palettes is just 32 bytes long. Only one palette is read at most though, and the others are just skipped.
The two bytes of unknown2 are indexes, the second has to be equal to or larger than the first, and they define a range of colors that are treated specially. The first index is the start index, the second index is the end index (both are inclusive). I can't tell what that special treatment is for, though. _________________ QUICK_EDIT
The two bytes of unknown2 are indexes, the second has to be equal to or larger than the first, and they define a range of colors that are treated specially. The first index is the start index, the second index is the end index (both are inclusive). I can't tell what that special treatment is for, though.
Could this be the same as the VPL header? RemapStart and RemapEnd? QUICK_EDIT
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Tue Oct 28, 2014 8:24 pm Post subject:
Very interesting what I'm reading so far. So, I can include countless palettes in a voxel file. How would the game determine which palette would be used by which section? QUICK_EDIT
CCHyper: Even without knowing what code exactly you are referring to, I think yes. The code looks a bit different. The VPL header is 16 bytes long, and starts with two DWORDS. Voxel palettes have two bytes, but they are extended to DWORDS and put into the same kind of struct, at the correct offsets. I guess that means yes. I can see that in YR there's a function from which I think it's the destructor that is used for both VPL and voxel reading; that's why I think it's the same struct.
Banshee: You can include several palettes, but I don't see them used and not even read. If there is 1 palette, the game reads one, if there are more, the game reads one and skips over the others. The game handles many palettes gracefully, but I don't think you can use them, though i haven't checked whether some other code reads the pals.
Some more findings and clarifications:
I think there has to be at least one palette, and 0 or less are no valid values for the field unknown or PaletteCount. The game can optionally disable using the palette in the file (by a function parameter), in which case PaletteCount * 770 bytes are skipped (the two index bytes and the palette itself). If there would be 0 palettes, the game would skip 0 bytes correctly, but if palettes are allowed it would still read one palette.
Also, if palettes are allowed and there is more than one palette, the game does not skip reading (PaletteCount - 1) * 770 bytes, but (PaletteCount - 1) * 768, which is the size of the raw palette data. Thus i guess the palettes share a common header, the two bytes. A weird inconsistency. Either I'm missing a piece or there are two incompatible voxel formats, and depending on what parameters are passed to the reading function, one or the other becomes invalid with the game. The only value for which both work is for a PaletteCount value of 1. Maybe this is a bug, and they intended to skip 770. I get a headache from this...
The game can optionall allow to load palettes as I mentioned. YR calls this function in 13 places, like loading BuildingType art, or VoxelAnimations, to other object. None allows to load palettes (each passing a hardcoded constant), thus half of the problem goes away: PaletteCount * 770 bytes are skipped. Still not clear whether that's correct opposed to 2 + PaletteCount * 768.
Note: All these finding are from YR 1.001. _________________ QUICK_EDIT
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Wed Oct 29, 2014 5:01 pm Post subject:
Unknown2 in VXLSE III are the indexes of from the first remappable colours and the last one. So, it's usually 0x101F (10 being 16, the first remap and 1F being 31 the last one). QUICK_EDIT
This internal palette can be used to display the voxel in the game? I replaced it with a fully black, and did not notice the difference (voxel still colored) QUICK_EDIT
Is there any use for the Remap Colour Index's or can they safely be saved as 0x101F each time? _________________ Free Map Editor - Game Requirements - Stucuk.Net QUICK_EDIT
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum