IRF

Danny, does this ring a bell with you? I seem to recall a game with an improbably long drop, where a rope saves the day several rooms down from the start of the fall. Can't recall which game though. One of Richard Hallas's maybe?

If I recall correctly, the Swimming Pool in Jet Set Mini has a Room Setup Patch which changes the initial swing direction of the rope, depending on which side of the room Willy enters. The net result is that the rope will always catch Willy whenever he drops from above, whether he is left or right of the top segment of rope.

Fun fact: if Willy drops down onto a rope from the room above (eg. Orangery to Swimming Pool), and then you use WRITETYPER to teleport him to another room, then sometimes* in the teleport destination room, he can end up dropping a 'safe' distance onto a platform only a couple of rows below but still be killed (because the falling counter variable isn't actually reset to zero by the process of being caught by a rope). (*At other times, Willy ends up 'out of alignment' with the character rows, causing further odd things to happen!)

If that's the case, then shouldn't you have included a screenshot of Down t'Pit (the start of that fall) to show that it is in fact a bigger drop (in terms of number of rooms) than the drop from On Top of the House? 🤨

What about the record for the longest fall which seems like it's going to be fatal, but in the room at the bottom Willy encounters a rope which saves the day!?

Norman's latest code makes it easy to switch between the two 'rope modes' (key function switch when rope turn round versus when rope passes through the vertical) - to revert the code as listed above back to the original setup (retaining the 6 byte saving), you only need to edit two bytes: change the offset byte of the XOR from 01 to 00, and then swap the JR Z, skip_0 to a JR NZ, skip_0 **** Random fact: when Willy jumps off or falls off the end of a rope, a counter is set that means he cannot get back onto the rope for 16 time-frames of the game. (Presumably intended to prevent him from getting unintentionally tangled back onto the rope immediately after dismounting.) But in a room in a modified game that has two ropes (even with the Adjacent Ropes patch implemented), this 'cooling off period' only lasts for 8 game 'ticks'; with four ropes in the same room it will only be four 'ticks' after dismounting before he can get back onto a rope; etc.

Norman's CPL is essentially doing the same thing as my XOR #80, in this context (CPL toggles all the bits of A, but that has no effect here since there's an AND gate shortly afterwards which isolates the bit under consideration). The other difference is that I applied the XOR #80 after XORing with the appropriate rope definition byte, whereas Norman did the CPL first. (Doesn't make a difference which order they're done in.) And of course the CPL only requires a single byte, whereas XOR #80 takes two bytes.

Potential six-byte saving here (see my comment in the post after the linked one):

Nice one, Norman! Note to self: The code changes you identified would provide a saving of six bytes if you weren't simultaneously implementing the alternative key action whilst Willy is on a rope. i.e. If not inserting the CPL command, whilst leaving the XOR as a xor (ix+rope00)

Further to my previous post, I've implemented my suggested alternative rope motion in the attached file. ** Code changes: this involved firstly changing the command at #937D from a XOR (IX+$00) to a XOR (IX+$01), to pick up the 'Is the rope left- or right-of-centre?' flag, instead of the 'Is the rope swinging left- or right-wards?' flag. But that had exactly the opposite effect of what I intended (the left key made Willy move rightwards on the rope, and vice versa), so I inserted an additional XOR #80 command to toggle the movement back to the correct way round. (I needed to insert two additional bytes for that, so I deleted the redundant two-byte instruction at #93B1, and shuffled all the code in between.) [There may be a simpler way of doing the above without using two consecutive XOR's, but I couldn't think of one.] ** Now that I've dealt with the technical stuff, please have a go with the rope in the Swimming Pool in the attached file. I think this makes most sense of all - pressing left moves Willy leftwards on the rope, regardless of its swing direction, and pressing right moves him rightwards on the rope - simples! In the original game, if you keep a single movement key pressed as Willy swings on the rope, then he switches from climbing up to climbing down the rope (or vice versa) at the moment when the rope reaches the furthest extremity of its swing and turns round to start swinging the other way - that doesn't seem to follow simple logic (hence SymbolShift was prompted to initiate this debate in the first place!) But in the attached, if you keep a single movement key pressed as Willy swings on the rope, then he switches from climbing up to climbing down the rope (or vice versa) at the moment when the rope passes through its vertical position, from one side of the screen to the other. i.e. as the rope changes between having a 'sloping down to the right' versus a 'sloping down to the left' gradient. This seems to me to be a more logical distinction to make, because if you consider the horizontal component of Willy's motion, he is always moving in the direction (left or right) which corresponds with the key that you are pressing. Thoughts? Logical Rope Movement.z80

SymbolShift wrote: "Anyone I know who jumps on a rope for the first time is totally baffled on how to control Willy, as the climbing direction reverses when the swing direction changes. That said, after a while, you do eventually get used to it. I have coded the above method in my game (since it's true to JSW), but I did try a simplified version (left = up, right = down, no matter what swinging direction) and it seemed way more logical." Your suggestion doesn't seem more logical to me, because when the rope is left-of-centre, pushing the left button (to move up, in your system) would cause Willy's horizontal position on the screen to move rightwards. It would only be a more logical method, it seems to me, at times when the rope is to the right of its central position (i.e. to the right of where it would hang if it wasn't swinging). Perhaps the most logical set-up would be to have the up-down functions of the left-right keys toggle to having the opposite effect every time the rope passed from the left-hand side to the right-hand side of the screen, and vice versa (as opposed to toggling every time the direction of swing flipped). That would involve the key functionality being determined by the value of the Rope Animation Frame variable (whether it is a positive or negative number, treating the byte as a signed number so that values > than 128 are negative), instead of using the Rope Direction Flag (the highest bit of the guardian type byte in the guardian definition buffer) to determine which keys send Willy up/down the rope.

Was he a clever de-bugger though? 😄

SymbolShift posed this query in another topic, but I think it belongs here really? : I was super impressed by the WRITETYPER run's from RuffledBricks and DigitalDuck. I wondered if any progress had been made on using AI to find the quickest teleport routes for this? It seems like a task well suited for AI, since there are so many possible combinations for the human brain to calculate. That said, I also understand this would be a complex beast to write, and possibly require a supercomputer to process 😁

I presume the above is referring to the use of AI and WRITETYPER in Jet Set Willy, not Manic Miner? It might be worth replicating the query in the similar topic under the JSW heading, so it's in the right place?

The two attached snapshots are both from the cavern 'Wacky Amoebatrons' (one from original Manic Miner, the other from Manic Jet Set Willy), and comparing/contrasting them illustrates several subtle differences between the two games: - The Coronavirus-esque vertical guardians animate more quickly in the original game (their 'pulsating' happens more quickly), compared with Manic JSW; - The conveyor also animates more quickly in the original game (first and third pixel-rows are 'sheared' by two pixels per time-frame; those pixel-rows are moved along by a single pixel in Manic JSW - which causes the 'messy bedsheets' in Willy's Master Bedroom!); - Observing the horizontal guardians moving along their platforms, you can see clearly the difference in behaviour between when they change direction at the rightmost extent of their range (some animation-frames are skipped in Manic JSW as the guardians turn around, but that's not the case in the original game), versus when they change direction at the leftmost end of their range (smooth, 'normal' behaviour in both games); - Finally, I've just noticed that the cyan horizontal guardian in Manic Jet Set Willy's 'Wacky Amoebatrons' cavern moves at the faster rate (advancing every time-frame), whereas in the original Manic Miner this cyan horizontal guardian was of the 'slow-moving' type (advancing every alternate time-frame). Manic Amoebatrons.z80 MJSW Amoebatrons.z80

I'd be particularly interested to hear from @Norman Sword whether or not the odd behaviour of the horizontal guardians (as they change from moving rightwards to moving leftwards) was a deliberate design feature, or a bug in the routine which moves the guardians. I suspect the latter, especially since it's asymmetrical and doesn't affect the guardians at the opposite extent of their bounds.

Further investigation reveals that it's not so much the saw guardian turning around more quickly which makes this room tricky (the saw is already advancing leftwards towards Willy when he enters the room). Rather, it's the rolling egg above the nest which bounces back more quickly from the outer edge of the nest, leaving Willy with less time to collect the item safely. I've created two snapshot files with Willy in a 'safe place' inside the nest, one from an original(ish - no changes to Cuckoo's Nest) JSW file, and the other from Manic Jet Set Willy - see attached. In both files, the game was paused when the egg had just reached the rightmost extent of its range (in its 'sloping down-to-the-right' frame of animation). If you load up each file in turn, unpause the game (press the 1 key or something to unpause, not a jump/move key as that would put Willy in danger!), then you can see the different behaviour of a horizontal guardian as it turns around and starts to move left. (I find it helps to keep the A-pause key depressed whilst doing quick jabs at the 1 key, in order to see the animation frame-by-frame.) In original JSW, the egg remains balanced on the spot for a single time-frame (with no change of animation frame), then moves to its 'lying horizontal' position in the next time-frame, and then moves to its 'sloping down-to-the-left' frame of animation in the next time-frame. In Manic JSW, the egg jumps straight from its 'sloping down-to-the-right' to its 'sloping down-to-the-left' frame of animation, as soon as you unpause the game, thereby missing out two animation frames. N.B. In both files, when the egg reaches the leftmost extent of its range, it spends two time-frames in its 'balanced vertically' frame of animation, so the 'turnaround bug' doesn't affect the horizontal guardians when they are turning from leftwards to rightwards motion. The consequence of this bug/feature/change is that in original JSW, it takes 13 time-frames for the rolling egg to get from its furthest position at the outer edge of the nest to a point underneath the item (which I believe is meant to be a tiny bird nesting atop the giant imposter egg?), whereas in Manic JSW, that same part of the egg's traverse only takes 11 time-frames. JSW Cuckoo's Nest.z80 Manic JSW Cuckoo's Nest.z80

Danny, I noticed that in your recording of the Mutant Telephones cavern, you collected the item that is located under the portal before the item in the middle of the cavern (to the right of the slow green horizontal guardian). So it seems that the effect of the 'bug' on the timings of the guardians may have even driven you to change the order in which you collected the items in this case? (So it affected not just the subsequent moves, but the preceding moves as well!)

Based on this post of Norman Sword's: https://jswmm.co.uk/topic/649-manic-jet-set-willy/?do=findComment&comment=14251 ... the general ethos of this project seems to have been to compress the two games into one, not to change the data (other than where necessary to allow fix certain critical bugs, to allow the game to be completed without loss of life). I think most of the room/cavern layouts, guardian behaviour, etc have been faithfully replicated, but the odd unintentional difference may have crept in during the process of transferring the data. However, I do think that the jerky movements of the horizontal guardians, as they turn around from moving rightwards to leftwards movement, is something that arises from a bug in the code which handles the movement of horizontal guardians. I don't think it's likely that it was a deliberately designed feature? Perhaps Norman Sword might wish to comment on this when he next visits the site? ** BTW Danny, I've just noticed that in your post which directly follows after the one I've provided a link for above, you commented on how, like Andy, you had encountered more difficulty than usual in the Cuckoo's Nest (particularly when playing the game at the fastest speed). As with Andy, I think this was probably because the saw turns around at the nest and comes at Willy much faster because in that moment it skips straight past two frames of animation (the 'turnaround bug', as I've started referring to it). You didn't specify which rope room in the above quote, but I believe you are talking about The Cold Store? Again, the Turnaround Bug is probably to blame (or, should I say, to be thanked, since you're reporting an improved performance here!) - the horizontal guardians fall into a different relative alignment with the phases of the rope's swing, and this happens relatively quickly after Willy enters the room because they all (except for the penguin on the floor) move within quite narrow bounds, so it doesn't take long for them to reach the edge of their ledges whereupon the bug makes them skip forward a few steps.

Actually, that red seal seems to have the rightmost extent of its bounds go further right by one character as well, which brings it even closer to the green seal. I thought the dataset for the caverns was identical, but it seems not in this instance? The green seal also goes one more character to the left in MJSW than it does in original MM. The two seals, at the closest point of their approach, get six frames of animation closer to each other in MJSW than they do in original MM (four frames because of the range of the seals being wider by one character, and two frames because of the 'turnaround bug' I've discovered).

Sorry yes, I should have aimed the question more widely. It makes sense what you're saying, in light of what I've discovered. Basically, if you're approaching a horizontal guardian from the left (like the saw in Cuckoo's Nest), whilst it's moving away from you but about to turn around, then when it turns around to come towards you it does suddenly leap forward by two animation steps faster than usual - making it harder to evade. I've just done a couple of screenshots from the Abandoned Uranium Workings, one from original Manic Miner and the other from Manic Jet Set Willy. In both cases, I've captured the last moment when the two seals are moving towards each other - in the next time-frame after the one I've captured, the red seal has turned away from the green seal to avoid colliding with it. You can see that in the case of Manic JSW (bottom image), the two seals get much closer together than they did in the original MM (top image). If the game was set up in such a way that the two seals normally have a near-miss, then with the new game engine they probably would have collided (killing Willy in the process!)

By my calculations, having done screenshots of both recordings (your 'old slow' recording and your 'new slow' one), you lost 560k points during the first jump through the beam in both recordings, and you lost 720k points during the second jump through the beam in both cases. (It is perhaps possible to miscalculate if you freeze the game using the emulator's pause button, and if in doing so you capture the game 'mid-calculation'? I used 'Stop Playback' just after Willy had commenced each jump, and then used the in-game pause button so that the freeze point fell at the same point in each pass through the main loop, so that the update of the score tallies should have been consistent.) This is also exactly the number of points I would have expected you to have lost based on the number of characters of the solar beam that Willy occupies during each time-frame of his jump through it. N.B. The discrepancy of 100 point which you mentioned is, I believe, due to the in-game clock having ticked over to the next minute in one of the cases. (You lose 100 points every time a minute is added to the on-screen clock.) In summary, I don't believe you could have reduced the amount of points lost to the solar beam any further than you already have managed to do. 🙂

Both of those things could be explained by the erratic behaviour of horizontal guardians as they change from moving rightwards to moving leftwards, as I outlined in my previous post in this topic. e.g. If Willy falls into the flashing portal when the penguin is in there, if the timing is right then the penguin may have partially* moved back out again faster than usual by the time Willy has dropped in there? (*Partially, as in sufficiently far for Willy not to clip it with his back foot as he's falling whilst the front of his sprite is pressed up against the wall.)

In the process of investigating Danny's recordings of 'Manic Jet Set Willy', I have just noticed that the animation of the MM guardians transposed into Jet Set Willy does not faithfully replicate their behaviour in their original Manic Miner setting. EDIT: In fact, the motion of the JSW horizontal guardians isn't faithful to the original either (see below). If you study the vertical guardians in the Solar Power Generator, they only animate (i.e. change frame of animation) every other time-frame, whereas in original MM they animate every time-frame. (In JSW you can have slow-animating or fast-animating vertical guardians; it seems that Norman Sword set the MM VG's to have the slow setting). You can see this even more clearly in the Final Barrier, where the winking eye winks more slowly than it does in original MM. There may be some instances of vertical guardians where this difference in animation speed makes manoeuvres around VGs more difficult (or alternatively more easy) - especially if such guardians change significantly in size during the course of their animation cycle (I'm thinking of the first Amoebatrons cavern, for example, where they pulsate inwards and outwards). But that isn't likely to be the case with the Solar verticals, which remain the same size and circular in shape (with just the inner pixel pattern within the circles changing as the discs rotate). Perhaps of even more significance: I noticed that the horizontal guardians (both fast and slow) within the Solar Power Generator miss out two frames of animation as they transition at the rightmost extent of their range from moving rightwards to moving leftwards. Visually, the effect can be seen as if the guardians are 'bouncing' off the right-hand wall of the cavern. Curiously, this doesn't happen at the other end of the horizontal guardians' range (when they switch from moving leftwards to moving rightwards). I have also observed this effect within both the Final Barrier and the Central Cavern (the latter having an eight-frame horizontal guardian, so it doesn't just affect the four-frame MM HGs). EDIT: In fact, it also affects the regular horizontal guardians in the Jet Set Willy rooms. Observe the yellow monk at the bottom-right of First Landing. When he turns from moving left to moving right, his nose is at its shortest extent (as is the case in original JSW). But as he turns from moving right to moving left, his nose is at its longest extent. Or see the rabbit in Ballroom West. When it stops pirouetting at the right-hand end of the table, it does a big, sudden bounce forward as it turns round to go leftwards. (That's a good example as the edge of the table shows you exactly the extent of its range.) This difference in the motion of the horizontal guardians (which may be caused by an error in the part of the code which handles the guardians as they change from moving right to moving left?) is likely to have a potentially significant effect on the gameplay. In fact, it explains why, when I was looking for Danny's reported 'sudden flash' of the solar beam horizontally across the top of the conveyor in an original MM game file (the file only being modified to deplete the initial air supply in the solar cavern by a single unit, to try and replicate what Danny was experiencing in his recording of 'Manic Jet Set Willy'), it didn't happen in quite the same way. (Changing the initial air supply from an 'odd' to an 'even' amount of units did change the way that the Slow HG interacted with the solar beam, but not in quite the same way because the timings are all different due to the missing animation frames of all the HGs. So the 'sudden flash' wasn't as sudden - it didn't last for just a single time-frame as Danny encountered.) ** Danny, in light of the above observations, I wonder if you found when you were playing 'Manic Jet Set Willy', that jumping over/under/past certain guardians (particularly horizontal ones) was either more easy or more difficult than anticipated, based on your 'usual' routines/routes in the regular games? I'm thinking maybe something along the lines of the horizontal guardians in The Forgotten Abbey, or The Endorian Forest, or The Cold Store, not being in sync in the same way as they usually are? **** Incidentally, another aesthetic change is that the conveyors in 'Manic Jet Set Willy' seem to animate by one pixel at a time rather than two pixels - which causes Willy's/Maria's bed to look rather messy! Also, the 'Forgotten Abbey' is now less forgotten, as the 'secret entrance' is more obvious due to the visible animation of the conveyor in The Wine Cellar.

Well done, Danny! I would guess that the remaining discrepancy may possibly be due to Willy being cell-row-aligned versus not cell-row-aligned (i.e. At a certain stage of his jump) at the moment when the beam first hits him during that pass through the beam. (Or conversely during the final instant when he passes through it?) Meaning that in one recording, there is a single time-frame when his air is sapped by 8 units (2*4) but in the other recording his air is sapped by 12 units. This is where my suggestion for Norman's colour-changing solar beam only to have its PAPER colour change for those cells actually occupied by Willy - with it reverting back to yellow once it has finished passing through his sprite - would come in handy.