- Extension: DXA
- Company: Adventure Soft Publishing Ltd.
- Samples: http://www.mplayerhq.hu/MPlayer/samples/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/
All multi-byte numbers are stored in big endian format. A DXA file begins with a video header with is laid out as follows:
bytes 0-3 file signature: 'DEXA' byte 4 unknown bytes 5-6 frame count bytes 7-10 frame per second, saturated to an upper limit of 100 bytes 11-12 frame width bytes 13-14 frame height
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.
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.