|
|
<![CDATA[
SUPERZZT file format: By WiL
Used same layout as Kevin Vance's ZZT file format.
Legal BLAH goes here.
Things nobody knew about SUPERZZT:
16 total flags, maximum length 21 letters apiece
Which means in all practicality
15 flags, plus ONE flag beginning with Z, indicating the name of the special variable.
you can #set a flag multiple times without penalty. Setting a seventeenth unique flag
will simply overwrite the sixteenth.
I. SUPERZZT World Files
Header
0 1 2 3 4 5 6 7 8 9 A B C D E F
+-------+--------+-------+-------+---+---+---+---+---+---+---+----+
| FE FF|# Boards| Ammo | Gems | Bk| Gk| Ck| Rk| Pk| Yk| Wk| Hea}
+---+---+----+---+---+---+---+---+---+---+---+---+---+---+---+----+
{lth| St. Brd| ?? ?? |Score | ?? ?? |Ecycles| T1| Title }
+---+--------+-------+-------+-------+-------+-------+---+--------+
{ . |1F1| Flag1 }
+-------+----+---------------+---+--------------------------------+
{ . . . . |1F2| Flag2 }
+-------+----+---------------+---+--------------------------------+
{ . . . } Continues for 16 total flags
+-----------------------------+
+------------+--+------+
(181h) | ?? ?? ?? |SB|Stones} ?? until 192h
+------------+--+------+
+-------+
(192h) |Time } Pad with 00 until 400h
+-------+
The SUPERZZT header starts off with FE FF, this is the magic number to identify a
SUPERZZT world file. All of the 2 byte-long values in the header are Intel style
and unsigned. The rest of the header is explained below.
Label | Location | Description
----------+----------+---------------------------------------------
FE FF | 00-01 | Magic Number - Always FE FF
# Boards | 02-03 | Board Count (zero based)
Ammo | 04-05 | Starting amount of ammo
Gems | 06-07 | Starting amount of gems
Bk | 08 | Blue Key: 0=no, 1=yes
Gk | 09 | Green Key: 0=no, 1=yes
Ck | 0A | Cyan Key: 0=no, 1=yes
Rk | 0B | Red Key: 0=no, 1=yes
Pk | 0C | Purple Key: 0=no, 1=yes
Yk | 0D | Yellow Key: 0=no, 1=yes
Wk | 0E | White Key: 0=no, 1=yes
Health | 0F-10 | Starting amount of health
St. Brd | 11-12 | Starting board number
?? ?? | 13-14 | I beleive this has something to do with scrolling
Score | 15-16 | Starting amount of points
?? ?? | 19-1A | Also, scrolling is my best guess
Ecycles | 1B-1C | Number of Energizer cycles remaining
T1 | 1D | Length of world title
Title | 1E-21 | Title of world (usually filename)
1F1 | 22 | Length of Flag 1
Flag1 | 23-36 | Name of Flag 1
1F2 | 37 | Length of Flag 2
Flag2 | 38-4D | Name of Flag 2 (1F repeats 14x more)
?? ?? ?? | 181-183 | I have the slightest inclination to believe that two of
| these three bytes deal with time, thought I have not been
| able to lock down which two.
SB | 184 | Saved game byte: 0=world, 1=saved game
Stones | 185-186 | FF FF = stones variable not set, else = starting # of stones
?? | 187-192 | Padding, possibly?
Time | 193-194 | Time left
At least two of these unknown bytes deal with time.
IIa. Board Header
0 1 2 3 4 5 6 7 8 9 A B C D E F
+-------+----+----------------------------------------------------+
| size | tL | Title }
+-------+----+--------------------+-------------------------------+
{ . . . | Padding }
+---------------------------------+-------------------------------+
{ . . . }
+-------------------------------------------------------------+---+
{ . . . |
+-------------------------------------------------------------+
Label | Location | Description
---------+----------+---------------------------------------
Size | 00-01 | The size in bytes of the entire board
tL | 02 | The length of the board title
Title | 03-17 | The title of the Board
Padding | 18-3E | Just some padding (fill with 00s)
IIb. Run Length Encoding
0 1 2
+--------+------+--------+
| | | |
| Number | Code | Colour |
| | | |
+--------+------+--------+
SUPERZZT uses a simple run length encoding scheme for storing board layout
information. It encodes from the first tile on the first row to the second
tile on the first row, wrapping around to the first tile on the second row as
it goes. The first byte is the number of tiles to be expanded. The second
byte is the code for that file (see Appendix A). The third byte is the colour
for that tile. The colour is represented in standard VGA video memory form
(see Appendix B for more colour info).
The tiles are stored in this fashion for a whole screens worth of 60*25 (1500
tiles).
IIc. Board Information
0 1 2 3 4 5 6 7 8 9 A B C D E F
+----+---+---+---+---+---+---+-----------------------+-------+----+
| m#s| Bn| Bs| Bw| Be| Re| lM| Junk |T.Limit| ...}
+----+---+---+---+---+---+---+-----------------------+-------+----+
{ MoreJunk . . . |# obj |
+------------------------------------------------------------+
After the board tiles, the board information is written. This is the data that
you modify in the "Board Information" dialog box in the SUPERZZT Editor.
Label | Location | Description
---------+----------+------------------------------------------
m#s | 00 | Maximum number of shots fired
drk | 01 | Darkness: 0=no, 1=yes
Bn | 02 | Board # to north: 0=none, 1=second board
Bs | 03 | Board # to south: 0=none, 1=second board
Bw | 04 | Board # to west: 0=none, 1=second board
Be | 05 | Board # to east: 0=none, 1=second board
Re | 06 | Re-enter when zapped: 0=no, 1=yes
lM | 07 | Length of on-screen message
Junk | 08-0C | Random junk
T.Limit | 0D-0E | Time Limit for board
MoreJunk| 0F-1C | More random junk
# obj | 1D-1E | Number of objects on board
Most of these are self-explanatory. It is not possible to link a board to the
title screen. When a board link is set to zero, SUPERZZT does not link that side to
anything. When it is set to one, it links to board number one - the board
after the title screen. The on-screen message is used by the game only.
Modifying this will not cause SUPERZZT to display a message. The object count
includes everything with parameters: objects, creatures, passageways, and
more.
IId Objects
0 1 2 3 4 5 6 7 8 9 A B C D E F
+----+---+-------+-------+-------+---+---+---+---------------+----+
| x | y | x step| y step| cycle | P1| P2| P3| P4 | Ut |
+----+---+-------+---+---+---+---+---+---+---+---------------+----+
| Uc | pointer |cur.ins| length| Data starts here }
+----+---------------+-------+-------+----------------------------+
After the board information, the parameter records are written sequentially.
The order is not important, except that the player (yes, the player needs
parameters) must come first. The format for the object parameter records
varies depending on what kind it is for. A scroll makes different use of the P
values than a tiger. An important detail to note is that the x and y
parameters are 1 based. The top left corner of the screen is (1,1) not (0,0).
The "pointer" variable is only used internally by SUPERZZT, writing to it is not
necessary.
The sections below show how all of the parameter-needing objects in SUPERZZT are
used. Any unmentioned variables are unused by that object type and should have
zeros written to them.
Every object also has a Ut and Uc variable. Ut is the code of the tile
underneath the object and Uc is the colour of the tile underneath the object.
III other notes
With the obvious exception of the removal of the padding, every other object
is assumed to be the same as it is in SUPERZZT. No doubt the objects that have
been removed no longer show up as allowable types, but I'm working on that.
Code | Character | Description
------+---------------------------------------------------------
00 | 00 | Empty Space
01 | 00 | Special: acts like edge of board
02 | 00 | No known use
03 | 02 | Player (Not sure what does yet)
04 | 02 | Player
05 | 84 | Ammo
06 | 9D | None
07 | 04 | Gem
08 | 0C | Key
09 | 0A | Door
0A | E8 | Scroll
0B | F0 | Passage
0C | (growing O) | Duplicator
0D | 0B | Bomb
0E | 7F | Energizer
0F | ?? | ??
10 | (spins) | Clockwise conveyer
11 | (spins) | Counterclockwise conveyor
12 | ?? | ??
13 | B0 | Lava
14 | B0 | Forest
15 | DB | Solid
16 | D2 | Normal
17 | B1 | Breakable
18 | FF | Boulder
19 | 12 | Slider: North-South
1A | 1D | Slider: East-West
1B | B2 | Fake
1C | 00 | Invisible wall
1D | (varies) | Blink Wall
1E | (varies) | Transporter?
1F | (varies) | Line
20 | 2A | Ricochet
21 | ?? | ??
22 | EB | Bear
23 | 05 | Ruffian
24 | (varies) | Object
25 | 2A | Slime
26 | 5E | Shark
27 | (spins) | Spinning gun
28 | (varies) | Pusher
29 | EA | Lion
2A | E3 | Tiger
2B | ?? | ??
2C | E9 | Centipede head
2D | 4F | Centipede segment
2E | ?? | ??
2F | B0 | Floor (custom fake)
30 | 1F | Water north
31 | 1E | Water south
32 | 11 | Water west
33 | 10 | Water east
34-3A| 00 | Unknown
3B | 94 | Roton
3C | 94 | Dragon Pup
3D | E5 | Pairer
3E | 0F | Spider
3F | (varies) | Web
40 | (varies) | Stone of power
41-44| ?? | ??
45 | F8 | Bullet
46 | CD | Horizontal Blink Wall Ray
47 | BA | Vertical Blink Wall Ray
48 | (spins) | Star
49 \ | Text: blue
4A | | green
4B | | cyan
4C } (set in colour byte) | red
4D | | purple
4E | | yellow
4F / | white
50 \ | Blink Text: blue
51 | | green
52 | | cyan
53 } (set in colour byte) | red
54 | | purple
55 | | yellow
56 | | white
57 / | grey
Some of the types, when they don't have stats, are invisible, meaning they
show up as char 00h.
Some of the unknown types will cause a runtime error if you try and play them.
Also, runtime errors may be created by some wrong color usages on types, but
I have still not determined the cases in which this is true, if any. Blinking
text (as with regular ZZT) will probably cause the program to crash.
]]>
|
