FUCK YEAH C1 PIX DATA
If you'd like to be able to create textures for C1 with custom sizes (284*24, 12*68, etc).
Then what I decrypted this night might interest you!
it works : I've been able to make a texture with custom dimensions following my findings.
It is similar to Dan's work with decrypting C2 formats, it helped a bit by the way!
BIN DATA from C1 PIX PACKS
(all the values written in here are always hex values mmmkay?)
Header :
Pix packs always start with this :
0000 0012 0000 0008 0000 0002 0000 0002 0000 00
Note the lonely byte at the end.
This hex string never changes apparently and appears only once in each PIX pack.
Then the pix slots follow. A pix slot always start with : 03 0000 0017.
I have already noted that the last byte here varies to 18 or 16,
I have no idea what it means so far.
Then you've got 1 byte to define the image type, it is 03 (=8bits), always,
in C2 it can also be 05 (=16bits) or 12h (=16bit+transluency).
Follow the size dimensions, occupying 6 bytes :
2 unknown ones which seem to be the replica of the width.
2 bytes for the width thus.
2 bytes for the height!
And yet 4 more bytes which are respectively the half of
the width (2 bytes) and the height (2 bytes).
So here's what it looks like so far for example :
03 0000 0017 03 0020 0020 0020 0010 0010
That gives 4E414D452E504958 in hex, its length doesn't seem to matter (I've seen
names longer that 8.3, but I'd say : let's try to stick with the 8.3 format!).
Add four null bytes after the name string.
This is the time for the pixel data!
Let's have a look at an example :
21 0000040 8 00000400 000000 01
Those three 0 are weird I know but that's the only structure it seems to rely on.
The ratio is the hex value of this formula result : [(width/2)*(height/2)]/4
Then a lonely 8. Then three 0 again. Then the ratio again. Then seven 0. Then 01.
Now the actual image data. Between the 8bit BMP format and the PIX format, the
image orientation varies a bit, there's like 2 mirroring or 1 mirror+90°.
It doesn't matter much, I suggest that if you want a customized size for your
texture, create a totally red (for example, just to help you find the start and
the end of the image data) image with the correct size, and then paste the image
data block from the BMP into the PIX file. You can use Carmagedit to import your
texture properly afterward.
Follows now a part with 11 null bytes.
And then you can start another pix slot again with 03 0000 0017...
The very end of the pix pack ends with some null bytes as well. Their number seems
quite random so far, I often see 23 or 8 null bytes. Maybe it doesn't matter.
Another note is that, from what it looks right now, dimensions of a texture shouldn't
be non-even uh?! Well actually they can be odd, or at least one of them.
The half of the non-even dimension is reduced to the next inferior integer.
Example : if the dimension is 185, the half is supposed to be 92.5, but it will be
written as 92 in hex (5Ch). After that, in the head of the pixel data part, where the
ratio is calculated, as the ratio is again not an integer, the first ratio is set on
the next HIGHER integer (in this case 93 (5Dh)) and the second ratio is set on the
next INFERIOR integer (in this case 92). But the lonely 8 moves after the second ratio
while in "normal" formats, it stays after the first.
Well that's all.
Good night.
Toshiba.
(all the values written in here are always hex values mmmkay?)
Header :
Pix packs always start with this :
0000 0012 0000 0008 0000 0002 0000 0002 0000 00
Note the lonely byte at the end.
This hex string never changes apparently and appears only once in each PIX pack.
Then the pix slots follow. A pix slot always start with : 03 0000 0017.
I have already noted that the last byte here varies to 18 or 16,
I have no idea what it means so far.
Then you've got 1 byte to define the image type, it is 03 (=8bits), always,
in C2 it can also be 05 (=16bits) or 12h (=16bit+transluency).
Follow the size dimensions, occupying 6 bytes :
2 unknown ones which seem to be the replica of the width.
2 bytes for the width thus.
2 bytes for the height!
And yet 4 more bytes which are respectively the half of
the width (2 bytes) and the height (2 bytes).
So here's what it looks like so far for example :
03 0000 0017 03 0020 0020 0020 0010 0010
03 0000 0017 03 0020 0020 0020 0010 0010Now it is directly the pix's name, let's take here NAME.PIX.
[pix header][im. type][width][width][height][width/2][height/2]
That gives 4E414D452E504958 in hex, its length doesn't seem to matter (I've seen
names longer that 8.3, but I'd say : let's try to stick with the 8.3 format!).
Add four null bytes after the name string.
This is the time for the pixel data!
Let's have a look at an example :
21 0000040 8 00000400 000000 01
21 000 0040 8 000 0040 0000000 01The 21h value is a flag which indicates the pixel data part.
[flag][1,5 null byte][ratio][8bits][1,5 null byte][ratio][3,5 null bytes][01]
Those three 0 are weird I know but that's the only structure it seems to rely on.
The ratio is the hex value of this formula result : [(width/2)*(height/2)]/4
Then a lonely 8. Then three 0 again. Then the ratio again. Then seven 0. Then 01.
Now the actual image data. Between the 8bit BMP format and the PIX format, the
image orientation varies a bit, there's like 2 mirroring or 1 mirror+90°.
It doesn't matter much, I suggest that if you want a customized size for your
texture, create a totally red (for example, just to help you find the start and
the end of the image data) image with the correct size, and then paste the image
data block from the BMP into the PIX file. You can use Carmagedit to import your
texture properly afterward.
Follows now a part with 11 null bytes.
And then you can start another pix slot again with 03 0000 0017...
The very end of the pix pack ends with some null bytes as well. Their number seems
quite random so far, I often see 23 or 8 null bytes. Maybe it doesn't matter.
Another note is that, from what it looks right now, dimensions of a texture shouldn't
be non-even uh?! Well actually they can be odd, or at least one of them.
The half of the non-even dimension is reduced to the next inferior integer.
Example : if the dimension is 185, the half is supposed to be 92.5, but it will be
written as 92 in hex (5Ch). After that, in the head of the pixel data part, where the
ratio is calculated, as the ratio is again not an integer, the first ratio is set on
the next HIGHER integer (in this case 93 (5Dh)) and the second ratio is set on the
next INFERIOR integer (in this case 92). But the lonely 8 moves after the second ratio
while in "normal" formats, it stays after the first.
Well that's all.
Good night.
Toshiba.