https://wiki.multimedia.cx/api.php?hidebots=1&hideanons=1&days=7&limit=50&action=feedrecentchanges&feedformat=atomMultimediaWiki - Recent changes [en]2024-03-29T07:21:02ZTrack the most recent changes to the wiki in this feed.MediaWiki 1.39.5https://wiki.multimedia.cx/index.php?title=Talisman_ANI&diff=15765&oldid=0Talisman ANI2024-03-22T14:50:32Z<p>fill format description</p>
<p><b>New page</b></p><div>* Company: Software 2000<br />
* Extension: ani<br />
* Game: [https://www.mobygames.com/game/32166/talisman/ Talisman]<br />
<br />
This is a rather peculiar video game format that uses frame data compression in addition to the frame coding.<br />
<br />
The file consists of chunks of various types, each starting with 32-bit little-endian chunk type and 32-bit payload size (compressed payload will start with an additional 32-bit unpacked size).<br />
<br />
== Known chunks ==<br />
* <code>0x1234</code> -- ANI header, should be 20 bytes long (always unpacked);<br />
* <code>0x4321</code> -- sync chunk, should be 16 bytes long (always unpacked);<br />
* <code>0x1111</code> -- Huffman codebooks data, always unpacked;<br />
* <code>0x2001</code> -- intra frame;<br />
* <code>0x2110</code> -- inter frame;<br />
* <code>0x2332</code> -- seems to always contain 32-value equal to one (obviously unpacked), probably skip frame signal;<br />
* <code>0x2553</code> -- probably the same, not encountered in game files;<br />
* <code>0x3456</code> -- unknown, might be related to audio data;<br />
* <code>0x5544</code> -- palette (unpacked), always 768 bytes;<br />
* <code>0xABCD</code> -- acknowledged by the decoder as unpacked but not encountered in game files.<br />
<br />
=== Header chunk ===<br />
The header chunk should be the first in the file, occur only once. It contains the following information:<br />
* 32-bit image width<br />
* 32-bit image height<br />
* 32-bit value that is always zero<br />
* 32-bit value that is always 300000<br />
* 32-bit number of frames<br />
<br />
=== Sync chunk ===<br />
Sync chunks mark a sequence aka group of frames (an intra frame plus some inter frames).<br />
<br />
* 32-bit offset to the next sync chunk<br />
* 32-bit value that is always zero<br />
* 32-bit value that looks like some suggested buffer size<br />
* 32-bit number of video frames until next sync chunk<br />
<br />
=== Codebooks data chunk ===<br />
This chunk contains Huffman codebook definition.<br />
<br />
First there may be a sequence of <code>0xFF</code> bytes that should be ignored.<br />
<br />
The first byte with another value tells which Huffman tree should be used for the sequence.<br />
<br />
The following data contains symbol values for the Huffman trees. It starts with an opcode telling what to do with the entries: <code>0xFF</code> means skip definition set, <code>0x00..0x7F</code> mean the next byte is the number of new symbols and the following N bytes are new symbol values, other values mean previously decoded definition with number in the low seven bits should be re-used (skipped ones included but should not be re-used).<br />
<br />
See the next section on how that data is used.<br />
<br />
=== Chunks unpacking ===<br />
Chunks are packed using order-1 static Huffman codes with some predefined tables and per-sequence symbol values (defined in chunk <code>0x1111</code>). That means when the data is decoded, it reads the same code set but the symbol value depends on the definitions transmitted in the chunk so e.g. if symbol <code>011</code> meant 0 in one sequence, it may mean 4 in another.<br />
<br />
First symbol is transmitted as is, then actual Huffman bitstream follows (packed in 16-bit words, MSB first). The first byte is transmitted as is since the symbol table is defined for the previously decoded symbol and newly decoded value from the stream. Chunk <code>0x1111</code> stores those context-dependent symbol definitions for each previously decoded value and all possible input values (i.e. first set is used when previous symbol value is 0, next set is used when previous symbol value is 1 and so on).<br />
<br />
== Video decoding ==<br />
Video frames are split into 2x2 blocks and use motion value in byte form (low nibble - X offset, high nibble - Y offset) with nibble values being signed (e.g. nibble value <code>0x3</code> means offset 3 and nibble value <code>0xD</code> means offset -3).<br />
<br />
Frame data is split into two parts, namely the motion vectors data (and run values) and pixel values. 32-bit value at the beginning tells where the pixel data starts (motion data always starts at offset 4).<br />
<br />
Codes <code>0x00..0xF6</code> copy 2x2 block using the corresponding motion vector (<code>0x00</code> - do nothing, <code>0x3D</code> - copy with 3,-3 offset).<br />
<br />
Codes <code>0xF7..0xFA</code> read a motion vector byte and a pixel byte, copy block from the specified location and replace pixel 3..0 with the new pixel value.<br />
<br />
Codes <code>0xFB..0xFD</code> read a motion vector byte and copy the source block rotated by 90/180/270 degrees counter-clockwise correspondingly.<br />
<br />
Code <code>0xFE</code> reads a run value (that may be prefixed with several <code>0xFF</code> to add 255 to its value) from motion data section and skips the signalled number of blocks.<br />
<br />
Code <code>0xFF</code> reads four pixel values for the block.<br />
<br />
Inter frame seems to be the same but uses the intra frame as the reference.<br />
<br />
[[Category:Game Formats]]<br />
[[Category:Video Codecs]]</div>Kostya