IRF

On reflection, the above aspect is potentially confusing, because of the coincidence of the solar beam detecting white INK - causing the air to sap - and the fact that the solar beam is drawn with white INK. (Even though the former - Willy's sprite - is non-BRIGHT white, whereas the beam's INK attribute is BRIGHT white.) A further modification (screenshot attached) helps to provide clarity. This time, the solar beam's INK setting is cyan - the rationale being that Willy is 'blue in the face, gasping for air'! - which applies whether the beam is sapping (red PAPER) or not (yellow PAPER - so it temporarily and harmlessly colours the guardians' INK cyan as well). Note that Willy's INK was still coloured non-BRIGHT yellow 'behind the scenes' by the adjacent guardian (before the solar beam's INK overwrote it in the same frame, this time with BRIGHT cyan) - this went unseen, but you can tell by the fact that his front foot (which falls beyond the reach of the beam as it is deflected away) also falls under the guardian's shadow, and so his front foot is visibly rendered with yellow INK in the screenshot.

The attached screenshot - based on a modified file in which only those characters of the solar beam that are currently sapping Willy's air supply get highlighted in red PAPER - demonstrates that in some circumstances, there can be separate, discrete elements of the beam sapping Willy's air. The intermediate character does not affect the air supply because it falls under the shadow of the adjacent guardian, which changed the INK attribute in the cell holding part of Willy's sprite to non-white (before the Main Loop drew the beam in this frame), therefore that character of the beam is drawn with the regular yellow PAPER/white INK attribute. N.B. It's all a bit academic, as Willy pixel-collided with the guardian and died shortly after the screenshot was taken! 😮😆

And then Norman Sword took the basic concept, refined it, and implemented it in some of the modes of play in Manic Panic.

Yes.

I've noticed it quite a few times actually, but forgot to mention it at the time. Every single post by Zub, for example! (I was searching back through his previous posts for something, and noticed it. But he doesn't seem to visit the site any more, so I didn't prioritise reporting it then.)

Ah, the reason why it's done the way it is, is because if the program were to RETurn to the exit point from the Main Loop, it would then try to draw vertical guardians on top of the Skylabs! So the Skylab code jumps back to a later entry point in the Main Loop, bypassing the CALL to draw regular vertical guardians (as well as the CALLs to draw Kong/the solar beam).

In Manic Miner, the code which deals with Skylabs seems to be arrived at via a JUMP from the Main Loop - unlike all the other guardian routines, which are CALLed. There doesn't seem to be any rational reason for this discrepancy, so a few bytes could perhaps be saved - with a bit of care to ensure the stack pointer is preserved, etc - by changing the status of the Skylab-handling code to a subroutine, with the jump back into the Main Loop replaced with a RET.

Doesn't 'Eugene - Lord of the Bathroom' use 'Erix Mode' as well (albeit an Erix1 rewrite of the Manic Miner game engine, rather than of JSW)? That's not to detract from your decision not to waste time categorising your list of games by game engine modifications - a decision which I can very much sympathise with! I seem to recall that Igor Makovsky's 'Ultimate Manic Miner'* would merit its own similar reference in the list - I think that Igor modified the JSW64 engine in that game, though I can't recall the details? Not to mention Norman Sword's numerous major game engine rewrites! So for consistency, you either had to make major changes to a lot of the entries in the 'Complete list of MM and JSW games', or else trim out the extraneous detail such as which Geoff Mode applied to the various games by Geoff. (*Incidentally, did you ever discover the personal tribute to yourself and many of the other 'Willy old-timers' in Room 54 of 'Ultimate Manic Miner'?)

It's a reference to the fact that one of the room names ('An Ecumenical Matter') is based on a quote from the Channel 4 show 'Father Ted'. Probably the kind of cryptic comment that you needn't concern yourself with. 😉

Is it just me, or do some older posts get truncated when you view them? e.g. this one, which ends just as it is getting going, with "Daniel Gromann raised the question of the game": EDIT... Posts split from original "Temporary Issues" topic.

I don't think that's the right tune. 😮

Now that one (tune.tap attached to the post quoted above) is familiar...

Whilst I was at compiling the previous images, I also came up with this one, which highlights more clearly the 'protective shadow' provided by the vertical guardians. N.B. No air-sapping took place in this frame - which might be counter-intuitive, since the front part of his head is within the beam and is drawn with white INK! But that's because the solar beam itself is drawn with white INK (on yellow PAPER) attributes, overlaying the front of Willy's head (which had previously been discoloured by the guardian's blue INK, earlier on during the processing of this pass through the Main Loop.) Presumably, Norman's modified solar beam wouldn't turn red at all here (which is good, both in terms of gameplay and analysis of the beam mechanics!)

There are also occasions when the solar beam only saps 4 air units, so it would be useful to only have a single character of the beam highlighted with red in such circumstances. In the two attached images, the solar beam is sapping 4 units and 12 units of air in those respective time frames. In the first image, the right of Willy's sprite falls under the shadow of the adjacent guardian, which protects him from the air-sapping effect of that character of the beam. Then the beam is deflected by the guardian, so it passes horizontally through the left of his sprite. A single red character of the beam would help to highlight what is happening. In the second image, the solar beam is passing vertically through Willy whilst he is jumping/falling and not cell-aligned. So three red characters of the beam would be visually useful here. Norman, I presume the beam is highlighted in red PAPER but with white INK in your images? (So that any infilled pixels of Willy's sprite would be visible within the red beam? I can't tell from the images you supplied so far, because Willy just happens to be in right-facing animation frame 0 is all cases, meaning that the right half of his sprite is comprised entirely of unfilled pixels.)

I think it's a useful tool (the beam turning red where Willy enters it), but the usefulness would be enhanced if it were to revert back to yellow 'downstream' of Willy. Because that would allow you to more clearly distinguish between times when the beam is sapping 8 units of air (as per your images), and when it is sapping 12 units - if Willy were to jump in the air in the scenario shown by your images (and assuming the beam stays in the same place), then in the next time frame, his sprite would be spanning three character-rows, and so three characters of the beam would be highlighted red in the upper image.

Thanks, Norman. It's interesting to see that the deflection of the beam (by the vertical guardian extending its reach) is favourable to Willy in that instance. (N.B. It can work the other way too, in some circumstances. e.g. if Willy had been standing a bit further to the left in the screenshot I uploaded a few posts back, then he would have been zapped by the beam, but only because the beam had been deflected downwards by the blue vertical guardian's 'shadow'.) Question: Is the red part of the solar beam in your top picture intended to show where the beam is in contact with Willy? If so, then shouldn't the final character of the beam revert back to yellow? Since Willy is only occupying two character-rows at that moment in time (as evidenced by the fact that the difference in score = 8 points. i.e. only 2 cells of Willy's white INK are in contact with the beam). I mentioned it as a bug because SkoolKid lists it as such in his disassembly (instead of it being in the 'Trivia' section). There is also a similar entry in the 'Bugs' part of the disassembly concerning the attributes bleeding out of Skylabs whilst they are on their landing pads just after crashing - the rationale for that not being a bug, I tell myself, is that the dust emanating from the disintegration of the Skylabs is what is temporarily colouring the platforms.

Another excerpt from the 'Jet Set Mini' Readme provides a couple of POKES, either of which allows you to play around with another novel, quirky feature of the game - namely the invalid rope in the room 'Overgrown MegaTree / Front Door' - happy swinging!:

I've already asked him (by email), and he also thought it was 'influenced by Bach' (but not actually 'by Bach').

Or POKE 37495, 201 (in Bug-Byte) turns off the second Fire cells for each cavern, but not the first.

Sorry, I can see where I made a mistake. I forgot to use an 'R' to turn Willy around after he drops down at the upper-left part of the cavern (after the first few jumps). This datastream is what I was aiming for (N.B. I've crossed out/underlined one 'R', and replaced it with an earlier one highlighted in bold) - the jump over the BRIGHT yellow Pac-man leaves Willy in exactly the right place to wait for the magenta Pac-man to turn around and start moving away: Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q . . . . . . . R R R R R RM . . . . . . . . . . . . . . . . . . . . R R R R R RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . QM . . . . . . . . . . . . . . . . . . Q . . . . . . . M . . . . . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R RM . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R R R R RM . . . . . . . . . . . . RM . . . . . . . . . . . . . . . RM . . . . . . . . . . . . . . . . . . Q Q Q Q QM . . . . . . . . . . . . RM . . . . . . . . . . . . R R RM . . . . . . . . . . . . Q QM . . . . . . . . . . . . . . . R R RM . . . . . . . . . . . . Don't worry if you've already updated your automated file and can't be bothered to make the tweak.

There don't seem to be any POKEs here to protect Willy from being killed by Fire cells in the Bug-Byte edition of Manic Miner (unless I've missed it?) There are two POKEs provided in the first post of this thread for the Software Projects version which apparently do the trick, so based on those, the following two POKEs should have the same effect for BB-MM (although I haven't tried them out yet): POKE 37492, 58 and POKE 37499, 58

No, I think it actually is the same number of frames as your previous best score-run (judging by the length of the video and the final positions of the guardians in each case). What I was trying to say is that, in your latest video, Willy avoids the (previously) first contact with the beam - which saves him from 24 saps - but now his first contact (which was previously his second contact with it) is more deadly by 20 saps compared with before. So the net reduction in total saps across the cavern is 4 - which equates to a total score that is 4 points higher (because both runs finished after precisely the same number of frames).

Thanks, Norman. If there's another update in future, perhaps you could take the opportunity to clean up the datastream in Processing Plant, as per this post (it's no biggie though):

Thanks, crem. I've just been scrutinising both the previous best score video and the current one. The previous one had an additional encounter with the light beam (at the point when Willy is on the conveyor), sapping 24 units of air. However, during the jump through the vertical beam to reach the top-right item, in the previous video Willy benefits from being in close proximity to the yellow horizontal guardian when he makes that jump, meaning that the beam doesn't recognise the presence of part of Willy's sprite (which is overshadowed by the guardian's attribute). Therefore only 64 units of air are sapped during that encounter with the beam, compared with 84 units in the latest performance (difference of 20). During the final jump back through the beam from the top-right corner, 72 units of air are sapped in both videos. Hence the net improvement in the latest walkthrough is only 4 points. *** This analysis has indirectly led me to discover something else about the solar cavern. In SkoolKid's Manic Miner disassembly, he reports the fact that, in the very first frame after Willy enters the Solar Power Generator, the blue vertical guardian's INK colour bleeds into the platform immediately below it (even though the guardian only occupies two character-rows at that point in time): https://skoolkid.github.io/manicminer/reference/bugs.html#blueShadow It's just occurred to me that this bug of the game engine means that a guardian (or rather, the 'shadow' of the guardian) can deflect the solar beam even when the beam isn't passing through it! You can see that occurring in the attached screenshot (beneath the blue vertical guardian, which at that moment in time is cell-aligned in the two character-rows above the approaching beam). In some circumstances, that might actually be beneficial to Willy. (Although at other times, the bug might send the solar beam in Willy's direction when logically it shouldn't!)

Would you be able to provide a similar column of data to what you did before, showing the number of 'air saps' by the solar beam in each frame of the game? It seems to me from watching the latest video that Willy only passes through the solar beam twice? (The bare minimum necessary in order to reach the top-right item.) Nifty work!