Username:    Password:    Login
Main  Secrets  Links  Specs  Articles  Forum  News  Downloads  Utilities  SCUMM?  Games  Demos  Contact
Main  Secrets  Links  Specs  Articles  Forum  News  Downloads  Utilities  SCUMM?  Games  Demos  Contact

SCUMM file format specifications and documentation

The Really Useful SCUMM etc. Info File
Maniac Mansion .lfl-files
Additional .lfl info
AKOS format
Preliminary SAN documentation
Monkey Island 1 & 2 costume format
Monkey Island 2 costume format
Monkey Island 2 SCUMM opcodes
SCUMM index files
.bun file format
.lab file format
EMI .lab file format
EMI .til file format
GF/EMI .laf fonts file format
EMI mesh specs

(download file)

AKOS: The Costume Format From Hell

WARNING: I do not guarantee all the information in this document is correct. I'm mainly interpreting from the ScummVM source code. If you have a correction to make, please do so!
ANOTHER WARNING: I won't be covering the AKSQ and AKCH stuff here. I tried, but the ScummVM code is messy, to say the least. Maybe one of its developers could document the sequence and animation stuff?
YET ANOTHER WARNING: This stuff may confuse you. I apologize for the inconvenience.
ONE MORE WARNING: Codec 16 still confuses me. I can't cover it. Sorry.

AKOS is an actor costume format. A costume is a set of graphics and animation which visualizes an actor (which is a good thing, otherwise Guybrush would be invisible). AKOSes are found in SCUMM versions 7 and 8, including Full Throttle, The Dig, and Curse of Monkey Island. Older SCUMM engines used the original "COST" costume format, but AKOS replaced it because it provided new stuff like larger images, better compression, and color effects like shadows.

Technical Stuff

Please make sure you understand how a palettized computer display works before you try to conquer the AKOS format.
You should probably know about SCUMM's actor palette system before reading on, so here you go:
Each actor contains its own special palette table. Whenever the AKOS renderer draws a pixel, that pixel's value (from the AKOS data) is translated into the actual pixel (to be drawn to the screen) using this palette table. For instance, if it has to draw "1", it will look in the first entry of the palette table for the pixel it should write to the display.
Why does it do this? Well, it really helps when the SCUMM engine needs to apply a color effect to the costume (also called a "remap"). Here's how it would make a costume slightly bluer, for example. For each entry in the actor's palette:
A) Compute the result color (which is slightly bluer) using the RGBS block as a reference (more on that below).
B) Search the hardware palette for a color which most closely matches the color it's looking for.
C) If that color is still not accurate enough, find an unused entry to change instead.
D) Remap the actor's palette table entry to the entry found in the hardware palette.
So, hopefully you can see the palette system's purpose.

The Chunks

An AKOS is based on the IFF format, and begins with the following header:

Name ("AKOS")     (4 bytes)
Size (big endian) (4 bytes)

This is followed by a series of IFF chunks, described below:
AKHD: The AKOS Header, containing some important information about the costume.
AKPL: The AKOS Palette, containing the initial palette table for the actor. This block may be empty in some costumes!
RGBS: RGB Values, used by the SCUMM engine as a reference when applying a color effect to a costume. Contains the actual colors used in the costume. This block isn't used in some costumes!
AKOF: AKOS Offsets. This is used to find frame data in the AKCI and AKCD blocks.
AKCI: AKOS Costume Information. This contains the width, height, and position of each frame.
AKCD: AKOS Costume Data. The most important block! Contains the compressed costume frames.


Name ("AKHD")        (4 bytes)
Size (big endian)    (4 bytes)
Unknown              (2 bytes)
Flags                (1 byte)
Unknown              (1 byte)
Number of Animations (2 bytes)
Number of Frames     (2 bytes)
Codec                (2 bytes)

As you can see, a couple fields haven't been identified yet. However, the ScummVM source code labels "Number of Frames" as unknown, but I've figured it out. 

There are only two known flags in the Flags field:
Bit 0: If set, the renderer will need to mirror frames for the actor to face certain directions.
Bit 1: If set, the actor can face 8 directions, rather than 4.

There are three codecs: Codec 1, Codec 5, and Codec 16. The codec specifies the type of compression used to compress the frames in the costume. Codec 1 is the same codec used in the old "COST" format, Codec 5 uses BOMP compression, and Codec 16 uses a bit stream encoding technique. I'll describe the codecs later.


The AKPL stores the actor's palette table and looks like this:

Name ("AKPL")         (4 bytes)
Size (big endian)     (4 bytes)
Palette Table Entries (1 byte, continues to end of block)

The RGBS stores the actor's colors, and looks like this:

Name ("RGBS")     (4 bytes)
Size (big endian) (4 bytes)
[Until end of block:]
Red               (1 byte)
Green             (1 byte)
Blue              (1 byte)


This block is used to find frame data in the AKCI and AKCD blocks.

Name ("AKOF")     (4 bytes)
Size (big endian) (4 bytes)
[Repeating until end of block:]
AKCD Offset       (4 bytes)
AKCI Offset       (2 bytes)


This block contains information about each frame.

Name ("AKCI")       (4 bytes)
Size (big endian)   (4 bytes)
[Repeating until end of block:]
Width               (2 bytes)
Height              (2 bytes)
Relative X Position (2 bytes)
Relative Y Position (2 bytes)
X Movement          (2 bytes)
Y Movement          (2 bytes)

When the renderer wants to draw at an X, Y position, it will need to compute the actual position to render on the screen with the "Relative" fields. This lets the costume identify its position with the offset of, say, Guybrush's feet rather than the top left of the frame.


Name ("AKCD")     (4 bytes)
Size (big endian) (4 bytes)
Data              (X bytes, until end of block)

The all-important AKCD block! It contains the compressed frame data itself. Let's take a look at the codecs:

Codec 1

This is the same codec as used in the old "COST" format. It works like this:

Byte Identification:
If NumColors = 32 then
5 bits for color, 3 bits for repeat.
Else if NumColors = 64 then
6 bits for color, 2 bits for repeat.
4 bits for color, 4 bits for repeat.

For each byte in data:
If repeat = 0 then
repeat = next byte.
For repeat value:
Plot color at pixel. Advance row.
If row > height then
Back to original row. Advance column.
If column > width then

Codec 5

This is just BOMP disguised as an AKOS codec. It works like this:

For each row:
Code = next byte.
Repeat = (code >> 1) + 1.
If first bit in code is set then
Color = next byte.
For repeat value: Plot color at pixel. Advance column.
For repeat value: Plot next byte at pixel. Advance column.
If column > width then next row!

Codec 16

This is the tricky one. It's a bit stream encoded thing that baffled the ScummVM developers for a while. Then one of them disassembled it and said, "This shouldn't be too hard," and implemented it. What the heck? I need somebody to explain it to me, really.



SCUMM Revisited screenshot
SCUMM Revisited

Quick & Easy
SCUMM Hacking Forum