Multicolour guardians in JSW48

[Spider]

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

I was not able to duplicate this despite a few attempts. I even tried a few manual pokes to it while the 'destruction' was in progress! :) I did end up with a flickering white guardian though but I suspect it may of been due to skipping animation frames. I remembered to save a .z80 of it!

[IRF]

My replies are in green below:

 

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.

 

That would bypass the initial phase, taking the guardian straight into its 'settled phase'.  To quote myself last night: "I tried using #FD or #FF for the second byte, and it ends up much the same as your file, although yours has an early 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. 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."

 

I actually think it would show much more interesting and quirky behaviour if you revert back to a value of #03 for the second byte.  (In my humble opinion. :) )

 

EDIT: Actually I would go further (and be less humble in the process! :P )  The fact that you chanced upon the value #7F for the eighth byte by accident, and you happened to choose #03 for the second byte, means that you inadvertently came up with the most convoluted pattern of colours it is possible to achieve via this method (which is itself based upon an unintended oddity of Matthew's original game engine)!  I think serendipity suggests that you should go for a starting value of #03 for the second byte!

Edited January 8, 2020 by IRF

[jetsetdanny]

I actually think it would show much more interesting and quirky behaviour if you revert back to a value of #03 for the second byte.  (In my humble opinion. :) )

 

EDIT: Actually I would go further (and be less humble in the process! :P )  The fact that you chanced upon the value #7F for the eighth byte by accident, and you happened to choose #03 for the second byte, means that you inadvertently came up with the most convoluted pattern of colours it is possible to achieve via this method (which is itself based upon an unintended oddity of Matthew's original game engine)!  I think serendipity suggests that you should go for a starting value of #03 for the second byte!

 

Ian, I will make a note of this inadvertent discovery and will try to remember to place such a guardian in some future game project :).

 

However, for the current one (the nature of which will be revealed soon, I know this assertion is probably becoming boring at this point ;) ), the only thing that is important is that the flashing/flickering be as close to the one in JSW128 game engine as possible.

 

The flickering in the JSW128 game engine is regular, there are no changes to it. It happens in the same way all the time, at least that's the impression I have without really analysing it frame by frame.

 

Therefore, a solution that is more regular is closer to what happens in JSW128 than a solution which has more irregularities in the flashing cycle, no matter how attractive, quirky or inventive that other solution may be. 

 

And whichever solution is closer to JSW128 has to be chosen for this project.

 

Nevertheless, as I said at the beginning, there will be future opportunities to apply this discovery, hopefully :) . 

Edited January 8, 2020 by jetsetdanny

[IRF]

No worries! I might use the 'initially different' one myself at some point. ?

Yes, the JSW128 cycling is indeed regular, you're right about that.

I look forward to your 'big Saddam's regarding your current project!
EDIT: Hah! That was supposed to say "big reveal"!

Edited January 8, 2020 by IRF

[Spider]

Not important but here is a snapshot of the 'fun' I had:

 

flicker_white.z80

 

I could not reliably save it out as a tap as it either errored out with no memory or crashed if you tried to cheat via starting with 32762 instead. I could work around it but it seems a lot of work for no reason! :lol:

 

Fixed. It had eaten part of the startup code, specifically things after the LD SP , manually adding three pokes to fix to loader:

 

33797 , 195

33798 , 202

33799 , 135 ; JP 34762

 

Attached is a .tzx , interesting to of noted (from the .z80 above) the low end of the memory where the game variables live is quite heavily populated, more than I would of expected.

 

Pic loading screen ( sorry! but I'm more sorry for the Basic in the loader itself :blush: check it out! ) and functional-ish tape:

 

 

flicker_white.tzx

 

Note starting room from this is still Attic, but you'll likely have to writetyper your way out of various scenario's as its got quite bad!

[IRF]

Danny, you may be interested (or may not!) in a useful tool which I came up with earlier - see the attached file.

 

It's a test file based on your 'MC guardian - quite good' file, with a minor modification.  What it does is, at the start of every pass through the Main Loop, it prints the current value of the second byte of the guardian definition (for the single guardian in the only populated/accessible room in the test file that you created), across a range of addresses starting at #9C00.

 

After printing a value (in the first instance at the address #9C00), it increments the IY index register (which is used to keep track - chosen because the IY register isn't used in the JSW game engine [except when drawing ropes, but there are no ropes present in this game file]).  So during the second pass through the Main Loop, the next value for the guardian's second byte is printed at #9C01, etc.

 

By running this program in an emulator for a while, then saving a snapshot after you've observed a good number of cycles of the guardian's colour changes, and then opening up the game file in JSWED and observing the addresses from #9C00 onwards in the Hex Editor, it enables you to study the sequence of values for the 'pseudo-rope guardian's second byte (which are generated as values for the rope animation index by the 'Move the guardians' routine, but then interpreted as a guardian colour attribute by the 'Draw the guardians' routine).  The lower nybble* of each stored value correlates with the BRIGHTness [bit 3] and the INK colour [bits 0-2] of the guardian at each point in time.

 

* (i.e. the 'units digit' if we were talking in terms of decimal numbers.  If you see a number like #F3, then the lower nibble is 3; the upper nibble is F.)

 

You can then play around with the definition bytes for the guardian (stored at #A000-#A007), as we were doing earlier yesterday, and then by running the file and saving snapshots, you can see a numerical interpretation of the different colour schemes on display.  (And then for added 'fun', study the routine at #90C0 and see how the commands determining how a rope is moved are reflected in the pattern of colours that you can see.)

 

N.B. If you leave the attached game file running for more than a minute or so (in real world time!), then the sequence of values being recorded internally by the program will reach the point where they start to overwrite the guardian's graphic bytes (which are stored at the top of page #9E, as you know), causing visible corruption of the guardian!

MC guardian - animation index test.tap

[IRF]

P.S. A similar approach (picking up sequential values of a particular game variable, and printing them across a spare page of the code, for detailed scrutiny of the raw data) could have useful applications for other purposes.

[jetsetdanny]

Thanks, Ian! It sounds very interesting. I will need to look at it again with a fresh mind to fully appreciate it :) .

 

 

No worries! I might use the 'initially different' one myself at some point. ?

 

Please do so, by all means! Or perhaps it'll find its way into a collaborative project of ours one day :) .

[Spider]

Yet more (as usual) helpful hints and advice! :) :)

[Spider]

I've not re-read the whole topic (sorry) however I did find with a regular but modified 48K game 'engine' there was one instance that said "unused" or similar and using it turned it into a mutlicolour guardian. I've not tried to duplicate this again.

EDIT... I see now from the file in the earlier post in the topic, it shows colour cycling in the editor but not in the game. Clarified that.