Difference between revisions of "SCUMM/Technical Reference/Room resources"

From ScummVM :: Wiki
Jump to navigation Jump to search
Line 96: Line 96:
Each object have the following structure starting from its matching object content offset:
Each object have the following structure starting from its matching object content offset:


==== Object content header ====
<table border="2" cellspacing="0" cellpadding="4">
<table border="2" cellspacing="0" cellpadding="4">
<tr><th>Relative location</th><th>Format</th><th>Data</th></tr>
<tr><th>Relative location</th><th>Format</th><th>Data</th></tr>
Line 113: Line 114:
</table>
</table>


The object name starts at specified offset. Each character is added to the buffer until a 0x00 value is found.
'''Note:''' The object content data starts at byte 15, the verb-script pairs part ends with a 0x00 byte. This means that the object name offset value is always an even number between 16 and 254.
 
==== Object content data ====
 
Object content data contains 3 sections optional, in this order:
* 0 or more pairs of verb ids and object script offsets
* The name of the object
* 0 or more object scripts
 
===== Object script offsets =====
 
From byte 15, 2 UInt8 are read 2 by 2.
 
The first one is a reference to the verb ID and the second is an offset to the beginning of the object script.
 
This part ends with a 0x00.
 
===== Object name =====
 
The object name starts at specified offset. Each character is read until a 0x00 value is found.
 
===== Object script =====
 
Each object script ends with 0x00.

Revision as of 10:08, 17 November 2021

SCUMM V1

A room resource is located as the first chunk in a LFL File.

Header

The room resource starts with a 28 bytes header containing the following information:

LocationFormatData
0x00UInt16LESize of the room resource chunk
0x02???Unknown
0x04UInt16LERoom width in tiles
0x06UInt16LERoom height in tiles
0x08???Unknown (Always 0 on NES)
0x0aUInt16LEOffset to gfx nametable location (NES)
0x0cUInt16LEOffset to gfx attrtable location (NES)
0x0eUInt16LEOffset to mask flag value location
0x10???Unknown (On NES both these values are equal)
0x12???Unknown
0x14UInt8Number of objects in room
0x15UInt8Offset to number of boxes location
0x16UInt8Number of sounds in room (Always 0 on NES)
0x17UInt8Number of scripts in room
0x18UInt16LEOffset to exit script location
0x1aUInt16LEOffset to entry script location

All offsets are relative to the start of the chunk.

Note: Because of the following constraints:

  • Offset to box number location is stored as an UInt8, thus must be within the first 255 bytes of the chunk
  • The header takes 28 bytes
  • The combined size of object image and object content offsets is 4 bytes per object

The total number of objects per room must be less than 57:

(256 - 28) / 4 = 57

Data

Object image offsets

From byte 0x1c starts the offsets to object images:

LocationFormatData
0x1cUInt16LEOffset to object 1 image location
0x1eUInt16LEOffset to object 2 image location
...UInt16LERepeated objNum times

Object content offsets

From there, there is the list of offsets to each object content:

LocationFormatData
0x1c + objNum * 2UInt16LEOffset to object 1 content location
0x1e + objNum * 2UInt16LEOffset to object 2 content location
...UInt16LERepeated objNum times

Number of boxes

The boxes number in the room is located at the boxes number offset specified in the header.

LocationFormatData
Offset to number of boxesUInt8Number of boxes in room

Note: Some LFL files have unknown data between the last object content offset and the boxes number offset location. For most file however, both data are contiguous.

Boxes

2 bytes after the offset to number of boxes starts the payload for the boxes. Each box takes 8 bytes described as follow:

Relative locationFormatData
0x00UInt8uy
0x01UInt8ly
0x02UInt8ulx
0x03UInt8urx
0x04UInt8llx
0x05UInt8lrx
0x06UInt8mask
0x07UInt8flags

Box matrix

Immediately following the last box payload is the box matrix.

There are boxNum * boxNum number of them read as UInt8.

Object content

Each object have the following structure starting from its matching object content offset:

Object content header

Relative locationFormatData
0x00UInt8Size of the object content chunk
0x02???Unknown (Always 0 on NES)
0x03???Unknown (Always 0 on NES)
0x04UInt16LEThe object number (used to reference object in scripts)
0x06??Unknown (Always 0 on NES)
0x07UInt8X position of object
0x08UInt8Y position of object + Object parent state
0x09UInt8Object width in tiles
0x0aUInt8Object parent
0x0bUInt8Walk to X position
0x0cUInt8Walk to Y position
0x0dUInt8Actor facing direction + Object height in tiles
0x0eUInt8Offset to object name

Note: The object content data starts at byte 15, the verb-script pairs part ends with a 0x00 byte. This means that the object name offset value is always an even number between 16 and 254.

Object content data

Object content data contains 3 sections optional, in this order:

  • 0 or more pairs of verb ids and object script offsets
  • The name of the object
  • 0 or more object scripts
Object script offsets

From byte 15, 2 UInt8 are read 2 by 2.

The first one is a reference to the verb ID and the second is an offset to the beginning of the object script.

This part ends with a 0x00.

Object name

The object name starts at specified offset. Each character is read until a 0x00 value is found.

Object script

Each object script ends with 0x00.