| Username: | Password: |  |
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 (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
|
RANDOM ARTICLE  Google THIS SITE FEATURED PROGRAM  HOT LINKS  ScummVMQuick & EasySCUMM Hacking Forummixnmojo.com |