Resource centre for ZX Spectrum games
using Manic Miner and Jet Set Willy game engines
Archive of the
Manic Miner & Jet Set Willy Yahoo! Group
messages
|
|
|
|
|
Message: 6280
Author: andrewbroad
Date: 30/09/2007
Subject: Editing diagonal guardians in JSWED
I wrote the following notes to work through the confusion I
experienced when editing JSW64:Z diagonal guardians in JSWED v2.3.1.
There are only four kinds of people in this world: those that promote
confusion, those that restrain confusion, and the confused.
Diagonal guardians (DGs) in JSW128/JSW64 can be thought of as
horizontal guardians with a vertical speed.
The following discussion applies directly to JSW64, and can be
applied to JSW128 by noting that Byte 2 is not edited in the guardian-
class, but the second byte of the guardian-instance (which gets
copied to Byte 2 of the guardian-class at runtime).
The 8 guardian-bytes of a DG are used as follows ('%' denotes binary,
and the capital letters which follow denote the individual bits from
most significant to least significant):
Byte 0: %DUUUTTTT
- %D: initial direction (0 left, 1 right)
- %UUU: unused
- %TTTT: guardian-type (5 for a DG that moves '\', 6 for a DG that
moves '/')
In JSWED's guardian-editor, the "Type" button controls %TTTT, and
the "L/R?" box controls %D.
Byte 1: %AAALBIII
- %AAA: animation-mask (%011 unidirectional, %111 bidirectional)
- %L: lift-flag (if using Broadsoft Lifts: 0 non-lift, 1 lift),
otherwise unused
- %B: BRIGHT
- %III: INK (0 to 7)
In JSWED's guardian-editor, the rightmost "Animation" box controls
%AAA, the colour-selector controls %III, and the "Bright" checkbox
controls %B. JSWED doesn't recognise Broadsoft Lifts, therefore %L
has to be set manually (by clicking the "!" button and adding #10 to
the second byte to convert a non-lift to a lift, or subtracting #10
to convert a lift to a non-lift).
Byte 2: %SSSCCCCC
- %SSS: start-sprite (should always be %000 for DGs)
- %CCCCC: start-column (0 to 31)
In JSWED's guardian-editor, the leftmost "Animation" box controls
%SSS, and %CCCCC is edited by selecting the guardian on the "Guards"
screen and clicking where in the room you want it to start (which
also affects Byte 3). However, JSWED's setting of %CCCCC seems to be
bug-ridden, so the safest way to set %CCCCC is to click "!" and type
the start-column into the third byte.
Byte 3: initial vertical position (in pixels*2: 2 to 224)
In JSWED's guardian-editor, the box immediately to the right of "Y:"
controls Byte 3. The values you see are the actual values of the byte
in pixels*2; values > 224 are allowed, but are invalid because
they're off the bottom of the room.
Byte 4: initial vertical velocity (in pixels*2 per time-frame:
0 stationary, 2 to 126 downwards, -128 to -2 upwards)
In JSWED's guardian-editor, the box to the far right of "Y:" controls
Byte 4. The values you see are the actual values of the byte (treated
as a signed byte) in pixels*2, though bugs occur when you try to
increment a value of 126 or decrement a value of -98.
Byte 5: sprite-page (high byte of sprite-address)
In JSWED's guardian-editor, the "Sprite" button controls Byte 5,
though it only allows you to select from a limited range of sprite-
pages.
Byte 6: %UUULLLLL
- %LLLLL: left-boundary column (0 to 31)
- %UUU: unused
In JSWED's guardian-editor, the leftmost "Bounds" box controls %LLLLL
(it allows you to decrement 0 but not increment 31).
Byte 7: %DTHRRRRR
- %RRRRR: right-boundary column (0 to 31)
- %H: half speed (if 1, then the guardian will only move every other
time-frame horizontally)
- %T: used at runtime
- %D: double speed (if 1, then the guardian will move two steps
horizontally every time-frame)
In JSWED's guardian-editor, the rightmost "Bounds" box controls
%RRRRR, the "Slow" checkbox controls %H, and the "Fast" checkbox
controls %D.
Worked example:
I want a DG that starts at its bottom-left boundary (13,1), and goes
up & right initially until it reaches its top-right boundary (1,13).
It is to move at the normal horizontal speed (2 pixels per time-
frame), and the same speed vertically so that it moves along a
perfect diagonal, like Willy on a ramp.
So I set the Type to "Diagonal NE/SW", and INK 2 and sprite-page #A7
will do for now. I want bidirectional animation, so I set the
rightmost "Animation" box to 7 (%111). So far, my guardian-bytes look
like this (the initial vertical velocity already happens to be what I
want):
#06 E2 0F 80 FC A7 13 1D
I click the "L/R?" box to make it go right initially:
#86 E2 0F 80 FC A7 13 1D
I set the start-column to 1 by manually editing Byte 2:
#86 E2 01 80 FC A7 13 1D
I see this change affecting the guardian visually on the "Guards"
screen, but not in the guardian-editor - no wonder I've been confused!
I set the initial vertical position to cell-row 13 by typing "208"
(13*8*2) into the box immediately to the right of "Y":
#86 E2 01 D0 FC A7 13 1D
I set the left-boundary to 1 by typing it into the leftmost "Bounds"
box, and the right-boundary to 13 by typing it into the
rightmost "Bounds" box:
#86 E2 01 D0 FC A7 01 0D
Then JSWED crashes, so after relaunching it, I simply input the hex
of my guardian. The guardian-editor doesn't render it correctly, but
the "Guards" screen does.
However, it doesn't turn out quite how I expected: its top boundary
turns out to be four pixels too high, causing it to collide with the
scenery. And when coming back down/left, its bottom boundary is four
pixels too low, causing another collision.
After tweaking the boundaries, I arrived at the following guardian:
#86 E2 01 D0 FC A7 02 0C
But it's too fast, so I had to slow down the horizontal component
(set the half-speed flag). And thus halve the vertical speed to
compensate:
#86 E2 01 D0 FE A7 02 2C
JSWED renders the guardian itself correctly - but renders the series
of squares representing the path as though the horizontal speed were
normal.
I then decided to create a symmetrical DG on the other side of the
screen. The easiest way for me to do this is to manually edit Bytes
0,2,6,7 in order to laterally invert the DG:
#05 E2 1D D0 FE A7 11 3C
Byte 0 = #05: it's now going left initially, and the guardian-type is
5 (Diagonal NW/SE)
Byte 2 = #1D: the start-column is now 29
Byte 6 = #11: the left-boundary is now 17
Byte 7 = #3C: the right-boundary is now 28 (and it's still half speed)
Interestingly, this second DG's actual top boundary is a few pixels
higher than the first, its actual bottom boundary a few pixels lower.
Presumably this has to do with the difference in the initial sprite-
frame: in JSW, the initial sprite-frame of a HG is always 0 (the
leftmost sprite-frame) regardless of whether the HG goes left or
right initially.
In summary, the start-column of a DG is best set by manually editing
Byte 2 (the third byte) of the guardian, and I also found it easier
to set the initial vertical position and the left & right boundaries
by calculating the correct values to type into the boxes in the
guardian-editor, than to set them by clicking in the room when this
is buggy.
--
Dr. Andrew Broad
http://geocities.com/andrewbroad/
http://geocities.com/andrewbroad/spectrum/
http://geocities.com/andrewbroad/spectrum/willy/
P.S. What's the deal with global cell-types in JSW64:Z? If I select
one of cell-classes #D, #E or #F in JSWED's room-editor, erroneous
colour-attributes appear when I attempt to set cells in the room to
these classes.
|
|
|