Adorage SSA

• Company: proDAD

This is an Amiga animation format (SSA stands for "Super Smooth Animation") which employs rather complex RLE for video compression.

Format details

Since this is an Amiga format, all values are big-endian.

The SSA file starts with three blocks of data prefixed with 16-bit length of that block: magic string, format details and palette.

Magic string should always be "FEE_Anim_V1.0".

Format details contain display dimensions, bit depth (1-8 probably), coded frame dimensions (all as 16-bit variables) plus some other data.

Palette block starts with a byte telling palette depth followed by RGB triplets for each palette entry.

Then a fixed block of six 32-bit variables follows. Third value in it is the number of frames, and fourth value is the number of chunks/bitplanes.

After that chunks follow prefixed by 32-bit size. First 10 bytes of chunk payload are garbage (placeholders for various variables after loading it into memory). Chunks with sizes 12 or 16 should be treated as skipped.

Video compression details

The video frame is split into planes with each chunk updating one of the planes (frame should be output only when all planes have been decoded/skipped). Plane data is transmitted in 16-bit portions with complex opcodes telling how to update the plane. Each opcode byte is followed by another byte which is the repeat count minus one for most opcodes. Usually the first 16-bit value after those two bytes is the amount of bytes to skip (from the start or from the previous iteration of the opcode). Opcode values are multiple of 4 up to 0xA0.

Known opcodes:

• 0x00 — end of frame marker, should always have repeat count zero
• 0x04, 0x0C — double copy. Each operation starts with 16-bit skip value before the first copy operation, byte value for the first copy operation, and byte value for the second copy operation. Then first raw data portion follows, then 16-bit skip before the second copy, and finally second raw data portion. Opcode 0x0C means that copy lengths are calculated as val * 2 + 3 16-bit words instead of val * 2 + 2;
• 0x08, 0x10 — same principle but instead of raw data there are two 16-bit values that should be repeated in interleaved form;
• 0x14, 0x18, 0x1C, 0x34, 0x38, 0x3C, 0x40, 0x44, 0x48, 0x6C, 0x74, 0x7C, 0x84, 0x8C, 0x94, 0x9C — on each iteration read skip value and copy 1-16 values from the input (the number depends on opcode);
• 0x14, 0x4C, 0x50, 0x54, 0x58, 0x5C, 0x60, 0x64, 0x68, 0x70, 0x78, 0x80, 0x88, 0x90, 0x98, 0xA0 — on each iteration read skip value and the 16-bit value that should be repeated 1-16 times (1-value repeat or copy is the same operation);
• 0x20 — should not be present but it's treated the same as 0x24 by the reference decoder;
• 0x24, 0x2C — singular operation, repeat count actually codes the number of 32-bit values to copy from the input (plus an additional 16-bit value for 0x2C);
• 0x28, 0x30 — the same but it is repeating a pixel pair instead.

Here is an example to make it clearer: 4C 02 00 2A 12 34 00 08 56 78 02 9A BC 14 00 00 02 FF FF means "repeat pixel twice" (opcode 0x4C) operation that should be repeated three times. First time it's "skip 42 bytes from the beginning and output 0x1234 twice", second time it's "skip 8 bytes from the end of last operation (i.e. 42+2*2+8=54) and output 0x5678 twice", third time it's "skip 2 bytes from the end of last operation and output 0x9ABC twice". Next operation means "skip 2 bytes from the beginning and output 0xFFFF".