Multicolour guardians in JSW48

[jetsetdanny]

John Elliott's JSWED's manual states (starting at the bottom of page 22) that "In JSW48, there are four guardian types - horizontal, vertical, arrow and rope. In JSW128 there are ten; the four mentioned earlier, two diagonal types, and ?ashing versions of all except the arrow and the rope."

 

The "flashing" versions are called "multicolour" in JSWED itself, e.g. in JSW128 games when choosing the guardian type you can choose "Vertical multicolour", "Horizontal multicolour", "NW/SE multicolour" and "NE/SW multicolour" (the latter two being diagonal ones, of course).

 

Judging by the description in SkoolKid's disassembly, it looks to me like bits 0-2 in the first byte of the 8-bit-long definition of each guardian class define what type of guardian it is (please correct me if I'm wrong on this). In practical terms, it looks to me that vertical multicolour guardians have #07 in the first byte of their definition (again, please correct me if this is not entirely accurate).

 

Please find attached two experimental files. The first one, "MC guardian 128K.tap", features a stationary (unmoving) multicolour vertical guardian in a JSW128 game file.

 

The second file, "MC guardian 48K.tap", features the same guardian copied to a JSW48 game file.

 

Even though there are no multicolour guardians in the JSW48 game engine, as per the JSWED manual, this guardian is still multicolour, or, to be precise, bicolour. If flickers in white and magenta only, which makes the way it flickers (glints? glitters? glows? shimmers? - I'm not sure what verb is best here) less elegant than in the case of the same guardian in the JSW128K game file: the flickering is much faster and less colourful in JSW48 than in JSW128; it does not look as good.

 

In the JSW128 game file the same guardian flickers in five colours: red, magenta, green, cyan and  yellow. Its flickering is much nicer to the eye than in the JSW48 game engine (although I suspect that if white and blue were added to the cycle, it would be even better).

 

The question I have is this:

 

Would it be possible to tweak the JSW48 game engine easily (like changing a couple of bytes or adding a little bit of some additional code, I'm not talking about any serious rewriting of the engine) to make this stationary bicolour guardian multicolour, i.e. to make it flicker at least in the five colours that it flickers in in the JSW128 game engine?

 

I only need it to flicker in a nicer way, I don't need it to move.

 

Any help on this would be appreciated :).

MC guardian 48K.tap

MC guardian 128K.tap

Edited January 6, 2020 by jetsetdanny

[IRF]

Based on the description, it sounds similar to the colour-changing barrels that can be found half way up the West Wall in 'Jet Set Mini', which are considered to be ropes by the 'Move the guardians' routine, but drawn as guardians (with fatal collisions with Willy, etc) by the 'Draw the guardians' routine.

In the JSW48 engine, the former routine only picks up bits 0-1 of the first byte, whereas the latter routine picks up bits 0-2 (compare the commands at #90CA and #91CB), so if you try to create a JSW128-style guardian in JSW48, by using bit 2 of the first byte, then the game treats it differently when it comes to moving the guardian versus drawing it!

I believe it should be possible to get your guardian to display a wider 'colour scheme' without making ANY changes to the JSW48 game engine, but by fiddling around with the guardian definition bytes instead.  EDIT: In four different colours (either all the odd colours Blue/Magenta/Cyan/White, or all the even colours Black/Red/Green/Yellow), not five as you requested.

Edited January 6, 2020 by IRF

[IRF]

Further to my previous post:

 

I haven't had chance to check out the test files you uploaded yet, but I would guess that the guardian is located quite high up on the screen in which it appears (i.e. it has a low value for its y-coordinate)? And I would also guess that you have the 'default' colour of the guardian (i.e. bits 0-2 of the second definition byte) set to white (or magenta)?

 

Anyway, if you try changing the maximum y-coordinate (the eighth guardian definition byte) to a high value (N.B. this shouldn't affect the placement or static nature of the guardian in either mode, and nor should it affect the appearance/colour sequence of the guardian in JSW128 mode, provided that the guardian's vertical speed [fifth definition byte] is set at zero), then in JSW48 mode, the colour-cycling should go through four colours at times (namely the four 'odd' colours).

 

And if you also reset bit 0 of the second definition byte (i.e. choose one of the 'even' colours as its default colour), then the JSW48 incarnation of the guardian will cycle through the other four colours (again, without affecting the guardian's appearance in the JSW128 engine file).

 

EDIT: In the above, when I referred to the aopearance/placement of the guardian being unaffected, I mean in-game. (When viewed in JSWED's GUI, that might not appear to be the case).

Edited January 6, 2020 by IRF

[jetsetdanny]

Thanks for your prompt response, Ian! :)

 

My replies to some of your points are in green below: 

 

Further to my previous post:

I haven't had chance to check out the test files you uploaded yet, but I would guess that the guardian is located quite high up on the screen in which it appears (i.e. it has a low value for its y-coordinate)?

 

No, actually it's at the very bottom of the screen  :o .

 

 

And I would also guess that you have the 'default' colour of the guardian (i.e. bits 0-2 of the second definition byte) set to white (or magenta)?

 

I've no idea what they are. I don't understand how one can work on the bits of a byte - I know the value of a byte (e.g. the second definition byte in case of this guardian is #05), but how can I know what the bit values are?

 

Oh, if it has something to do with the binary perhaps, the binary value of #05 is 0000 0101.

 

Anyway, if you try changing the maximum y-coordinate (the eighth guardian definition byte) to a high value (N.B. this shouldn't affect the placement or static nature of the guardian in either mode, and nor should it affect the appearance/colour sequence of the guardian in JSW128 mode, provided that the guardian's vertical speed [fifth definition byte] is set at zero), then in JSW48 mode, the colour-cycling should go through four colours at times (namely the four 'odd' colours).

 

The eighth guardian definition byte's value is #D0, so it's quite high already. I tried changing it to #FF, but this didn't produce any visible changes as far as I could tell.

 

 

And if you also reset bit 0 of the second definition byte (i.e. choose one of the 'even' colours as its default colour), then the JSW48 incarnation of the guardian will cycle through the other four colours (again, without affecting the guardian's appearance in the JSW128 engine file).

 

I don't know how to do it, but again, I suspect it may be related to the binary value. I'll experiment a little bit and get back to you :) .

[IRF]

Try experimenting with different values for the eighth (last) definition byte.  You're trying to replicate the rope being 'far out' in its swing, where it is being incremented by 2 (as opposed to being stuck near the central/fastest bit of the swing trajectory, when it is being incremented by 4, so you only get two colours when it is drawn.

EDIT: You should probably select a multiple of 4 (i.e. the byte ends in either 0, 4, 8 or C), otherwise the position of the 'rope' will never match its outer limit and so won't 'turn around' to swing back again (which is manifested, in this case, in the pattern of colours being reversed).

 

Regarding setting/resetting bit 0 of byte 1 (i.e. to switch between the 'odd' and the 'even' colour palettes), the easiest way is just to change the guardian's colour in JSWED's GUI.

Edited January 7, 2020 by IRF

[jetsetdanny]

I am writing this as I'm experimenting with the last (eighth) byte of the guardian's definition:

 

value 00 - first cycles through blue, magenta, cyan and white various times, then flickers irregularly a couple of times and then starts flickering in magenta and white only!

 

value 01 - can't be set in JSWED's GUI. When you set it manually in JSWED's GUI, it reverts to 00.

 

value 02 - flashes in white and magenta only

 

value 03 - can't be set in JSWED's GUI. When you set it manually in JSWED's GUI, it reverts to 02.

 

value 04 -  flashes in white and magenta only

 

value 05 -  can't be set in JSWED's GUI. When you set it manually in JSWED's GUI, it reverts to 05.

 

value 06 - value 04 -  flashes in white and magenta only

 

value 07 (skipping, I'm sure it would revert to 06)

 

value 08 -  flashes in white and magenta only

 

value 0a - flashes in white and magenta only

 

value 80 - flashes in white and magenta only

 

I don't think any higher values would yield any different results, especially that the original value #D0 is a multiple of four (208 in decimal) and it doesn't do anything else but flicker in white and magenta.

 

 

Now:

 

value 01 (inserted in JSWED's Hex Editor, not GUI) - first cycles through blue, magenta, cyan and white various times, then flickers irregularly a couple of times and then starts flickering in magenta and white only! - so it has the same behaviour as value 00.

 

So values 00 or 01 would be best for my purposes if they maintained cycling through the four colours - blue, magenta, cyan and white - but they stop after a while and revert to flashing in white and magenta only!

 

Weird, weird, weird...  :unsure:

[jetsetdanny]

Regarding setting/resetting bit 0 of byte 1 (i.e. to switch between the 'odd' and the 'even' colour palettes), the easiest way is just to change the guardian's colour in JSWED's GUI.

 

 

Changing the guardian's colour to red (02) makes it flash in red and yellow. Still only two colours, while I'm looking for five, like in JSW128.

 

The guardian's full definition in this case:

 

07 02 00 d0 00 9e d0 d0

[jetsetdanny]

Based on the description, it sounds similar to the colour-changing barrels that can be found half way up the West Wall in 'Jet Set Mini', which are considered to be ropes by the 'Move the guardians' routine, but drawn as guardians (with fatal collisions with Willy, etc) by the 'Draw the guardians' routine.

 

The colour-changing barrels half way up the West Wall in 'Jet Set Mini' have the following definition:

 

ef fe 00 c0 02 9c 9c 7e

 

They seem to be flashing in the following colours: black, red, green, yellow, BRIGHT red, BRIGHT green and BRIGHT yellow, although I can't establish the exact cycle right now.

 

I will have to experiment, then, since what I'm trying to obtain is something as similar to what JSW128 does - i.e. the cycle of red, magenta, green, cyan and  yellow - as possible.

[IRF]

JSWED's GUI won't let you input odd numbers for the eighth byte, because it thinks you're inputting a y-coordinate, and the y-coordinates work in increments of 2 (they look up pairs of values from a look-up table). Incidentally, the 'Attic Bug' arises from an odd value being used for an arrow's y-coordinate.

 

You should(?) be able to replicate what the flashing barrel in the West Wall of 'Jet Set Mini' does - including the fact that the 'direction of swing' periodically reverses, causing the sequence of colours on display to flip around - but using the four 'odd' colours, by manually setting an odd value for the eighth Byte and then playing around with the other bytes.

 

You won't achieve the same pattern of colours as the JSW128 colour-changing guardians, because that involves a mixture of 'odd' and 'even' colours. The rope-moving routine only ever increments the second byte's value by 2 or 4.

EDIT: Bit 0 (the lowest bit) determines whether a number is odd or even, adding 2 or 4 (00000010 or 00000100) leaves the status of bit 0 unchanged (as you'd expect based on your intuitive understanding of the decimal system).

Edited January 8, 2020 by IRF

[IRF]

You should(?) be able to replicate what the flashing barrel in the West Wall of 'Jet Set Mini' does - including the fact that the 'direction of swing' periodically reverses, causing the sequence of colours on display to flip around - but using the four 'odd' colours, by manually setting an odd value for the eighth Byte and then playing around with the other bytes.

On second thoughts, it might not be possible to get a guardian which replicates the exact cycle of colours of the barrel, but using Blue/Magenta/Cyan/White - the actual y-coordinate (fourth byte) has to be an even number for the guardian-drawing routine to draw it safely (without an Attic Bug-style incident!), and so it will never match the eighth byte (extremity of swing when it is being 'moved' as if it were a rope) if that is assigned an odd value, and so it will always end up swinging in the same direction, I think (so the order of colours displayed will never go into reverse).

 

 

EDIT: I've just remembered another factor to consider - the eighth byte needs to hold a value less than #80 (so #7E is the highest practical value, as per the barrels in 'Jet Set Mini', given that it also needs to be an even number), in order for the 'rope' to turn around. That's because the command at #9120 resets bit 7 of the second byte before it compares it with the eighth byte. So keep bit 7 of the eighth byte clear IF you want the colour sequence to reverse periodically.

FURTHER EDIT: Looking at your earlier trials, it seems that you didn't try a large value for the eighth byte other than ones which exceeded #80. And all the values you tried were in the range of a 'narrow/fast swinging' rope (incrementing by 4 at a time); the animation frame has to get past #12 (or it might be #14 - see #90F7 and similar commands) before it starts swinging more slowly/incrementing by 2. So ironically, at #0A, you may have stopped just a few increments short of a value that would have yielded more positive results!

Anyway, try #7E for the eighth byte. (Note that it will still go through a phase of alternating between just two colours, before it resumes cycling through four, as it passes through the 'near-vertical' position in its 'swing'.)

 

ANOTHER EDIT: The upper three bits of the second guardian definition byte determine the animation mask. The 'rope-like' behaviour might interfere with that, causing the guardian to stop and start animating through different sprite-frames. (That isn't an issue with the 'Jet Set Mini' barrel, as it only has one frame of animation, and I think from memory the barrel bitmap occupies the last 'slot' on the sprite page, with the 'base sprite' set to 7 in the third byte [via the guardian specification byte in the room definition, which also specifies the x-coordinate], thus 'overriding' the animation mask. N.B. I still haven't had chance to see your guardian 'in the flesh', so I don't yet know whether it is animated, or if is meant to animate?)

 

 

However, none of the above should affect your ability to place the guardian wherever you want on the screen (via the third and fourth definition bytes), since your guardian is non-moving. i.e. the fifth byte, which determines the speed, is set to zero. (N.B. My barrels appear to have a speed setting of 02; I'm not sure why I didn't set that fifth byte to zero - if you transposed the barrels into JSW128 they would probably start moving instead of changing colour! If you want the same guardian definition to be non-moving in both game engines then leave the fifth byte set to 00.)

Edited January 8, 2020 by IRF