Kostya's Boring Codec World

Back in the day I’ve stumbled on a post called Archaic Video Compression Algorithms of FMV Games Era (in Russian) giving a concise review of VGA era video. For a long time I wanted to discuss it but I lost the link to it and managed to locate it just recently.

For those unable to read Russian here’s a gist of it: all the variety of those formats used just three methods to compress video, those methods being lossless redundancy removal via RLE or LZ77-based method (Huffman codes not employed), vector quantisation, and block truncation coding. Inter-frame compression was rather primitive, often without any motion predictions; fade-ins/outs were not handled either. And later, when computers became powerful enough, everybody switched to DCT coding and later to in-engine animation.

It is a very good first approximation but as a person who looked into several formats myself and even documented a couple of them, I have something to add or correct.

First of all, ‘archaic’ means something not merely old but also not in common use—and that does not apply neither to LZ77 (which is still the base of most of the practical compressors and archivers; and there’s WebP using its variant in lossless mode) nor vector quantisation (even if it’s mostly employed in texture compression nowadays).

Second, I consider block truncation coding to be a specialised form of vector quantisation for a case of two colours per block. And considering that the input data could be palettised already it’s more likely the encoder searched for the most fitting two colours in the palette instead of generating two RGB triplets and handing it all to the palettisation process.

Third, I’d argue that back in the day codecs did not need sub-pixel motion compensation and motion vectors were often not needed since you could simply code an offset in LZ77 compression. And some of the codecs allowed copying data from either already decoded parts of the current frame or some not yet touched part (or any part in some cases) of the previous frame. This archaic method of copying from already decoded part of the frame is present in AV1 for example (under IntraBC name).

Fourth, I think that recursive block division deserves to be mentioned there.

A minor nit would be that even if very few codecs supported explicit fading, a lot of them had support for palette change event (partial or full). Yet it mostly depended on people developing the format and the encoder for it how well it was handled.

So in my opinion the final list of the techniques most FMV games of the VGA period used should look like this:

• lossless data compression with RLE or LZ77-based method
• vector quantisation—both whole tiles and inside single tile;
• recursive block splitting (either horizontal/vertical or as a quadtree);
• and fullpel motion compensation usually done by skipping pixels, blocks, or reusing some already decoded region.

And typical video codec of that era should look like one of those two:

1. line-based codec employing RLE, probably with skips for inter-frames and optional LZ77 compressing of whole frame data afterwards (or extending LZ77 approach to work with the forward data in the buffer as well);
2. tile-based codec usually working with 4×4 tiles, employing vector quantisation to paint the tile with 1-8 colours, sometimes sub-dividing tile for better detail preservation, sometimes having a dictionary of tile configurations, sometimes even employing block-based motion compensation; those codecs usually employ 1-4 byte opcodes to code the tile type of whole sequences of tiles of the same type.

Of course there are deviations from those two schemes but the majority of game codecs of that era should follow either of those two designs.

Later, as the original article said, those codecs were supplanted by DCT-based ones (I’ve seen the ones based on MJPEG and MPEG-1/2; and there’s hybrid Bink). On the other hand, DCT-based Bink2 is still in use.

Overall, if you look at game formats section in the wiki you’ll see a lot of various formats and many of them are built on a handful of the idea described above while still being quite different from each other. Originality lies not only in the methods employed but also in how you combine them together. And the modern codecs are the example of how different organisations build essentially the same codec using slightly different methods. MPEG-5 LCEVC was a nice change though.

Since I had nothing better to do, I decided to re-play some old adventure games and one of them was King’s Quest VII (I don’t know why it gets Roberta Williams name attached to it, she’s behind all previous KQ games as well, it’s Mask of Eternity and the 2015-2016 re-imagining that deserve Not Roberta Williams game title). And in my usual habit I also looked at intro/ending animations. As you all remember, there are DOS, Mac and Windows releases of the game and each of them uses its own format. Windows version uses 10-fps MS Video 1 in AVI, Mac version uses 8-fps Cinepak in MOV (with data in a separate resource fork as expected from Mac video), DOS version turned out to use 5-fps RBT. Thanks to Mike Melanson documenting it in the course of his experiment, I was able to write a quick and dirty program to unpack .rbt files (essentially it’s just raw frames compressed with LZStac so if you don’t care about handling errors or less common cases then 3.5kB program in C is enough).

And while doing that I remembered that animating of this game was partly done in-house but most of the work was outsourced to the various animation studios including the infamous Animation Magic. In case you forgot that is a studio with Russian origins that was mostly known for their unforgettable animation of CD-i games. Yes, those CD-i games. To their defence it mostly came from them being inexperienced with the computer animation and slowly the animations in their games became better at the expense of them becoming less memorable (animated fairy tales books are interesting only when Dingo Pictures does them!). But between MAH BOI games that are refusing to be forgotten and rather obscure Magic Tales series there were two edutainment first-person shooters, namely I.M. Meen and Chill Manor, that are still somewhat remembered by their wildly imaginative cutscenes. Of course somebody had to look at the format.

It turned out to be a custom format with intra-only RLE-packed video with the only interesting things about it being the use of up to 128 colours only, the fact it should be drawn over some external background (even the intro or ending), and that it uses run length 0 as “fill until the end of current line” mode. Audio is raw PCM, so nothing remarkable there.

For the comparison here’s the captured image from the intro playback (stolen from Mike’s review of the game):

and a decoded frame from intro.ani (not the same one but close enough):

You can find the missing background among the game files in PCX format though.

This is a bit crazy format but it was fun looking at it.

For the lack of anything better to do I took a second look at Shannara game from Legend Entertainment (yes, I was that bored). And while it failed to captivate me once again, at least I have discovered yet another video format.

Actually I like old adventure games of theirs, especially the fact that they use RealSound technology (even if it’s just a way to play PCM on PC Speaker). But Shannara is a hybrid game with all the map travelling and fighting monsters. And I could not get into Terry Brooks’s books either, the first Shannara book reminded me of Lord of the Rings but in post-apocalyptic setting with magic appearing for some reason so I dropped it halfway.

In either case, the game featured full-motion animations and of course I had to look at them. As one would expect, all of them could be found in FLICS subdirectory and some of them even were in FLIC format. The rest were sporting rather rare .q extension and I doubted those were Quantum archives. After looking closer it turned out to be quite interesting format.

Video is compressed by splitting frame into 4×4 blocks, usually coding those blocks either as a block filled with two colours using a pattern or by copying some previous block (it does not try to motion search up to a pixel precision but it can reuse any block from a frame). There is an additional coding mode for coding either raw 4×4 block or block filled with 3-8 colours in a pattern. And additionally 128 of the most commonly used patterns for a group of frames are transmitted in a separate chunk before those frames, in result you can use just one byte to code that index instead of two bytes for a full pattern.

Even if I haven’t managed to figure out all details from it and there may be other flavours of it in other games, it was a surprisingly original format and it was fun looking at it.

Last time I forgot to mention another obscure Russian adventure game called either Adventure History or Sin(d)bad’s Eighth Adventure which has quite interesting selection of video in its resources.

So it has some game sprites in FLIC format (most of the sprites are in its own custom format), half of the game size is occupied by clips from Soviet movie (the one featuring the same hero) in AVI with MJPEG format, and finally logo and ending are in the custom HSA format.

HSA is video-only format that is very simple: 32 bits – video width, 32 bits – video height, then you have video frames data prefixed with 32-bit size (0 means end of file) and followed by 768 bytes of VGA palette. And yes, each video frame has palette following it. And of course each frame is compressed independently (using unmodified classic LZSS.C).

At least that’s more variety than you usually get in the games.

Today I’d like to sum up my experience looking at various game video formats, none really finished or worth documenting. In case you wonder I’ve not played (or plan to play) either of these games, I just found a place with some adventure games and looked at them for anything not known to me (and below is what’s left after discarding games using Cinepak, Smacker or Truemotion).

First of all, SIFF format used by Beam Software. It turns out that in their game The Dame Was Loaded has various resources in this container format but even larger ones look more like special game resources than videos (think about .RBT vs .VMD in SCI32 games). But there’s Alien Earth with a newer video compression and audio—both 16-bit now. Since I was unable to find the code that plays it, I’ve found the details by studying the files. The compression seems to remain largely the same except that pixels are 16-bit, pattern coding has changed (and the patterns are coded in the binary) and old “palette present” flag is reused to signal that fill values take one byte instead of two (for black values it’s enough).

Now let’s look at various Cyberflix games like Dust: A Tale of the Wired West or Titanic: Adventure out of Time. From what I could find the .mov files found there are similar in the structure with other kinds of resource files. And even if the game explicitly demands 256-colour video mode I could not see anything resembling a palette inside those files. My conclusion is that they’re not real video files either but rather some game scripts and graphics.

And let’s end it with The Vampire Diaries. This is another game with video files without palette. It seems to store just video frames either uncompressed or compressed with LZSS scheme. It’s not interesting enough to dig further.

I guess this is it and I should finally return to writing proper NihAV video player.

Since I still have nothing better to do I keep looking at various formats in adventure games. And it turned out Prisoner of Ice has cutscenes in MUX format (that’s a stupid name in my opinion but what you can do now). IIRC there’s a newer version of Time Game that uses Smacker, maybe this game got a new release too but my interest was not in playing cutscenes but rather see how they’re packed. And the scheme turned out to be rather interesting.

Originally The Wiki said about it that it’s similar to HNM version 1 from Cryo (subtype 173 after investigating more thoroughly) and that’s all. As it turned out the ideas are very similar but the implementation details are sufficiently different (were they all inspired by the same book or code?).

So it turned out you have a format with 8-bit PCM audio and video that optionally employs simple LZ77-based scheme and small-codebook RLE. The main problem during REing was the way the code was written: where it reads nibbles it conditionally jumps into the middle of NOP instruction (that does a different thing then, isn’t x86 fun?); in other place you have self-modifying code, functions modifying three or four registers for return value and opcode tables. Still after figuring out some of those I’ve managed to decode all cutscenes from Prisoner of Ice, Time Gate and half of those from Chaos Control. The rest of the files in that game use a completely different method that I’ve not seen elsewhere.

Overall, this was still an interesting experience.

Since I don’t like my work to go completely to waste I decided to document the formats on a separate page in this blog.

I’m not sure these formats are that fitting to be documented in The Wiki since they’re in an archive and not standalone. But since I’m too lazy to find a proper wiki for game formats and register there I dumped it here instead.

In my last post I said something about video compression but now I have much clearer picture in my head so I’d better document it a bit.

So it turns out bitmaps and videos share the same compression methods (just 1 and 3, 0 and 5 are video-only) and they’re even more interesting than at the first glance.

• Compression 0 is simple stream with 8- or 16-bit opcodes with follow-up pixel data. Top two bits mean operation – skip, error, copy, repeat; next bit signals whether actual operation length is 5 or 13 bits; next bits are obviously operation size.
• Compression 1 is tiling compression. Frame data is split into three chunks with first two starting with chunk size. First chunk is bit flags telling which 40×40 tiles in the frame are updated (this chunk can be ignored). Second chunk contains its own tile dimensions and tile metadata (one bit signals that tile is coded, 3 additional bits tell tile type). The last chunk contains tile contents in form of pixels and pattern data. Tile can be skipped, filled with single colour, filled with raw pixels, or it can be filled with 2-16 colours (with all intermediate values allowed) using 1-4 bits as index.
• Compression 3 is LZ77-like and works on two lines at once. It reads a code using static codebook (one for intra-frames, another one for inter-frames), for code 0 is for literal (reads and output two pixel values, one for each line), all other code values are treated as copy length which is followed by offset (and in case of inter frame also direction bit telling if data should be copied from start to end or from end to start).
• Compression 5 is virtually the same as compression 1 but tile type takes 4 bits now to fit operation 8 (copy tile from the same place in some previous frame).

Indeed, this game turned out to have very original formats.