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)

The Monkey Island 4 tile file format

Ok, here's the format description. Keep in mind that I don't know yet what most of the stuff is doing.

Before we start

First, you should get the EMI LAB extractor (or something similar) to extract all data fro t he bundle 'tile.lab'. That's the file where all background graphics are stored in.
Then, you should either decompress those files with GZIP, WinZip or the mgzip supplied with the LAB extractor. After you've done that, you're ready to read the file.

To prevent misunderstandings:
A 'long' is an 4 bytes wide, unsigned long.
A 'single' is an 4 bytes wide floating point value.
Screen coordinates are 0-based.
* is absolute.

At the beginning there was a header, and is looked like that:

Field		Type		Description
id		long		the tile ID, "TIL0"
bmoffset	long		start offset of the bitmap data
rects		long		number of rects
b		long		??
c		long		??

Now for a more detailed description of the single fields:

At the offset  a LucasArts-Bitmap is stored. This is the place where the real image data is.

The bitmap header:

Field		Type		Description
id		long		"BM  "
(unknown)	3*long		3 unknown longs
tiles		long		number of tiles
(unknown)	27*long		27 (twenty-seven) unknown longs

A rectangle (I think those singles are rects, might be something completely different) looks like that:

Field		Type		Description
x		single		X
y		single		Y
x2		single		second X
y2		single		second Y

After the tile header follow  times a rectangle. You may read it, but you might as well skip directly to the bitmap though the offset.

Well, now for the tile data. Each tile consists of 2 longs that tell us the width and the height of this tile. The tile data has a size of width*height*4 bytes. '*4' because the graphics are stored in 32-bit format.
There are  tiles in the file.

Here begins the 'dirty' part, it's really not nice but at least it works.
To show an image (only the background image, there are some other sprites or so stored within the data) I copy all the tiles onto an memory-buffer (a 'virtual screen'), and then get the image from this buffer, with a width of 640 and a height of 480.
To put these tiles into the memory-buffer you just copy one tile after another as if it was a sprite. There are (always?) three tiles in a row. If you've put three tiles, you increase the 'put position' (the y coordinate) by 256 (seems all tiles are 256*256, that's good for 3D cards).
Because the lower-right part of the background is in the third tile (what looks strange, and what wouldn't be saved in the 640*480 image anyway), you'll have to copy that 128*223 big strip to where it should be. The x/y position of the strip is 640/0, the destination x/y position is 512/256.

That's it! I hope I didn't forget any essential information, if you have questions or corrections then just mail me.

(c) 2000 by Benjamin Haisch
e-mail me:
visit my site:



SCUMM Revisited screenshot
SCUMM Revisited

Quick & Easy
SCUMM Hacking Forum