Multicolour guardians in JSW48

[Spider]

Although sometimes difficult to see and only happened rarely (and this is not really that relevant!) when the 'Attic Bug' was in full swing it was occasionally possible to see the Barrel in Top Landing flickering between different colours. :)

[IRF]

Although sometimes difficult to see and only happened rarely (and this is not really that relevant!) when the 'Attic Bug' was in full swing it was occasionally possible to see the Barrel in Top Landing flickering between different colours. :)

 

It probably is relevant!  I find it easier to believe that the Attic Bug caused corruption of the guardian data, leading to the same phenomenon, than that the Attic Bug somehow rewrote the game routines to include JSW128-style colour-changing guardians! :P

[jetsetdanny]

Thanks for all your comments, Ian! :thumbsup:  They are very helpful in understanding the situation.

 

Taking into account the limitations of the game engine - i.e. the fact that in JSW48 I will not be able to create a guardian flickering exactly like the ones in JSW128, what would be as good as it gets for me is as follows:

 

A guardian at the bottom of the screen (vertical position 208) flashing through a constant cycle of white-cyan-magenta-blue in any order, without reversing the cycle and without any interruptions or changes of the cycle.

 

After much trial and error (mostly error! :lol:) I haven't been able to achieve that yet. The closest I have come to it - or rather, the closest of many close ones which I intuitively like the best (without analysing the way they all flicker in detail) is the guardian found in the attached file "MC guardian - quite good.tap".

 

It has the following definition:

 

ef 03 00 d0 00 9e d0 7e

 

It still isn't perfect - after including magenta in the first couple of flashes, it then flashes in three colours only - white, cyan and blue and it has some irregularities in the way it flashes, sometimes it seems to be flashing more quickly than at other times - but it's probably good enough for the purposes of my current project (the exact nature of which will be revealed soon) if I'm not able to create a guardian which would flash with 4 colours in a totally regular way. Three colours are better than two, that's certain ;).

 

If anyone were able to create a better guardian (flashing through four colours rather than 3, but excluding black - or at least flashing through the three "current" colours but in a perfectly regular way) - I would be happy to use it with all due credit given :).

MC guardian - quite good.tap

Edited January 8, 2020 by jetsetdanny

[IRF]

Try either #FD or #FF for the second byte (instead of 03), with all the other bytes as before.

 

(That's purely a guess!)

 

Does your guardian change animation frames, by the way? (I'll try and get a look at in action tomorrow.)

Edited January 8, 2020 by IRF

[jetsetdanny]

The guardian doesn't change animation frames.

 

#FD or #FF are perhaps marginally better, because they seem to make the four-colour flash last longer after entering the room. However, then the guardian reverts to flashing in three colours anyway.

 

The challenge would be to keep it flashing in four colours. It wouldn't actually matter so much if it reversed the cycle or not, flashing in four colours would be better than flashing in three (which is already an improvement over flashing in just two).

[IRF]

Try either #FD or #FF for the second byte (instead of 03), with all the other bytes as before.

 

(That's purely a guess!)

 

Does your guardian change animation frames, by the way? (I'll try and get a look at in action tomorrow.)

 

Okay, I was curious so I just took a look.  (I can see that you used Base sprite 7 so it doesn't animate through different frames.)

 

One of the reasons I investigated this evening was because your description of the colour scheme puzzled me - I couldn't see how it would end up cycling through three colours.  In fact, I think you're mistaken on that - having watched it, it clearly goes through all four 'odd' colours most of the time, but with a brief intermediate phase now and again when it just alternates between blue and cyan (when the 'rope' is swinging through its central equilibrilium point, it swings faster, so you just see two colours), before reverting back to the four colours for several 'cycles', and then the pattern repeats.

 

I tried using #FD or #FF for the second byte, and it ends up much the same as your file, although yours has an initial 4-colour phase where the colours go from 'dark-to-light' (blue->magenta->cyan->white), before settling into a pattern of 'light-to-dark' (white->cyan->magenta->blue) and staying that way.  EDIT: And in yours, the very first pattern is a 2-colour magenta-white phase (just for the first few colour changes) before the 2-colour phase settles on blue-cyan.  So using #FD or #FF is more 'consistent' (always 'light-to-dark' from the offset), but your version (with the second byte = 03) is more interesting and quirky, I would say.  :)

 

 

Incidentally, the test file has a bug whereby if you pause (using the A-G keys) and then unpause it, my emulator crashes and resets!

[IRF]

The guardian doesn't change animation frames.

 

#FD or #FF are perhaps marginally better, because they seem to make the four-colour flash last longer after entering the room. However, then the guardian reverts to flashing in three colours anyway.

 

The challenge would be to keep it flashing in four colours. It wouldn't actually matter so much if it reversed the cycle or not, flashing in four colours would be better than flashing in three (which is already an improvement over flashing in just two).

 

Our posts just crossed!

 

As I explained in my previous post, I think your guardian does cycle through four* colours for most of the time - it just has regular (but brief) periods where it only cycles through two colours.  That's unavoidable since it is behaving like a rope, which speeds up in the mid-point of its oscillations.

 

*I just fixed the pause bug in your test file, freeze-framed through the sequence, and confirmed that four colours (including magenta) are indeed used.

 

P.S. In my earlier analysis, I didn't really go into whether BRIGHT or non-BRIGHT colours are used, but both are at times, it seems.

 

P.P.S. Have you tested whether this guardian 'behaves' in the JSW128 game engine?  (It should do, I think.)

Edited January 8, 2020 by IRF

[jetsetdanny]

Thanks for your involvement in this subject, Ian! :)

 

 

Let's get this question out of the way first:

 

P.P.S. Have you tested whether this guardian 'behaves' in the JSW128 game engine?  (It should do, I think.)

 

No, it's beyond my scope of interest. I am only interested in being able to insert into my current project a guardian that will flash satisfactorily.

 

 

Now as a preamble:

 

Incidentally, the test file has a bug whereby if you pause (using the A-G keys) and then unpause it, my emulator crashes and resets!

 

(...)

 

*I just fixed the pause bug in your test file (...)

 

Thanks. This test file, however, has nothing to do with the project I am working on, it's just a file I created to present the guardian issue outside of the proper project.

 

 

Our posts just crossed!

 

As I explained in my previous post, I think your guardian does cycle through four* colours for most of the time - it just has regular (but brief) periods where it only cycles through two colours.  That's unavoidable since it is behaving like a rope, which speeds up in the mid-point of its oscillations.

 

When I read you saw it cycling through fours colour for most of the time, I thought you were wrong. Then I looked at it and I could see you were right.

 

However, when I looked at the guardian in my proper project, with the values ef 03 00 d0 00 9e d0 7e inserted, I could still see it was, after a short while, flashing in white, cyan and blue only. Definitely no magenta. 

 

I thought I was going crazy.

 

I couldn't understand how it was possible, as I saw no difference between the two files in the guardian definition. Why would the same guardian behave differently in two JSW48 files?

 

Then I realised that the guardian in my proper project was using a sprite from page 9f, not 9e. This was adjusted, so its definition was really ef 03 00 d0 00 9f d0 7e.

 

I checked and yes - it makes a difference! Please find attached a file in which the guardian's sprite page has been changed to 9f.

 

Look at the guardian, please. After a few cycles involving magenta, where the flickering seems slower, the guardian starts flashing faster, in white, cyan and blue only. No magenta whatsoever and it's not coming back at any time AFAICT. And please don't tell me you see magenta there, or I'll really go crazy! ;)

 

Here's the file:

 

MC sprite page 9f - 3 colours only!.tap

 

Now, I was really glad about this, because I thought I would swap the sprites around in my proper project and put the flashing one at 9e instead of 9f and I'll have it flashing in four colours.

 

However, I tried it without swapping the sprites (just using the sprite which already sits at 9e), and it doesn't seem to work, I don't see magenta there after the initial few cycles.

 

Weird, weird, weird...  :unsure:

 

 

[IRF]

In the test file which I looked at last night ('quite good'), the eighth byte (at address #A007) was set to #7F, whereas the one you've just provided that goes through just three colours has the eighth byte set to #7E.  Presumably that's also the case in your 'proper' project?  (Remember, JSWED will try to be 'helpful' and fix certain bytes to even numbers to avoid 'Attic Bug' style corruption - I suspect that may have happened in this case?)

 

So I think using #7F for the eighth byte (setting it that way in the Hex Editor rather than the GUI) should resolve it - that worked when I just tried editing #A007 in your '3 colours only!' test file, so it should work on your 'proper project' as well.  EDIT: Notwithstanding what I said about only using even numbers for the eighth byte, which is not important unless you want a guardian which also (with the same definition) moves normally in JSW128.

 

 

I don't think the chosen sprite page (sixth byte) changes things at all.  (I was completely mystified as to why it should, until I spotted the difference reported above, at which point I was relieved!)

 

 

Now, as to why #7E versus #7F makes a difference requires further investigation by me at some point... I'm still not sure how the 'Move the guardians' routine comes out with three colours, when it's incrementing by either 2 or 4...  The guardian must be hovering around the transition between 'slow-swinging' and 'fast-swinging' rope phases?  EDIT: Yes, I think that's more or less it.

 

 

Oh, by the way:

 

 

Thanks for all your comments, Ian! :thumbsup:  They are very helpful in understanding the situation.

 

I'm glad you made sense of them, despite some rather dodgy 'auto-correct' choices by my Tablet!  ('Direction of swing' got changed to something very odd - I can't remember what now, having edited the original post last night - but it was 'Direction of sewer's or something like that!)

Edited January 8, 2020 by IRF

[jetsetdanny]

My replies are in green below:

 

In the test file which I looked at last night ('quite good'), the eighth byte (at address #A007) was set to #7F, whereas the one you've just provided that goes through just three colours has the eighth byte set to #7E.  Presumably that's also the case in your 'proper' project?  (Remember, JSWED will try to be 'helpful' and fix certain bytes to even numbers to avoid 'Attic Bug' style corruption - I suspect that may have happened in this case?)

 

So I think using #7F for the eighth byte (setting it that way in the Hex Editor rather than the GUI) should resolve it - that worked when I just tried editing #A007 in your '3 colours only!' test file, so it should work on your 'proper project' as well.  EDIT: Notwithstanding what I said about only using even numbers for the eighth byte, which is not important unless you want a guardian which also (with the same definition) moves normally in JSW128.

 

Thanks for spotting the difference and thus determining what the problem was, Ian! Indeed changing the value of the last byte to #7F in my "proper project" did the trick - the guardian is now flashing in 4 colours! I also changed the value of the second byte from #03 to #FF - I'm not quite sure what the difference is, but I *think* the flashing is more regular, at least in the first few seconds.

 

To sum up, your assistance has allowed me to achieve what I wanted, i.e. that the guardian in the JSW48 game engine not be too different from the one in the JSW128 engine. I mean, it is different, but flashing in four colours is much closer to the original guardian flashing in 5 colours in JSW128 - it's a definite improvement over the two-colours-only cycle I was initially facing - thank you! :)

 

 

I'm glad you made sense of them, despite some rather dodgy 'auto-correct' choices by my Tablet!  ('Direction of swing' got changed to something very odd - I can't remember what now, having edited the original post last night - but it was 'Direction of sewer's or something like that!)

 

Sewers are a very legitimate JSW subject! :) They have appeared in various games. The rooms that come to my mind immediately are: Paul Equinox Collins's room "The Sewer" from his unfinished "JSW '96 Remix" which found its place, as room 079, in "JSW: The 2010 Megamix", as well as the rooms in The Megamix I designed using Paul's excellent graphics: "Entrance to the Sewer" (076) and "Below the Bathroom" (075).