DXA

• Extension: DXA
• Company: Runesoft GmbH
• Samples: http://samples.mplayerhq.hu/game-formats/dxa/

The DXA format is used for videos in the Amiga and Macintosh versions of the Feeble Files. It is basically zlib compressed video frames, using WAV format for audio. The Macintosh version uses Microsoft ADPCM format for the audio.

The source code of a player for the DXA format can be found at: http://membres.lycos.fr/cyxdown/scummvm/feeble/

Data Format

All multi-byte numbers are stored in big endian format. A DXA file begins with a video header with is laid out as follows:

  dword Signature;
  byte  Version;
  word  Frames;
  dword FrameRate;
  word  Width;
  word  Height;

• Signature - File signature 'DEXA'.
• Frames - Number of logical frames.
• FrameRate - can be determined this way:

 if (FrameRate > 0)
   fps = 1000 / FrameRate;
 else if (FrameRate < 0)
   fps = 100000 / (-FrameRate);
 else
   fps = 10;

• Width, Height - Frame dimensions in pixels.

If the file contains an audio chunk, a Microsoft Wave file will be appear in its entirety after the video header.

Following any sound data there will be a sequence of CMAP, FRAM, and NULL chunks. The format of a CMAP chunk is as follows:

 bytes 0-3    chunk FourCC: 'CMAP'
 bytes 4-771  256 3-byte RGB palette triplets

Each palette component has a full 8-bit range of 0..255. The FRAM chunk is formatted as follows:

 bytes 0-3    chunk FourCC: 'FRAM'
 byte 4       compression type
 bytes 5-8    chunk size (not including this 9-byte preamble)
 bytes 9..    chunk payload

A NULL frame simply consists of the FourCC 'NULL'. There is no other data associated with it. A NULL frame instructs the decoder not to update the video buffer during this frame.

Video Coding

Compression method 2 is the standard zlib algorithm. The entire payload data buffer is fed into zlib's inflate() method and the output is the decompressed video frame. That video frame is presented to the user.

Compression method 3 is the same as method 2. However, the video data is decoded into a temporary buffer. Then, the entire frame is XOR'd against the previous frame and the result is presented to the user.

Compression methods 4 and 6 are unknown. Compression methods 5 and 7 are the same as methods 4 and 6, respectively, but the decoded data is XOR'd against the previously decoded frame, as is done with method 3.

Compression methods 12 and 13 are introduced in ScummVM > 0.9.1 for compressing cutscenes in different games. Both methods employ zlib compression and are used for delta frames and divide frame into 4x4 blocks, the first can store raw pixels block, mask and changed pixels only or motion compensation vector (all is packed with zlib). Compression method 13 can also divide 4x4 block into 2x2 subblocks and also fill block with pattern like IBM UltiMotion or Microsoft Video 1.