Open main menu

Difference between revisions of "SCI/Specifications/SCI in action/The message subsystem"

Merging of the SCI documentation. Done
(Merging of the SCI documentation. Work in progress.)
 
(Merging of the SCI documentation. Done)
 
Line 17: Line 17:
==Ties to audio==
==Ties to audio==
Of course, the story does not end there. CD-ROM games contain audio, and having two addressing schemes would have been a mess. So naturally, the same scheme was used. However, this poses another problem: Individual resources are usually addressed by just a type and a number, not by a message tuple like the one we saw above. Sierra's solution was to add a new resource type, other resource files and maps beside the main one. The extra resource files are called something like <tt>RESOURCE.AUD</tt> and <tt>RESOURCE.SFX</tt>, and their maps are contained in map resources, either in the main resource file or separately as patches. The resource type is called audio36, and there is a sync36 type as well which provides cueing capabilities to these resources (like sync does to ordinary audio resources, see section ???).
Of course, the story does not end there. CD-ROM games contain audio, and having two addressing schemes would have been a mess. So naturally, the same scheme was used. However, this poses another problem: Individual resources are usually addressed by just a type and a number, not by a message tuple like the one we saw above. Sierra's solution was to add a new resource type, other resource files and maps beside the main one. The extra resource files are called something like <tt>RESOURCE.AUD</tt> and <tt>RESOURCE.SFX</tt>, and their maps are contained in map resources, either in the main resource file or separately as patches. The resource type is called audio36, and there is a sync36 type as well which provides cueing capabilities to these resources (like sync does to ordinary audio resources, see section ???).
SCI message resources and their capabilities
{|
|Version
|StD
|Cond/Seq
|Rec
|SRec
|----
|early<ref>May not include a version number (needs confirmation)</ref>
|----
|2.101
|V
|----
|3.340
|V
|V
|V
|----
|3.411
|V
|V
|V
|----
|4.000
|V
|V
|V
|----
|4.010
|V
|V
|V
|----
|4.211
|V
|V
|V
|----
|4.321
|V
|V
|V
|V
|----
|5.000
|V
|V
|V
|V
|----
|}


The maps are indexed by module (room number), so that 100.map contains map entries for all the message tuples that have the module number 100. Map number 65535 (2<sup>16</sup>-1 ) is special - it indexes ordinary audio resources.
The maps are indexed by module (room number), so that 100.map contains map entries for all the message tuples that have the module number 100. Map number 65535 (2<sup>16</sup>-1 ) is special - it indexes ordinary audio resources.


To patch resources of this kind, Sierra used a base-36 encoding of the message tuple as the file name. Since this results in oddly looking names, the patch files, if any, are usually stored in a separate directory on the CD.  
To patch resources of this kind, Sierra used a base-36 encoding of the message tuple as the file name. Since this results in oddly looking names, the patch files, if any, are usually stored in a separate directory on the CD.
 
==File formats==
As can be seen from figure 6.1, the message file format and interfaces changed quite a bit over time. Interestingly, as perhaps the only part of the SCI system, message resource files incorporated a version number, with one exception. It is marked 'early' in the table. It is still possible to discern them from a corrupt resource, though.
 
The version numbers given in the table were divided by 1000 to yield an real-numbered representation; thus, the message format represented as <tt>2.101</tt> had a version tag of <tt>0x835</tt>.
 
All versions can be said to follow the general pattern given below; on the following pages, specific file formats are given for each version.
 
* HEADER
* MESSAGE OFFSETS
* ACTUAL TEXT
* COMMENTS/DEBUG
 
==early==
The exact file format is still not known, but seems to be the same as 2.101, without either the version number or the zero (Drantin?).
 
==Version 2.101==
The message resource begins with a 6-byte header, laid out thus:
 
{| border="1"
|Offset
|Size (bytes)
|Description
|----
|0
|2
|Version number (==0x835)
|----
|2
|2
|Always zero
|----
|4
|2
|Number of messages in file (<i>n</i>)
|}
 
The <i>n</i> offset records are laid out as follows:
 
{| border="1"
|Offset
|Size (bytes)
|Description
|----
|0
|1
|Noun
|----
|1
|1
|Verb
|----
|2
|2
|Offset to text (from beginning of resource)
|}
 
==Version 3.411==
The message resource begins with an 8-byte header, laid out thus:
 
 
{| border="1"
|Offset
|Size (bytes)
|Description
|----
|0
|2
|Version number (== 0xd53)
|----
|2
|2
|Always zero
|----
|4
|2
|Pointer to first byte past text data, not counting this header
|----
|6
|2
|Number of messages in file (<i>n</i>)
|}
 
The <i>n</i> offset records are laid out as follows:
 
{| border="1"
|Offset
|Size (bytes)
|Description
|----
|0
|1
|Noun
|----
|1
|1
|Verb
|----
|2
|1
|Condition
|----
|3
|1
|Sequence
|----
|4
|1
|Talker
|----
|5
|2
|Offset to text (from beginning of resource)
|----
|7
|3
|Unknown
|}
 
==Version 4.010==
The message resource begins with an 8-byte header, laid out thus:
 
 
{| border="1"
|Offset
|Size (bytes)
|Description
|----
|0
|2
|Version number (== 0xfaa)
|----
|2
|2
|Always zero
|----
|4
|2
|Pointer to first byte past text data, not counting this header
|----
|6
|2
|Number of messages in file (<i>n</i>)
|}
 
The <i>n</i> offset records are laid out as follows:
 
 
{|border="1"
|Offset
|Size (bytes)
|Description
|----
|0
|1
|Noun
|----
|1
|1
|Verb
|----
|2
|1
|Condition
|----
|3
|1
|Sequence
|----
|4
|1
|Talker
|----
|5
|2
|Offset to text (from beginning of resource)
|----
|7
|1
|Noun of referenced message
|----
|8
|1
|Verb of referenced message
|----
|9
|1
|Condition of referenced message
|}
 
The reference fields are set to zero if no reference is intended.
 


==Notes==
==Notes==
<references />
<references />
236

edits