The Magic of Animation

May 1st, 2021

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.

Le spam

May 1st, 2021

Sometimes I look inside Baidu Mail spam folder to see if there’s anything useful got there by mistake (notifications from various shops with purchase confirmations end there quite often, to give one example). And there’s a weird tendency I’ve spotted recently.

In the last five days I’ve received 47 spam mails. 37 of them were in French. I’m used to receiving spam in various European languages (including but not limited to Bulgarian, German, Italian, Russian and Spanish) but before last year it was mostly in English. Additionally a good deal of them now is about some promotional actions from supermarket chains like Aldi, Carrefour or Lidl (and I’ve never considered either of them to be some luxury store).

What’s wrong with this world?

Looking at Q Format

April 24th, 2021

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.

Things I want in Ghidra

April 14th, 2021

Ghidra, as you should know already, is a disassembler and decompiler for unprofessional folks who can’t cough up a couple thousands dollars and pass background check to buy a disassembler and decompiler the experts use. And here’s a list of things that would make Ghidra better or much better for me. I know it’s opensource but I’d rather not touch large codebases written in Java (or any codebases written in Java really). Disclaimer: by the time of writing this I’m still using Ghidra 9.2 even if 9.2.2 has been available for months, but I doubt any of the things mentioned here are implemented already.

First of all, there’s a bug with x86 disassembly: while rep movsX is recognized and works fine, some of the code I’ve seen uses repne movsX which is treated as simple movsX even by disassembler. Initially I was confused by this bug and only disassembling instruction bytes with ndisasm proved that it’s not a compiler (or assembly author) missed a prefix but rather Ghidra ignoring it entirely. Some other rarely seen instructions that involve FPU operation and an addressing with segment registers (e.g. ES, FS or GS; if you don’t have an idea what those are for—be thankful for that) and explicit offsets are disassembled incorrectly, consuming a byte more than required (and thus making the following instruction to be disassembled incorrectly as well).

And speaking about assembly, current program text search is nice since you can search inside a specific part of an instruction (e.g. MOVSD.REP in instruction name or 0x800 in its operand) but it would be even better to have a more generic search by a regular expression. Quite often I want to locate a specific instruction doing e.g. shift left by five. The problem is that there are many shift instructions and even more instructions with an operand having 5 somewhere in it. And I don’t know the exact operand register so searching for shl eax, 5 first, then shl ebx, 5 and all the way to shl dh, 5 is tedious. The same can be said about dumping listing and searching there. It will work as intended though.

Beside the issues above and idiosyncratic x86 assembly syntax (it does not bother me much though) I have nothing else to complain in disassembler, so let’s move to the decompiler issues.

I suspect that decompiler output is not stored permanently, but it would be nice to mark some function as being “decompiled, it’s fine, do not touch it, I mean it”. Looks like the process of function being decompiled again and again even if you change something not related to it in any way is annoying not just to me. So it would be nice to mark some large decompiled function as permanently decompiled so it’s not re-decompiled on a subsequent visit to it.

And speaking of functions, it would be nice if functors (aka function pointers) would be supported instead of just detecting that this variable is a pointer to function. When arguments are passed by stack, decompiler usually can detect that. But when arguments are passed in registers you have to trace the registers and their values by hand. Of course you’d need a monstrous syntax to specify a type for e.g. a function that accepts three arguments in designated registers but I can still wish for it, can’t I?

Another thing I often wish for is being able to tell decompiler that after a certain point the variable is no longer valid and it should treat subsequent uses of that register or stack as a new variable. A very common example is when a first argument (usually some context pointer) is moved to a register (or it is passed in a register already), some fields are read from the context, context value is stored to some local variable and the initial register is used for example as a loop variable that gets decompiled to something monstrous like for (ctx = (Context*)0; ctx < (Context*)42; ctx = (Context*)((int)ctx + 1)) { ... } and it also screws types for variables involved in the same expression as this loop counter.

Of course not all of these things can be easily implemented, and maybe some of them would require architectural changes. But I prefer to cherish my ignorance on Ghidra internal details and just point out what I’d find good to have in principle.

I feel old

April 4th, 2021

Probably it’s exactly when you start complaining about things changing you realize you’ve become old. And as you can guess this is my turn to complain about things changing.

The last tipping point for me was when I tried to update rustc from version 1.33 I’d been using. I wanted to do it mostly for three things: atomic types beside bool and usize (for the use in NihAV video player that should be written eventually), replacing now deprecated mem::uninitialized(), and being able to switch to a newer version of SDL2 bindings for the future video player (because old version depends on about 25 crates more than a newer ones).

So I tried latest-and-greatest rustc 1.51 and ran cargo clippy to see what has changed meanwhile. And beside seeing that now there’s a special macro matches!() as a convenient shorthand for checking object type to be some variant(s) I could not see anything useful because the linter spammed everything with “selected name is bad, you should change NASomething into NaSomething“. Which looks ugly and dropping the NA prefix entirely may make names too generic and collide with the standard ones. And before you tell me: I’m aware of the lint suppressor flag and that there’s a fix for it that makes it not to complain on public names. Still, I find this brain-damaged and thus I’ve settled on rustc 1.46 for now.

Then there’s an even funnier thing. I’ve discovered that crates.io (the site for navigating Rust packages) has stopped working in Firefox 52 (docs.rs still works fine—for now). Probably because of some JavaScript new feature (which is invoked inside rather large bundle) the scripts cannot be parsed and it simply gives you a cryptic message “Sorry, it looks like we were not able to load the page.” without explaining much. The problem is most likely at your side, you find it out.

My friend Luca actually wasted some time to create an issue for that and got an obvious reply that the browser is outdated and this is expected. For the record GitHub at least prints a message that the browser version is too old and not supported (yet the main functionality is still working), the same is true for WordPress instance where I’m typing this post.

So why don’t I update this four-year old browser? Because it’s painful. The browser is tied to the Linux distribution so either I should compile it myself (I tried that once with earlier Firefox, ran out of disk space and almost of swap space too; so I’m not eager to compile any browser more complex than elinks). The other alternative is updating the distribution and that is even more painful because of the drastic changes in software.

I’m not talking about desktop environments per se even if they expose the problem. I don’t care much about how the windows look like or where launch menu is located. But I do care about the programs I used to being no longer the part of the distributive or changing their interface in radical way. Simple example: for various reasons I like to have several input layouts and methods (for English, Ukrainian, Russian and Japanese language). On Ubuntu 12.04 I have keyboard layout switching between English and Ukrainian layouts (the latter can also produce Russian or Belarussian letters with AltGr) plus mozc to input Japanese (previously it was Anthy and who knows what will be the default Japanese IME in 2024). On Ubuntu 18.04 (which I use on a different machine) you can’t set it up the same way, Ukrainian layout does not have AltGr support and mozc by default outputs Latin characters with no setting or key combination to make it output kana by default (of course I can simply press kana mode change key on my Japanese keyboard—but that means connecting an external keyboard just for that). And even if my fingers are the wurst I have sausage fingers hardly hitting a correct key on the first time, I still want to perform keyboard actions using keyboard.

The sad thing is that I somewhat understand why this happens. Web sites get bloated and do not work with older browsers because of the browser war (no plural, you know The Browser) and shiny features developers are eager to try (and testing for older versions takes time and efforts better spent elsewhere—if people remember about it at all). Some programs need to be updated because of security issues (e.g. I upgraded from Ubuntu 10.04 mainly because of TLS troubles leading to programs not being able to open half of the sites over HTTPS). Some programs get replaced because the maintainer left and there’s nobody to step in. Some interfaces need to be adapted to the new reality (while Debian on Nokia smartphones is not so popular now, Ubuntu on tablets seems to be the next popular thing). And there’s GNOME and freedesktop.org which seem to be the main sources of disruptions. I can’t explain the logic by which they change things but it’s because of their view the mountpoint for network shares in the next release will probably be different from two previous places (and when you’re still using command line to access files on those shares like I do this feels annoying).

The sad thing is that all other non-toy OSes have the same problems. Windows users might still remember Windows Vista GUI affectionately and like how Windows 10 changes GUI elements time from time. *BSD seems to be more stable but they still support GNOME. macOS users might be still ashamed for their muscle memory failing them when OS update decided to reverse scroll direction. This is also why Linux kernel is still precious: it still cares about its interfaces being backward compatible so the userspace can rely on them while you can’t say the same about glibc 2.16.

And here we have it. As I said in the beginning this whining about programs and environments changing constantly mostly tells that I’ve become old. On the other hand if you think this “move fast and break things” motto is a good idea—remember who coined it and think again.

And another one weird game

March 25th, 2021

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.

A brief look at various game video formats

March 24th, 2021

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.

A quick look on movies for handhelds

March 21st, 2021

In not-exactly-recent news there was a piece about some guy who decided not to listen to the advice of a director of some blockbuster and instead of going to cinema to watch it he encoded it to watch on Game Boy cartridges instead. While people doing stupid things is hardly news, it sparked a mild interest in me so I looked what are the options on underpowered hardware for storing video.

It turned out there are at least three formats for coding not just cutscenes but whole movies (or at least episodes of various series) to fit into 32MB GBA cartridge. And those three formats seem to be built on vector quantisation and they all embed video into the player program (well, the cartridge in this case does not have segments or filesystem for different resources).

  • GBA Video is probably the most famous and the most official one (there were official releases of couple dozens animated movies and cartoon series that used the format). It’s been developed by Majesco and it seems to use vector quantisation and deflate and since it checks codebook size to be 256*6, it’s most likely to be something like Cinepak using 2×2 YUV 420 codebook entries for compression. Additionally it seems to use left prediction (i.e. code pixel as a difference to the left one);
  • Caiman video codec seemed to come in two flavours, the original one coding 8×8 blocks using either four 4×4 pixel codebooks or just one scaled (that reminds me of Cinepak again for some reason, maybe because it did the same albeit using 2×2 vectors), next version of the codec introduced codebooks of different sizes and 8×8 block could be split recursively for that (also that version got motion compensation);
  • METEO is some Japanese format that seems to be the choice for the GBA enthusiasts since there’s a free encoder for it. I actually looked into it to see what it does (it’s a standalone binary about two hundred kilobytes large) and it turns out to decode input videos using standard Windows interfaces and encode frames with Cinepak encoder and write them into their own container.

All these formats make me think that if I look at other gaming consoles I can find Cinepak there as well. Let’s look what those FMV games used

Curiosity satisfied, I should move to something else.

Looking at Infogrames video format

March 20th, 2021

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.

This method 8 (I called it that because it’s signalled by frame flags defining compression method are set to 8 in this case) uses RLE over several line with opcodes by adding several pixels at the end of decoded part of some image row and some rows below. You can imagine it as each row being a piece of string or wire and commands are like “take box with red beads, put three of them on this row, two of them on next row and one of them on the following row” and you repeat that until all rows are filled. Since this method has too confusing implementation and I don’t care much about it to figure out exact details, feel free to document it yourself.

Overall, this was still an interesting experience.

Final words about Escape from Haunted House formats

March 17th, 2021

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.