Content for everyone
Imagination Pilots Transparent AVI Driver (Codec)
IPMA (Imagination Pilots Matte) and IP20 (Imagination Pilots Matte Ver 2) are video codecs Imagination Pilots used for transparent AVI files in their games.
News 16 January 2022: The codec has finally been reverse-engineered, and the exact compression was determined!
Download (Decoders only)
With this package you can install the video codecs manually, so you can watch the videos without the game being installed. To install, right click Install.inf and choose "Install".
Attention: This driver is 16-bit only, so it will only work on 16- or 32-bit Windows versions. 64 Bit is not supported.
Help wanted! Who can create a Windows 32/64 bit codec together with me?
Frame extractor tool for Windows
This tool extracts frames from an IPMA/IP20 AVI file and saves them as Bitmap files.
ipma_frame_extractor.exe -o outputdir -i avifile
Used in games
Each frame is encoded using the same LZW implementation as the GIF graphics file standard (except that the stream of LZW data is not partitioned into blocks, instead the stream is continuous). So, the developers re-used the code they have used for the ART files in order to create the AVI codec. (It uses dynamic index size from 9 to 12 bits, code 256 means decoder reset and code 257 means end of stream, 258 is the first code).
A frame can be empty (0 byte data), which means that the previous frame should be repeated. Or in other words, the empty frame is a fully transparent frame.
Each frame is "bottom-up", like a headless 256 color bitmap file.
Each pixel is 1 uncompressed byte long and is a reference to the 256 color bitmap palette of the AVI file.
The first frame is the background and will stay in the background for the whole length of the video.
The color #0 in the 256-color-palette means "transparent" and will result in the pixel of the previous frame(s), or the background.
The color #1 in the 256-color-palette has the special meaning "erase" and will reveal the background (frame #0).
The typical AVI file contains the background (e.g. a room) in frame #0 and the person (usually on a green-screen; but the color is not relevant) on the other frames.
It is unknown what happens if the colors #0 or #1 exist in the background frame #0.
In this example you can see a few uncompressed frames of LB05M03.AVI (the images have been flipped vertically):
Used in games
The same compression like IPMA
Like IPMA, each frame is "bottom-up", like a headless 256 color bitmap file, and each pixel is 1 uncompressed byte long and is a reference to the 256 color bitmap palette of the AVI file.
Unlike IPMA, the first frame is NOT interpreted as background. Instead, the whole video is pure transparent. (You can see the difference between IPMA and IP20 by changing the FourCC code of an AVI file using an hex editor and see the result.)
The color #0 has the special meaning "transparent" and will reveal the pixels of the previous frame(s), or the background.
The color #1 in the 256-color-palette has the special meaning "erase" and will reveal the background.
SUGR (Not a video codec handler FourCC!)
I first became aware of a possible third FOURCC code by the page wiki.multimedia.cx.
In the disassembly of IPMA.DRV and IP20.DRV you can see that beside the check of "IPMA" and "IP20", there is a check for "SUGR".
Disassembly shows that the game (e.g. BLOWNAWY.EXE) opens the codec transmits "SUGR" in the ICM_SETSTATE configuration data block:
Here is what happens: Among other things, the identifier "SUGR" is put in a struct (called configuration data block),
and then the memory address of that struct is passed as arg0 into the function
According to MSDN,
TODO: Find out the structure of this configuration data block! Note that in "Blown Away" the configuration data block size is 22h, while in "Panic in the Park" and "Where's Waldo? At the Circus" it is 3Ah.
Another open question: Since the game only sends "SUGR" configuration data blocks in the ICM_SETSTATE messages, why does the codec then check for "IPMA", too? Theory: Could it be the case that "something" sends a "IPMA" configuration data block when it plays the animation, and if the game plays the animation, then a "SUGR" configuration data block is sent? My first idea was the the Operating System sends a "IPMA" configuration data block (but where would that be documented?) when the animation is played with Media Player. However, this does not seem to be true, because I modified IPMA.DRV so that it crashes (Division by 0) if the "IPMA" code branch is executed. But the animation still worked in the game and Media Player... The other theory (which is not so exciting) is that the "IPMA" configuration data block is a feature which is not used by the final version of the game (either it was a feature that was removed, or it is feature that was never used in the first place).
If "SUGR" gets changed to something else, then the IPMA graphics will be invisible in the
game, but they can still be played (you just hear the sound).
So, in conclusion, "SUGR" is not a FourCC Video Codec Handler, but it is an internal identifier for the ICM_SETSTATE message, since there are probably different types of states that could be set, or at least the code was made prepared for this.
Please also see my pages for other Imagination Pilots games:
Blown Away | Panic in the Park | Waldo at the Circus | Waldo Exploring Geography | Eraser Turnabout | Virtual K'Nex