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: 5700
Author: andrewbroad
Date: 11/03/2006
Subject: JSWED 2.3.1: Andrew's comments (Chapters 14 to 17)
This follows on from Message 5695.
This message represents my first-ever foray into Chapters 14 to 17
of the JSWED manual! I have also studied Appendix A to round off my
JSW64 lesson. I am using JSWED v2.3.1, but with a printout of the
jswed.pdf from v2.3.0.
(This message is long, but not everyone needs to bother with
Appendix A.)
#####################
Part III: JSW64 games
#####################
14 Guardians
============--------
14.1 Guardian editor
--------------------
> There are two "Animation" fields. The left-hand one is the start-and the right-hand one is the animation-mask. To quote from Arsen
> frame of the guardian.
Torbarina's JSW Tech Page in my own terminology (/frame/ being a
single pixel-pattern, and /sprite/ being an animated set of frames):
>>>Technically, the frame-number to be displayed cycles constantly from
0 to 7 (%111), and is modified before drawing by ANDing with the
animation-mask and ORing with the start-frame.
Animation-mask 0 (%000) gives no animation: only a single frame is
used (e.g. the barrel).
Animation-mask 1 (%001) gives 2-frame animation (e.g. the jelly).
Animation-mask 2 (%010) gives slow animation using only the even-
numbered frames 0 and 2.
Animation-mask 3 (%011) gives 4-frame animation (eg. the sponge in
The Bathroom).
Adding 4 to the animation-mask for a horizontal guardian gives
bidirectional animation. The left-facing frames are in Frames 0-3,
and the right-facing ones in 4-7, so a 2-frame bidirectional
guardian with start-frame 2 would use Frames 2, 3, 6 and 7.
For vertical guardians, adding 4 just increases the number of frames
used.
<<<
Good advice: To avoid jerky movement, a bidirectional HG should
always have a start-frame of 0 and an animation-mask of 7 (%111). A
unidirectional HG should always have an animation-mask of 3 (%011),
while its start-frame should be either 0 or 4.
Arrows: Although JSWED allows you to edit the ink-colour and middle
pixel-row, they are always displayed as white and %11111111 in the
room-view and in the Guardians panel.
> Extra guardian types are supported: Skylabs, Angry Eugenes,and Stoppers.
> Triggers, Switches and Vanishing Walls.
14.1.1 Skylabs
--------------
> However, these Skylabs can also go up. If so, the first bound isI'm having trouble constructing a Skylab that goes up. The best I've
> the bottom bound and the second bound is the top (the other way
> round from all other vertical guardians).
managed so far is:
Hex: 08 09 02 30 04 9B 30 00 (in JSW64:X, Ballroom West)
which stays at its bottom boundary for one time-frame, then skips to
its top boundary for the other seven. If I swap the bounds or give
it a negative velocity, it goes up off the top of the screen and
kills you.
I also experienced a JSWED crash when exiting the guardian-editor
after editing a Skylab, and again when right-clicking in the Guards
screen (which has happened more than once after exiting the guardian-
editor - specifically after editing the bounds).
Editing a Skylab's "Animation" appears to have no effect. Is it
possible to change a Skylab's start-frame, or must this always be
Frame 0 of the sprite-page?
It would also be nice to be able to edit a Skylab's horizontal
displacement (including negative values for Skylabs that go left,
and 0 for droplets).
I know that the displacement is a global datum (at 0:#FF61), but
perhaps JSWED could be clever enough to daisy-chain the room's setup
patch-vector to poke in a non-standard displacement, should the
author wish to set this by room.
14.1.2 Angry Eugenes
--------------------
> There are three Eugene types - normal, multicolour, andWhen I tried one of type "Angry Eugene multiclr", it appeared to be
> multicolour 2. The second multicolour option exactly duplicates
> the way Manic Miner does a multicoloured Eugene; it will only
> work in a room with a limited air supply.
colour-cycling in JSWED, but just appeared white in the game - until
I added a limited air-supply. So it appears that the /first/
multicolour option is the one that duplicates MM (Guardian-type #28
according to Section A.4).
When changing the Type of a guardian from vertical to an angry
Eugene, or between different angry Eugene types, some of the data
get set to default values instead of being carried over from the
guardian it was before.
(Also, the guardian-type is not updated in the Guardians panel until
you refresh the room.)
It would be cool if these guardian-types could have an option to
leave a trail of deadly pixels as in JSW II's "The Foot Room" (I
guess the trail would have to be redrawn every time-frame in order
to detect pixel-collision).
14.1.3 Triggers
---------------
What a fantastic innovation!
This section would be better presented after the current Section
14.1.5, so that we can learn about switches and vanishing walls
first.
It should be possible to insert a trigger - or any guardian for that
matter - at any position in the guardian-list, not just after the
last guardian.
> Effect brings up another guardian editor, in which you can decideSo the user is expected to know which controls in the guardian-
> exactly what will happen when the trigger takes effect. The
> trigger can only change bytes 0 and 4-7 of a guardian, so you
> can't change position, colour or animation settings.
editor correspond to which Guardian-offsets in Section A.4? Yuck.
Effects have a nasty to tendency to disappear after setting them,
resulting in a blank guardian, and a need to set the Effect-data
again. I haven't got to the bottom of when this happens and when it
doesn't, but I'm pretty sure it wasn't that I clicked Cancel instead
of OK.
When the Source is "An angry Eugene stopping", does this refer to a
particular guardian, or /any/ angry Eugene in the room? I ask
because my test-room contains the following guardians:
0: Trigger (Source: items; Effect: VG)
1: Angry Eugene #28
2: Trigger (Source: items; Effect: another Angry Eugene #28)
3: another VG
4: Trigger (Source: Eugene; Effect: HG)
5: HG
The trigger at Guardian 4 is to move the HG's bounds out of the way
of the Angry Eugene created by Guardian 2, but if I reenter the room
after collecting the items, the HG collides with that Angry Eugene!
I now see that the answer is: "Eugene" in the "Triggered by" panel
refers to a particular guardian, but JSWED doesn't recognise Eugenes
that are created by triggers, and therefore only offers Guardian 1
as an option in the above example.
It would have been much clearer if JSWED gave the guardian-numbers
next to Eugenes, switches and vanishing walls in the "Triggered by"
panel.
> If you save a game with a trigger at the end of the list, then theI tried that, and I didn't notice anything happen when the trigger
> game will probably crash when the trigger is activated.
was activated.
If a trigger's Source already obtains on entering the room, the
Effect doesn't kick in until the second time-frame. The worst-case
scenario would be infinite death (e.g. a trigger removes a guardian
that blocks a room-exit, then you go back into that room).
14.1.4 Switches
---------------
The "Animation" control should be renamed "Start-frame", since it
doesn't include an animation-mask; the same goes for Angry Eugenes.
I don't like seeing "On/Off?" as a tickbox - I get confused over
whether a tick means "on" or "off" (answer: a tick means "on").
In the room-view, switches should be drawn according to whether
they're initially "on" or "off" (currently they're always
drawn "off", which is pretty confusing in my test-room of three
switches).
I don't like the way switches are only drawn down to the pixel-row
at which collision is detected (that subroutine ought to be modified
not to return immediately on detecting collision, but to set a flag
and finish drawing the frame).
Collision-detection for switches should be colour-based (or perhaps
position-based) rather than pixel-based anyway, giving them the
illusion of being cells as they are in MM.
What's the point of being able to turn a switch off if this doesn't
reverse the effect of switch-based triggers, which can only react to
switches being on? (Answer: patch-vectors?)
Another issue is whether switches should be reset to their initial
state when reentering the room, or whether the state of a switch
should be global and permanent like the Trip Switch in JSW II.
14.1.5 Vanishing Walls
----------------------
> It is possible to use a vanishing wall as a delay system, by"on top of" -> "in" (unless you mean that its vertical position is
> putting it on top of air cells.
higher)
When setting a vanishing wall's position, you can't move the cursor
into column 31, although you can click in that column.
A vanishing wall can be its own Source. It makes no sense for JSWED
to allow this.
Ordering the guardian-instance list
-----------------------------------
Even in JSW48/128, the order of the guardian-instance list does
matter: a rope should come after all the horizontal and vertical
guardians, and arrows should come after everything else. JSW CK
allows you to insert a guardian-instance at any place in the list.
JSWED does allow you to cut or copy a guardian and paste it into an
earlier slot in the guardian-list, but this overwrites the guardian
at that slot instead of shunting it and the following guardians
forward. So you have to do a lot of manual copying and pasting to
shunt up to 15 guardians forward in the list.
I would like to see an additional option "Insert" in the Guardian
context-menu (in JSW48/128/64), which inserts a guardian-instance in
the slot currently highlighted in cyan, after shunting the guardian
in that slot and all following slots forward.
I would also like to see an option "Swap" to swap two entries in the
guardian-instance list, and an option "Correct order" to ensure that
ropes come after all the HGs and VGs, and that arrows come after
everything else (with the appropriate extensions to this ordering
for JSW128/64 guardian-types).
There's a very nasty bug in JSWED where if you paste a guardian-
instance after a "--" slot (because you want to insert a trigger and
a stopper, so you shunt some guardians forward two places), it gets
deleted, AND YOU DON'T SEE THAT IT'S GONE UNTIL YOU REFRESH THE
ROOM, BY WHICH TIME YOU MIGHT WELL HAVE PRESSED F2!! :-||
-------------------
14.2 Guardian table
-------------------
How many bytes to a cell in the memory-map? Eight?
> If you change the size or position of a room's guardian table,I take it the address increases from left to right? Then why not
> cross-references in triggers and opening walls will become
> incorrect and must be set up again.
grow the guardian-list/table upwards, keeping the start-address the
same?
Otherwise, JSWED should automatically fix the cross-references.
==================
15 Teleport editor
==================
The user should see the visual effects as tickboxes rather than
options in a menu, in order to be able to check the current setting
(and even more importantly, be able to check the destination of the
teleporter).
The manual needs to state explicitly that the visual effect is a
global setting (with an on-screen hint too) - without prior
knowledge or careful reading, the user may well assume it's per
teleporter.
JSWED should allow the user to set a teleporter's row by pixel, as
the teleporter-format allows.
How does the user know how many portals (s)he can add before memory
runs out, and what does JSWED do when it does?
=================================
16 Start position / Portal editor
=================================
Another vital aspect of the feature-comparison is that a portal's
destination sets Willy's row and column, whereas a teleporter's
destination only sets the room.
But the teleporter-patch could be extended to set a new row and
column at the expense of two extra bytes per teleporter.
In fact, if we take advantage of the fact that JSW64 has only 64 or
128 rooms (requiring only 6 or 7 bits to specify a room-number),
these extended teleporters could still fit in 4 bytes each with the
following compacted format (at the expense of being able to specify
a teleporter's row in pixels):
Offset 0: teleporter's position (room in Bits 6:0, MSb of cell-row
in Bit 7).
Offset 1: teleporter's position (lower 3 bits of cell-row in Bits
7:5, column in Bits 4:0).
Offset 2: teleporter's destination (room in Bits 6:0, MSb of cell-
row in Bit 7).
Offset 3: teleporter's destination (lower 3 bits of cell-row in Bits
7:5, column in Bits 4:0).
The feature-comparison should also mention that the visual effect is
global for teleporters, but per room for portals, and that you can't
have a portal with the air running down but without the screen
turning blue.
Multiple portals per room could be simulated with a teleporter and
two switches (or four cells) each (though you couldn't force the
player to collect items first).
This is pretty much the way I plan to do almost all the room-
connections in Advanced MM/JSW Trainer: the thing-like-a-portal-
sprite will give a visual clue to its destination (the Earth-cells
trainer, the Fire-cells trainer, &c.).
In the Portals screen, you should be able to click in "Portal
attributes" rather than having to press I, P, B or F to edit the
colour-attribute.
The Undo-keys should be applicable here.
The keypresses in the manual should be grouped by function rather
than sorted alphabetically (here and in Section 9.6).
====================
17 JSW64 Good advice
====================
> If Willy stands on a trampoline in a room with Superjump turnedWow - a new quirky feature! :-) I would have thought one single jump
> on, he will shoot straight up until he either:
> 1. Arrives in the room above;
> 2. Loses a life;
> 3. Hits something solid.
would be induced in this situation.
> Make sure the Solar Power beam doesn't go off the screen, or theThis belongs in the "MM Good advice" chapter too, of course - not
> game engine will crash. Block it with Earth if necessary.
that it exists yet (it could also include things like items in
Crumbly cells, VGs killing you if they collide with an item, and
various points from my Manic Miner Room-Format).
> Unlike in JSW48 and JSW128, you can't combine the behaviour ofThe term "colour-attribute" is much more lay-user-friendly, not to
> different cells by setting them to the same attribute.
mention accurate (cf. "item"/"object").
====================================
A JSW64 for machine-code programmers
====================================
http://www.seasip.demon.co.uk/Jsw/jsw64room.html could do with being
updated to reflect the changes in the manual, and vice versa.
----------------------
A.1 JSW64 Room Formats
----------------------
The URL of my Manic Miner Room-Format runs off the edge of the page -
that's LaTeX for you! ;-)
The subsections of A.1 need to iron out the use of both "cell"
and "cell type" to mean /cell-class/.
A.1.4 Bytes #B5-#FF (all formats)
---------------------------------
#B6-FF
> 3: Screen buffer 1(Bank 7 at #E2FF)
> 4: Screen buffer 2(Bank 7 at #EBFF)
> If you want a harmless solar beam, you'll have to set the room notOr use a patch-vector.
> to limit air supply.
This could do with a mention in Chapter 17.
--------------------------------------
A.2 Cell Types Table (formats W, Y, Z)
--------------------------------------
Cell-Classes Table (ditto re. A.3)
"10 Trap" has been added to the v2.2.9 manual, but not to the v2.3.0
manual or the web-page.
-------------------
A.4 JSW64 Guardians
-------------------
> I refer to them as GB0-GB7.Except that you usually refer to them as bytes 0-7 in this very
section! ;-)
The web-page has the following guardian-types that aren't in the
manual:
#B8: Stopper. Guardians after this one don't move or get drawn.
#C8: Stopper. Guardians after this one don't move but do get drawn.
And I know there are experimental guardian-types such as #58 (Lift)
and #78 (Droplet), not currently supported by JSWED. And #68 and #D8
(what are these?), as mentioned in Section A.6.
Another addition from the web-page:
"Diagonal 1 and 2 are similar; the difference is that if all the
other bytes are the same, one goes down when moving left, and the
other goes down when moving right."
A.4.1 Horizontal and Diagonal Guardians
---------------------------------------
> Guardian will be animated twice per frame.time-frame (to avoid confusion with sprite-frame)
-----------------
A.5 Patch Vectors
-----------------
If a room has a setup-vector, it could do with another patch-vector
that is called when leaving the room (whether in the conventional
way, or via a teleporter or portal).
This exit-vector would undo any patches that the setup-vector made
to the game-engine (e.g. the displacement of a Skylab, or undoing
any of the usual JSW pokes that the author may wish to apply on a
room-by-room basis).
I would rather have an exit-vector than the portal-vector.
A.5.1 Patch Vector Jumpblock
----------------------------
> If more entries are added, they will go at #86B2The web-page wrongly says 86AFh instead of #86B2.
--------------------------
A.6 Guardian Patch Vectors
--------------------------
> The "Droplet" patch defines #78.Shouldn't this be available on the Game screen for JSW64 then, if
not supported by JSWED as a standard JSW64 guardian-type?
--------------
A.7 Memory Map
--------------
> #8553: Number of objectsitems
> #8D33-#8D52: Runtime cell type table"cell type" -> "cell-class" (x2)
> #C000-#C0FF: In formats V and W, contains object locations"item-locations" (specifically room-numbers - that's what I had to
know to write SPECSAISIE ItemsJSW128)
The web-page has a section "Bugs and Possible Future Enhancements"
which is not in the manual, but does not have the contents of
Sections A.6 and A.7.
--
Dr. Andrew Broad
http://www.geocities.com/andrewbroad/
http://www.geocities.com/andrewbroad/spectrum/
http://www.geocities.com/andrewbroad/spectrum/willy/
|
|
|