Difference between revisions of "SCUMM/Technical Reference/Index File"
m (After the first initial version, added the category entry) |
m (corrected V3/4 block size interpretation) |
||
Line 90: | Line 90: | ||
* File's aren't xor'ed | * File's aren't xor'ed | ||
* Block Size does not include the | * Block Size does not include the 6 bytes used up by Block Name and Block Size, it's the size of the data that follows. | ||
Line 140: | Line 140: | ||
No of items (2 bytes) | No of items (2 bytes) | ||
*Owner of Object (1 byte) | *Owner of Object (1 byte) | ||
= Scumm 5 = | = Scumm 5 = |
Revision as of 21:58, 13 April 2007
SCUMM Technical Reference → SCUMM index file
Introduction
Most of the information below are retrieved from the LucasHacks! site and from the Pascal source code of the IndexFileReader 1.2 (written by Ben Gorman (Bgbennyboy, http://quick.mixnmojo.com). In addition, ScummRevisited (written by Jimmi Thøgersen (Serge), http://www.mixnmojo.com/scumm/scummrev) turned out to be very useful in verifying the found offsets.
The SCUMM index file contains special information to allow quick random access to the resources in the other game files. It also includes the room names and some max limits for the game. The following filenames are used:
filename | SCUMM version |
---|---|
00.lfl / 000.lfl | V3/4 |
.000 | V5/6 |
.LA0 | V7/8 |
Version 1 to 3 use hardcoded offsets and cannot be treated that easily. For the other games, the index file can be used to determine the SCUMM version because there have been slight changes in each version.
- Version 4: the 5th and 6th byte match RN or OR
- Version 5: RNAM xor'ed with 0x69 at the beginning of the file, next 4 byte integer xor'ed with 0x69 is > 9
- Version 6: RNAM xor'ed with 0x69 at the beginning, next 4 byte integer xor'ed with 0x69 is 9 (actually it's the size of the chunk. In V6 games, no room names are stored so the size is 4 bytes (header) + 4 bytes (size) + 1 byte for the termination character).
- Version 7: RNAM at the beginning of the file (not xor'ed this time), next 4 bytes result in BE integer 9. (NOTE: must be verified!)
- Version 8: RNAM at the beginning of the file, next 4 bytes integer is > 9
Conventions
As usual, the endianness (Wikipedia) is important. Unless stated, little endianess (LE) is used. BE is used as abbreviation for big endianness.
A Chunk is a named part of the file, e.g. RNAM. Each chunk has a header that contains at least the chunk name and its size. The following chunks are available:
RNAM Room Names | In V5+ |
MAXS Maximum Values | In V5+ |
DROO Directory of Rooms | In V5+ |
DRSC Direcory of Room Scripts | In V8 |
DSCR Directory of Scripts | In V5+ |
DSOU Directory of Sounds | In V5+ |
DCOS Directory of Costumes | In V5+ |
DCHR Directory of Charsets | In V5+ |
DOBJ Directory of Objects | In V5+ |
AARY List of Arrays | In V6+ |
ANAM Animation Names? | In V7 |
RM Room Names | In V3/4 |
0R Directory Of Rooms | In V3/4 |
0S Directory Of Scripts? | In V3/4 |
0N Directory Of Sounds? | In V3/4 |
0C Directory Of Costumes? | In V3/4 |
0O Directory Of Objects? | In V3/4 |
Scumm 3/4
- File's aren't xor'ed
- Block Size does not include the 6 bytes used up by Block Name and Block Size, it's the size of the data that follows.
RN
Block Size (4 bytes) Block Name (2 bytes) #Room No (1 byte) #Room Name (9 bytes) XOR'ed with FF Blank (00) byte (1 byte) Marks end of chunk
0R
Block Size (4 bytes) Block Name (2 bytes) No of items (2 bytes) *Room Number (1 byte) *Offset (4 bytes)
0S
Block Size (4 bytes) Block Name (2 bytes) No of items (2 bytes) *Room Number (1 byte) *Offset (4 bytes)
0N
Block Size (4 bytes) Block Name (2 bytes) No of items (2 bytes) *Room Number (1 byte) *Offset (4 bytes)
0C
Block Size (4 bytes) Block Name (2 bytes) No of items (2 bytes) *Room Number (1 byte) *Offset (4 bytes)
0O
Block Size (4 bytes) Block Name (2 bytes) No of items (2 bytes) *Owner of Object (1 byte)
Scumm 5
tbd.
Scumm 6
tbd.
Scumm 7
tbd.
Scumm 8
tbd.