Another annoying game video format

Since I had nothing better to do and remembered about one mostly finished format, I decided to add its support to na_game_tool. The game in question is called either Cydonia: Mars – The First Manned Mission or Lightbringer (with two variations of sub-title).

The main problem is that there may be different audio and video formats inside but you cannot easily detect them. The header contains only the dimensions (which can be any as long at it’s 640×320 as the game uses hard-coded dimensions in the decoder), number of video frames (also rather pointless as it does not really affect anything) and audio present flag (the only useful information there).

First annoyance is audio format detection. The simplest solution I could devise is looking at the first audio block size and depending on its size setting the format (22050 bytes means 11kHz mono, 44100 bytes are for 22kHz mono and 88200 bytes are for 22kHz stereo). As long as you don’t encounter those extra-short files with a single audio block of different size you should be fine.

Then, video. Game demo (and maybe some versions of the full game) uses paletted video while the full game (at least the version I could find) uses 16-bit video instead. So if you discover palette chunk before video it must be a paletted format. At least the compression schemes remain the same.

And what do you know, video compression is also annoying. Both compression methods employ LZ77-based algorithm with some variations. Method 3 always decodes 640*320 bytes (or twice as much for 16-bit video) and employs an additional code for leaving data unchanged from the previous frame. Method 2 uses the same coding method (minus the “keep previous data” code) to code inter frame data of variable length (without an end code apparently). Essentially if the next 24-bit code is a valid offset (which is coded as x+y*632) then copy a block from the previous frame at the given position, otherwise decode block data (64 or 128 bytes depending on bit-depth). As I mentioned before, you don’t know compressed data size beforehand and you don’t have end-of-stream marker so you have to decode the needed amount of data as you paint the frame.

Overall, this is rather interesting video compression scheme but Paco also serves as an example of how not to design a container format. This reminds me of RoQ hack where the game engine used slightly different decoding mode if the filename was in a special list. And Nova Logic KDV but there it were different flavours in different games at least.

3 Responses to “Another annoying game video format”

  1. Paul says:

    NHW Project – a free state-of-the-art image/video compression codec

    This one is still strong and alive.
    Once I was annoyed and frustrated by 512×512 resolution limitation, but maybe developer can’t work on higher resolutions because developer can not buy better monitor.

    Now I just over-watch observe and do not interact, with this one and will do same with other, similar stuff. With no interaction things become better or worse, but you stay above it in both cases.

  2. Kostya says:

    @Paul – IIRC the project author explains (occasionally, between the point releases that tweak some stuff) that he optimised the kernel for 512×512 case so even if it’s trivial to extend wavelet coding to other dimensions it won’t work that well. And he has no time to stop and think how to re-work it into something better as he keeps producing those new versions with tweaked weights. At least it has good chances to outlive either of our projects.

    @Peter – wow, that’s really kanged. I recognized that bit of code for example – https://github.com/cherryding1/RDA8955_W17.44_IDH/blob/master/soft/platform/system/mdi/alg/h264_dec/src/h264pred.c#L667

Leave a Reply