Either that, or this is just a convenient or otherwise advantageous way of storing them. I do admit I don't see a reason not to use PNG though 
This might not mean much to you, but I'll just put this here anyway. If not for anyone else, then for myself. Numbers preceded by "0x" are in hexadecimal and all values are little-endian unless stated otherwise.
Here's what I've figured out so far, from res_splash.bar. The image header contains info on how the images should be arranged, there are two in this particular file. These both start with 0xDF0539250100, as read in big-endian (0x0001253905DF in little-endian). After that comes a 16-bit unsigned integer, which designates the length of the following array (let's call it "arrayLength").
Now comes an array of "chunks", each chunk containing the coordinates and dimensions of a part of the image. The structure of each chunk goes like this:
1 byte - always 0x00, haven't seen anything else. Looks like some sort of separator.
16-bit unsigned integer - X coordinate
16-bit unsigned integer - Y coordinate
16-bit unsigned integer - width in pixels
16-bit unsigned integer - height in pixels
So there are [arrayLength] of these chunks. The X and Y coordinates are relative to the top-left of the image part.
After that come a bunch of bytes, whose meaning I have yet to discover. I don't know how to figure out the length either, however I can tell where it ends by finding the first part of the pixel data. In this file I can find that easily since the first colour in the pixel data should match the colour of the top-left pixel in the images I pieced together in my last post.
This pixel data is stored in 32-bit big-endian ARGB format (so that'd be BGRA when reading in little-endian). These are just like most image formats, you simply draw the pixels from left to right, row by row. You do this for each chunk, in the order the chunks are.
Again I'm not sure yet how to find out the length. I could probably multiply the dimensions for all the chunks, add them together, and multiply by 4, but there's probably a better way.
So yeah, that's what I've got so far. Theoretically it's already enough to get the images, but it really would be much better if I could figure out those bytes between the chunk array and pixel data. The first 5 bytes also look different in other files (e.g. res_chinatown_sprites.bar has 0xDF0531250100 instead of 0xDF0539250100) so that might have some significance as well.
I'm really glad how well this is going though!
This might not mean much to you, but I'll just put this here anyway. If not for anyone else, then for myself. Numbers preceded by "0x" are in hexadecimal and all values are little-endian unless stated otherwise.
Here's what I've figured out so far, from res_splash.bar. The image header contains info on how the images should be arranged, there are two in this particular file. These both start with 0xDF0539250100, as read in big-endian (0x0001253905DF in little-endian). After that comes a 16-bit unsigned integer, which designates the length of the following array (let's call it "arrayLength").
Now comes an array of "chunks", each chunk containing the coordinates and dimensions of a part of the image. The structure of each chunk goes like this:
1 byte - always 0x00, haven't seen anything else. Looks like some sort of separator.
16-bit unsigned integer - X coordinate
16-bit unsigned integer - Y coordinate
16-bit unsigned integer - width in pixels
16-bit unsigned integer - height in pixels
So there are [arrayLength] of these chunks. The X and Y coordinates are relative to the top-left of the image part.
After that come a bunch of bytes, whose meaning I have yet to discover. I don't know how to figure out the length either, however I can tell where it ends by finding the first part of the pixel data. In this file I can find that easily since the first colour in the pixel data should match the colour of the top-left pixel in the images I pieced together in my last post.
This pixel data is stored in 32-bit big-endian ARGB format (so that'd be BGRA when reading in little-endian). These are just like most image formats, you simply draw the pixels from left to right, row by row. You do this for each chunk, in the order the chunks are.
Again I'm not sure yet how to find out the length. I could probably multiply the dimensions for all the chunks, add them together, and multiply by 4, but there's probably a better way.
So yeah, that's what I've got so far. Theoretically it's already enough to get the images, but it really would be much better if I could figure out those bytes between the chunk array and pixel data. The first 5 bytes also look different in other files (e.g. res_chinatown_sprites.bar has 0xDF0531250100 instead of 0xDF0539250100) so that might have some significance as well.
I'm really glad how well this is going though!