-
Notifications
You must be signed in to change notification settings - Fork 4
/
sect12.html
228 lines (184 loc) · 7.82 KB
/
sect12.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
<!DOCTYPE html>
<html>
<head>
<title>The Z-Machine Standards Document</title>
<link rel="stylesheet" type="text/css" href="zspec.css">
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
</head>
<body>
<img class="icon" src="images/icon12.gif" alt="">
<h1>12. The object table</h1>
<hr>
<p>12.1 <a href="#12.1">Storage</a> /
12.2 <a href="#12.2">Property defaults table</a> /
12.3 <a href="#12.3">Object tree</a> /
12.4 <a href="#12.4">Property tables</a> /
12.5 <a href="#12.5">Well-foundedness of the tree</a>
</p>
<hr>
<h2 id="12.1">12.1</h2>
<p>The object table is held in dynamic memory and its byte address
is stored in the word at <strong>$0a</strong> in the header. (Recall that objects
have flags attached called attributes, numbered from 0 upward, and
variables attached called properties, numbered from 1 upward. An
object need not provide every property.)
</p>
<h2 id="12.2">12.2</h2>
<p>The table begins with a block known as the property defaults table.
This contains 31 words in Versions 1 to 3 and 63 in Versions 4 and later.
When the game attempts to read the value of property n for an object
which does not provide property n, the n-th entry in this table
is the resulting value.
</p>
<h2 id="12.3">12.3</h2>
<p>Next is the object tree. Objects are numbered consecutively from
1 upward, with object number 0 being used to mean "nothing" (though
there is formally no such object). The table consists of a list of
entries, one for each object.
</p>
<h2 id="12.3.1"> 12.3.1</h2>
<p>In Versions 1 to 3, there are at most 255 objects, each having
a 9-byte entry as follows:
</p>
<pre>
the 32 attribute flags parent sibling child properties
---32 bits in 4 bytes--- ---3 bytes------------------ ---2 bytes--
</pre>
<p><strong>parent</strong>, <strong>sibling</strong> and <strong>child</strong> must all hold valid object numbers.
The <strong>properties</strong> pointer is the byte address of the list of
properties attached to the object. Attributes 0 to 31 are flags
(at any given time, they are either on (1) or off (0)) and are stored topmost
bit first: e.g., attribute 0 is stored in bit 7 of the first byte,
attribute 31 is stored in bit 0 of the fourth.
</p>
<h2 id="12.3.2"> 12.3.2</h2>
<p>In Version 4 and later, there are at most 65535 objects, each
having a 14-byte entry as follows:
</p>
<pre>
the 48 attribute flags parent sibling child properties
---48 bits in 6 bytes--- ---3 words, i.e. 6 bytes---- ---2 bytes--
</pre>
<h2 id="12.4">12.4</h2>
<p>Each object has its own property table. Each of these can be
anywhere in dynamic memory (indeed, a game can legally change an object's
properties table address in play, provided the new address points to
another valid properties table).
The header of a property table is as follows:
</p>
<pre>
text-length text of short name of object
-----byte---- --some even number of bytes---
</pre>
<p>where the <strong>text-length</strong>
is the number of 2-byte words making up the text,
which is stored in the usual format. (This means that an object's short
name is limited to 765 Z-characters.) After the header, the properties
are listed in descending numerical order. (This order is essential and
is not a matter of convention.)
</p>
<h2 id="12.4.1"> 12.4.1</h2>
<p>In Versions 1 to 3, each property is stored as a block</p>
<pre>
size byte the actual property data
---between 1 and 8 bytes--
</pre>
<p>where the <strong>size byte</strong> is arranged as 32 times the number of data bytes
minus one, plus the property number. A property list is terminated by
a size byte of 0. (It is otherwise illegal for a size byte to be a
multiple of 32.)
</p>
<h2 id="12.4.2"> 12.4.2</h2>
<p>In Versions 4 and later, a property block instead has the form</p>
<pre>
size and number the actual property data
--1 or 2 bytes--- --between 1 and 64 bytes--
</pre>
<p>The property number occupies the bottom 6 bits of the first size byte.</p>
<h2 id="12.4.2.1"> 12.4.2.1</h2>
<p>If the top bit (bit 7) of the first size byte is set, then there are
two size-and-number bytes as follows. In the first byte, bits 0 to
5 contain the property number; bit 6 is undetermined (it is clear in
all Infocom or Inform story files); bit 7 is set. In the second byte,
bits 0 to 5 contain the property data length, counting in bytes;
bit 6 is undetermined (it is set in Infocom story files, but clear
in Inform ones); bit 7 is always set.
</p>
<h2 id="12.4.2.1.1"> 12.4.2.1.1</h2>
<p><strong>***</strong>
A value of 0 as property data length (in the second
byte) should be interpreted as a length of 64. (Inform can compile
such properties.)
</p>
<h2 id="12.4.2.2"> 12.4.2.2</h2>
<p>If the top bit (bit 7) of the first size byte is clear, then there is
only one size-and-number byte. Bits 0 to 5 contain the property number;
bit 6 is either clear to indicate a property data length of 1, or
set to indicate a length of 2; bit 7 is clear.
</p>
<h2 id="12.5">12.5</h2>
<p>It is the game's responsibility to keep the object tree
well-founded: the interpreter is not required to check.
"Well-founded" means the following:
</p>
<p><strong>(a)</strong> An object with a sibling also has a parent.</p>
<p><strong>(b)</strong> An object is the parent of exactly those objects
in the sibling list of its child.
</p>
<p><strong>(c)</strong> Each object can be given a level n, such that
parentless objects have level 0 and all children of a level
n object have level n+1.
</p>
<hr>
<h2 id="remarks">Remarks</h2>
<p>The largest valid object number is not directly stored anywhere
in the Z-machine. Utility programs like <strong>Infodump</strong> deduce this
number by assuming that, initially, the object entries end where
the first property table begins.
</p>
<p>Infocom's 'Sherlock' contains a bug making it try to set and
clear attribute 48.
</p>
<p>The reason why the second property size byte needs to have top bit
set is that the size field must be parsable either forwards or
backwards -- the Z-machine needs to be able to reconstruct the
length of a property given only the address of the first byte
of its data. (There are very many (e.g. 2000) property entries
in a story file, so optimising size into one byte most of the
time is worthwhile.)
</p>
<p>Bit 6 in the second byte is presently wasted, which is a pity as
it could be used to allow up to 128 bytes of property data. But such
a change would cause Infocom's story files to fail (since they
set this bit, unlike Inform story files).
</p>
<p>Inform can only construct well-founded object trees as the initial game
state, but it is easy to compile sequences of code like "move red box to
blue box" followed by "move blue box to red box" which leave the object
tree in an ill-founded state. (The Inform library protects the standard
object-movement verbs against this.)
</p>
<hr>
<p>
<a href="index.html">Contents</a> /
<a href="preface.html">Preface</a> /
<a href="overview.html">Overview</a>
</p>
<p>Section
<a href="sect01.html">1</a> / <a href="sect02.html">2</a> /
<a href="sect03.html">3</a> / <a href="sect04.html">4</a> /
<a href="sect05.html">5</a> / <a href="sect06.html">6</a> /
<a href="sect07.html">7</a> / <a href="sect08.html">8</a> /
<a href="sect09.html">9</a> / <a href="sect10.html">10</a> /
<a href="sect11.html">11</a> / <a href="sect12.html">12</a> /
<a href="sect13.html">13</a> / <a href="sect14.html">14</a> /
<a href="sect15.html">15</a> / <a href="sect16.html">16</a>
</p>
<p>Appendix
<a href="appa.html">A</a> / <a href="appb.html">B</a> /
<a href="appc.html">C</a> / <a href="appd.html">D</a> /
<a href="appe.html">E</a> / <a href="appf.html">F</a>
</p>
<hr>
</body>
</html>