I keep looking for old games with interesting animation formats and I’ve found another two, from Israeli companies this time.
First is the format used in Armed & Delirious. Since all of the files are in the custom archive (except for a single file with “please change CD” animation) I’m not going to support it, though I still documented it for posterity. Apparently it has two operating modes: updating some lines where each line can have its own coding mode (all are RLE variations) and updating tiles, now with each tile having its own coding mode. The only interesting thing is that tile coding operates on a sub-set of colours so it can use 3-6 bits for index. I remember some formats resorting to 16 colours and 4-bit indices but there are more variations here.
And then there’s VID format used in Soul Hunt and, apparently, some other games by the same company. It features DPCM-compressed audio and depending on version RLE- or JPEG-compressed images (and both versions are present in the game). That’s right, they use code (probably borrowed from libjpeg but I’m not sure about that) to decode data in JPEG-like format (8×8 blocks, IDCT and such) and then use some large lookup table to convert it from YUV to paletted RGB. Of course there are video codecs with such built-in functionality like Cinepak or Indeo 3 but it’s still surprising to see such thing in a random codec.
I wonder how much was time spent on coding actual games and how much on coding actual game formats used within game, like there is thousands of formats and their variations.
PS. wrote native zlib inflate decompression, gonna slowly replace all of old zlib with this new one.
Its funny how such old compression scheme (at least decoding) was never implemented in that project that should not be named again. (inflate is bellow 512 lines of code, and bunch of alternative implementations on web are unreadable with thousands lines of code..)
Well, it’s nowadays you have freely accessible game engines and documentation, back in the day information was more rare (and probably not everybody could afford e.g. Smacker, both financially and computationally) so people had to invent their own formats, tools and so on.
As for inflate, congratulations. Actually there was almost finished effort back in the day but its author abandoned it before some bugs could be weeded out and nobody picked it up.
Also for comparison, my inflate implementation is about a thousand lines but only because I wrote it in a very straightforward way and implemented it as state machine as well as “uncompress all” mode (so you can e.g. feed data by one byte and still decompress it in the end; one of my tests actually does that). Leaving just either of them would shrink it by 300 lines already.
I do not see point in “state machine” to suppor fake streamable processing.
The state machine make code more complex and probably slower.
So code just use full uncompressing of whole buffer just with custom stride/width/height support for output.
You’re right on that account, it was more of a theoretical exercise on my side. Being able to inflate data into a frame buffer with a stride differing from width*bpp sounds more useful for multimedia purposes too.