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)


MANIAC MANSION .LFL FILES (01-52)

 Each LFL file corresponds to a room. This can be demonstrated by swapping
two LFL files For example, let's say you swap 03.LFL and 23.LFL. When you run
the game again and enter the lounge (with the sofa), you will instead walk
into the room with the piano and vice versa at the other location.

 An LFL file is xor encoded with the byte 0xFF. This means that every byte in
the file has been xored with 0xFF. A very simple program can be written to
decrypt the file and the beauty of this program is that it would operate in
both directions.


LFL FILE FORMAT

 Byte         Description                            Example (MM 03.LFL)

  0-1          Offset to something near the end?      B8 0E   (0x0EB2)
   2           ?                                      00
   3           ?                                      D4
   4           Width of picture in columns.           50 (80)
   5           Height of picture in rows.             11 (17)
   6           Color 0 (C64 value)                    00 (Black)
   7           Color 1 (C64 value)                    09 (Brown)
   8           Color 2 (C64 value)                    0A (Lt. Red)
   9           ?                                      01
 10-11         Offset to picture character set.       B1 00 (0x00B1)
 12-13         Offset to picture screen map.          B5 05 (0x05B5)
 14-15         Offset to picture colour map (C64).    AD 08 (0x08AD)
 16-17         Offset to picture walk behind mask.    01 09 (0x0901)
 18-19         Offset to walk behind mask char data.  30 09 (0x0930)
  20           Number of objects.                     0E (14)
  21           ?                                      56
  22           Number of unknown bytes #1 (NUB1)      01
  23           Number of unknown bytes #2 (NUB2)      01
 24-25         Unknown offset.                        85 0E
 26-27         Unknown offset.                        8F 0E

 Notes:

  (1)  Maniac Mansion was designed initially for the Commodore 64. Almost
       exactly the same data is used in the PC version. This means that the
       colours mentioned above relate to the C64 palette.

  (2)  Offsets 22 and 23 store the size of two later section sections. When
       we work out the purpose of these sections, we can give these fields
       a better name.


 Up to this point everything is of a set length. Past this point almost
everything has a variable length.


OFFSETS TO OBJECT IMAGES

 These always appear at offset 28.
      ____ ____
     |    |    |
     | Lo | Hi | ....    (repeated for each object)
     |____|____|

 The images at these locations are a lot like add.to.pics in the Sierra AGI
 system. At some stage they will be applied to the screen to change the
 background image in some way. For example, when a door is opened, the open
 door image is placed on top of the closed door image.


OFFSETS TO OBJECT CODE
      ____ ____
     |    |    |
     | Lo | Hi | ....    (repeated for each object)
     |____|____|

 The object code sections seem to store information such as the dimensions
 of the object, the name of the object, and then responses to various actions
 performed on the object.
 

FIRST SET OF UNKNOWN BYTES

 The purpose of this section is not know at this stage. It usually quite
 short. The length is given by NUB1 mentioned earlier (in bytes).


SECOND SET OF UNKNOWN BYTES

 The purpose of this section is not know at this stage. It usually quite
 short. The length is given by NUB2 mentioned earlier (in bytes).


NUMBER OF BOXES (1 Byte)

 The walking space that the actors can walk about in is made up of a number
of shapes. The purpose of these boxes is to control how the actors walk
between certain parts of the screen. Even though they appear to be called
boxes, there are some that are more like triangles and trapeziums.

 The number of boxes field says how many of these boxes there are.


BOX DIMENSIONS

 This section gives data that determines the shape of the boxes. For every
 box there is an eight byte structure as below:

   _______ _______ _________ _________ _________ _________ _______ _______
  |       |       |         |         |         |         |       |       |
  | Y-Top | Y-Bot | X-L-Top | X-R-Top | X-L-Bot | X-R-Bot |   ?   |   ?   |
  |_______|_______|_________|_________|_________|_________|_______|_______|

  Y-Top*2 = pixel line for the top of the box.
  Y-Bot*2 = pixel line for the bottom of the box.
  X-L-Top = the row of the top left corner.
  X-R-Top = the row of the top right corner.
  X-L-Bot = the row of the bottom left corner.
  X-R-Bot = the row of the bottom right corner.

  The last two fields are unknown.

  Notes:

    (1)  The top and bottom sides of the box are horizontal lines whereas the
         left and right sides can be diagonal.

    (2)  The background picture is made up like a text screen with a certain
         number of columns and rows. Each character position on that screen
         is 8x8 pixels in dimension. Thus, the row values above must be
         multiplied by 8 to give the x pixel positions.


BOX MATRIX ROW OFFSETS

 This section contains the offset of each row in the matrix that follows.
 Each offset is on byte in length which means that the total length of this
 section is given by the number of boxes field mentioned above.

  Example (03.LFL):  00 06 0C 12 18 1E

 Note: There are six offsets each six in value apart from each other. Thus
 the number of boxes in this case must be six.


BOX MATRIX

 The box matrix tells the interpreter how to make an actor walk between boxes.
 For example, if two boxes are reasonably close, but there is a fence in the
 way that should prevent them from walking that way, then the actor needs to
 walk around the fence when the box on the other side of the fence is clicked
 on. The left side of the matrix is the 'from' box and the top of the matrix
 is the 'to' box.

 For example,

         To
   F 00 01 01 01
   r 00 01 02 02
   o 01 01 02 03
   m 02 02 02 03

 To walk from box 3 to box 0, you have to firstly walk through box 2. To then
 walk from box 2 to box 0, you have to walk through box 1, and finally to walk
 from box 1 to box 0, you simply have to walk straight to box 0.

 Now, matrices of the pattern above are for rooms that have there boxes nicely
 joined in a row like so:

          +------+      +------------+
   +------+      +------+            |
   |   0  |   1  |  2   |     3      |
   +------+------+------+------------+

 However, a lot of rooms have a fairly complex walking space which gives rise
 to larger matrices with more complex patterns.

            +--------+
            |    4   |
            +-+----+-+ 
  +-------+   |  2 |   +-----------+
  |   0   +---+----+---+     3     |
  |       |     1      |           |
  +-------+------------+-----------+

 For example, the layout shown above would produce a matrix as follows:

   00 01 01 01 01
   00 01 02 03 02
   01 01 02 01 04
   01 01 01 03 01
   02 02 02 02 04

 The data above would be stored in the LFL file as:

  00 01 01 01 01 00 01 02 03 02 01 01 02 01 04 01 01 01 03 01 02 02 02 02 04


CHARACTER DATA

 The background pictures for Maniac Mansion are designed to be displayed in
 the Commodore 64's multicolour graphics mode. The screens are composed of
 characters. Each background picture has a character set of size 256. The
 data is in a compressed form, but when uncompressed, this data would have
 been stored in the location of memory that was currently acting as the C64's
 character memory. It is probably a good time at this stage to familiarise
 yourself with the C64 graphics system.

 The first four bytes are common bytes. They appear the most often in the
 uncompressed character data.

   Example (03.TST):  AA 00 99 FF

     AA = 10101010 = Colour 2 | Colour 2 | Colour 2 | Colour 2
     00 = 00000000 = Colour 0 | Colour 0 | Colour 0 | Colour 0
     99 = 10011001 = Colour 2 | Colour 1 | Colour 2 | Colour 1
     FF = 11111111 = Colour 3 | Colour 3 | Colour 3 | Colour 3

 This is how they are interpreted in C64 multicolour mode. Following these
 four bytes is the actual compressed character data. There are some special
 codes that control how this is decoded:

   00-3F   # of different bytes that follow.
   40-7F   # of times to repeat byte that follows.
   80-9F   # of times to repeat common byte 1.
   A0-BF   # of times to repeat common byte 2.
   C0-DF   # of times to repeat common byte 3.
   E0-FF   # of times to repeat common byte 4.
  
 Examples:

   (1)  06 35 04 26 CF 45 04 16

        The 06 code is between 00 and 3F which means that it is the first
        case. The value 06 says that there are seven bytes that follow which
        are to be interpreted as uncompressed character data (00 = 1 byte,
        01 = 2 bytes, etc).

   (2)  43 0F

        This code 43 is between 40 and 7F. The value 43 says that the
        following byte is repeated four times ((0x43 & 0x3F) + 1). So
        43 0F = 0F 0F 0F 0F

   (3)  87

        This code is between 80 and 9F. The value 87 says to repeat common
        byte 1 eight times ((0x87 & 0x1F) + 1). So for the common byte
        examples give earlier, 87 = AA AA AA AA AA AA AA AA.

        The next three codes operate in a simlar fashion but for the other
        three common bytes. So, using the same example common byte values,

        A5 = 00 00 00 00 00 00
        B1 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        CB = 99 99 99 99 99 99 99 99 99 99 99 99
        E0 = FF
        F3 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

        The codes 87, A7, C7, and E7 are seen quite frequently because a
        length of eight makes up a whole character. The data for one
        character takes up eight bytes.

 The character data section of an LFL file is a series of code sequences like
 those shown above. When the data is uncompressed, the result is a C64
 character set of size 2048. The decompression stops when the uncompressed
 data reaches this length.


PICTURE SCREEN MAP

 The screen map is compressed in an identical manner to the character data,
 the difference being that the uncompressed data is interpretered as an
 array of characters rather than an array of character bitmap data.

   +-------------------+   The uncompressed data flows from top to bottom,
   | 0 17 34 ...       |   left to right on the virtual screen. It seems that
   | 1 18 34 ...       |   most if not all Maniac Mansion background pictures 
   | 2 19 36 ...       |   have seventeen rows. Therefore the diagram to the
   | 3 20 37 ...       |   left shows the situation in most cases where, for
   | .  .  .           |   example, 37 is the character at offset 37 in the
   | .  .  .           |   uncompressed screen map.
   +-------------------+

 The decompression stops when the length of the uncompressed data is equal
 to the height * width of the picture. These values are given right near the
 start of the LFL file (see earlier section).


PICTURE COLOUR MAP

 The colour map is once again compressed in the same manner as the character
 data and screen map. In this case the uncompressed data is interpreted as
 C64 colour values. The uncompressed data follows the same top to bottom,
 left to right ordering as for the screen map. The decompression stops when
 the uncompressed data is equal in length to the height * width of the
 picture. The resulting data will be placed in the C64's colour memory and
 will therefore become the fourth colour for the multicolour mode blocks. 

 The actual colour is given by the bottom three bits. The fourth bit is
 always set to show that the character at that location will be displayed
 in multicolour mode. This further highlights the fact that the data was
 designed for the C64 and was brought across nearly untouched.

          7   6   5   4   3   2   1   0
        +---+---+---+---+---+---+---+---+
        | 0 | 0 | 0 | 0 | 1 | C | C | C |           C = colour.
        +---+---+---+---+---+---+---+---+
                          |________________________ multicolour mode
                          
scumm.mixnmojo.com

RANDOM ARTICLE
Article


Google THIS SITE
Web
scumm.mixnmojo.com


FEATURED PROGRAM
SCUMM Revisited screenshot
SCUMM Revisited



HOT LINKS
ScummVM
Quick & Easy
SCUMM Hacking Forum
mixnmojo.com