IRF

I've just realised that we forgot to laterally invert the boot (and Willy) on the Game Over screen in 'Manic Mixup'! (As we did in 'Jet Set Mini'.)

I just tried out the third file (maximum POKEage variant). Some very strange behaviour going on there! Although I found it slightly frustrating that Willy kept getting sent to The Off Licence (because the default exit setting from most of the rooms, where another room isn't meant to be adjacent is set to The Off Licence by default).

There are some quite supportive reviews in the comments zone here, as well as the positive commentary: https://www.youtube.com/watch?v=f8SBOL1iPdo

I think the answer is "both" - the toilet sprites have been physically relocated (from page #A6), but there is a net loss of two editable sprite pages in the editor's GUI (as well as two fewer rooms) to make way for the extended guardian table. I don't believe that two new pages of memory get 're-purposed' as editable sprite pages in Softricks?

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.

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

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"!

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!

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: 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!)

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.)

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!

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.)

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

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.)

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).

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.

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).

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.

May as well, it wouldn't be a big task.

I presume you meant to say there: "The logical sequence from JSW128VK and JSW128VL" ? (Since this is Version M?)

Didn't we figure that out during the development of 'JSW: The Nightmare Edition'? I seem to recall relocating one or two of them, to ensure that they all had a solid block to their left (in which the cleaver is embedded), rather than 'floating in mid-air'. :P

Conservatory Roof: "Those are probably little bears holding bottles" (as per my avatar). That corroborates my theory that they should all be paired up (Fire cell adjacent to collectable item), and any fix for the uncollectable item in there which doesn't pair them up is unsatisfactory.

There's a preview of a few pages of RG201 available online, including the first two pages of the article which Andrew mentioned - and I noticed that a certain Mr Gromann of this parish puts in an appearance!

Interesting - I had those down as bats, flapping their wings up and down. Their ears turn around as well, as if they're navigating using sonar. It's funny how people come up with quite different interpretations for some of the sprites - on the Yahoo Group, someone described that same guardian as a 'woodcutter'! Anyway, I think I'll stick with my interpretation for my project 'Willy's Recurring Nightmare' (if it ever emerges), because

It seems that you're right about that Danny, sadly. Funnily enough, I managed to post some messages on there, and view them, only on Sunday (the 15th, so after the supposed cut-off date of the 14th). So I was hopeful that the site would remain in the same format as before (except for the inability to upload attachments, etc). But it seems that that is not the case after all. :( However, some good has come out of the situation, because it has prompted several Yahoo Group 'veterans' to sign up here! :)