Looking at AVX format

Since I had been looking at video files in various games I’ve decided to look at AVX format in Jack Orlando, a Polish adventure game.

The format is not very complicated but somewhat WTFy. It combines audio track compressed with IMA ADPCM and RLE-compressed video. The format is organised into chunks (audio, video, palette update). Sound easy enough?

Well, here are WTFy bits:

  • audio violates chunking structure: file starts with 32-bit word to signal this is video file, then you always have ~110kB of audio data (that starts with its own header) and only then you have video header and chunks;
  • speaking of which, video frames are packed together with audio chunks so after reading/decoding one you have audio data without the usual chunk header (you can have standalone audio chunk of course);
  • oh, and another thing—the video file header seems to list number of audio frames (which is usually several times larger than the number of video frames);
  • another fun fact about video header: it may occur several times throughout the file;
  • and another fun fact: while the format is paletted, palette can be either 24-bit (I’ve seen that only in intro) or 16-bit (all other files, which are predominantly short game over animations). And by 16-bit palette I mean 256-colour palette with actual colours represented in RGB565, I’ve never seen that before;
  • as a cherry on top of that sometimes chunks start earlier or later than you’d expect from declared size.

And if you thought video compression would be sane, think again:

  • actual data is compressed in two passes: first it groups data into coded segments in the form (1 byte - number of skipped pixels, 1 byte - number of coded pixels, 0-254 bytes - actual pixels) and then all that data is RLE coded (0xFF – escape flag after which run value and run count bytes follow, otherwise byte value should be copied as is);
  • since this is too easy it also uses pixel value 0 as skip value;
  • plus there’s a global offset in the beginning of the chunk telling from which pixel to start decoding;
  • plus there are two video chunk types that seem to differ only in one header field being missing in one of them;
  • and the actual video is 640×480 but it is coded as 1024×480 with right part of the frame being blank.

Some game formats are interesting but this one borders with being unbearably interesting.

4 Responses to “Looking at AVX format”

  1. Paul says:

    Obscure games with even more obscure formats!

  2. Kostya says:

    s/even more/equally/

    There’s a term “one-hit wonder” originally used for music bands known for just one song but it also applies to the games since there are many cases when some studio made a single game and sometimes those games use video format designed specifically for that game.

    Even if it’s usually RLE/LZ77/VQ/quadtree, sometimes you get something more interesting.

  3. Paul says:

    I still can’t get VMIX decoder DC decoding correct, I feel rusty.

  4. Kostya says:

    Change activity then and return to it later with clear head and maybe analyse that piece of code from scratch. That helped me in the past (not always though).