IRF

Surely the room should be called The Bassment? 😉

I've just noticed something slightly different about the behaviour of the game mechanics in MJSW compared with original MM/JSW. I noticed it in The Endorian Forest, whilst trying to jump leftwards off the bottom right crumbly platform. If Will stands on the far left of that crumbly platform (in such a position that one step leftwards would cause him to stand on the spiky branch fire cell to the left of the crumbly, killing him), and then does a leftwards jump: - In original MM, he hits the Fire cell and dies (because in the first increment of a sideways jump, he moves leftwards and is drawn at the same height; the jumping indicator is set in that pass through the Move Willy routine, but he isn't actually moved upwards until the next time frame; - In MJSW, the movement is the same and he is drawn in the next iteration apparently standing on the Fire cell (although his pixels only occupy the righthand of the two character columns that he occupies in that frame of animation), but he survives the encounter and subsequently jumps over the fire cell and onto the platform above.

Digital Duck took advantage of Willy's ability, when jumping up and landing on a platform above that which he jumped off, to perform a turnaround and vertical jump in a single time frame. Crem's AI did those manoeuvres (in order to collect the top right item) in two consecutive time frames (also had to keep the right key pressed at the end of the first jump to advance Willy by one more frame to be able to collect the item using a vertical jump. So whilst the AI was seemingly 'one step ahead' jumping up off the crumbly, that initial gain was negated by having to take two frames to turn around and jump compared to DD's one frame - at that point they're level-pegging. But then DD's extra frame spent on the upper-right crumbly meant that they didn't have to wait as long (one time frame less) to drop through it later. The middle of the three crumbly blocks is the determinant here - DD has things optimised as both left and middle crumbles disappear at exactly the same time, whereas in the AI recording, once the left-hand crumbly block has gone there is still one more pixel-row of the middle crumbly block remaining to delay Willy's drop.

To answer my own question, no the difference occurs on the top right crumbly platform - Willy walks along one more step before jumping rightwards off that platform in Digital Duck's video, compared with Crem's AI-generated walk through in page 6 of this thread. However, they both land in the same place after the jump (in the optimum position to collect the top-right it), because of different left-right keypresses being pressed at the moment of landing (I think?)

I wonder how the AI failed to pick it up? Is it because it involves momentary inaction in the present to make things more efficient in the future? Mind you, that's the sort of things that humans are less likely to come up with (our in-built instinct is to do something), whereas the brute force AI approach of trying every possible iteration of moves (or in this case non-moves) should have detected it?

Actually, I've just added a timestamp in a comment on your YouTube video (8:52), just before when Will jumps onto the crumbly platform which I think is the one you're talking about (the lower one of the right). Is that correct?

Which platform specifically are you talking about? Could you describe it please, or show an image with it circled or something?

My main current obsession is still my bass guitar! I've not done anything major in the JSWMM scene lately but I do pop in here now and again. No doubt the time will come when I devote more time to Willy's universe. Packaging up a series of minim puzzles is certainly one of the things on my to do list. 😊

Interesting idea, Andy!

You could always change its status to 'unlisted'. That way you would have 100 publicly available videos, but the 'temporary' video would be preserved, and you could send a link for it to anyone who requested to see it.

There is another aspect of the code in that vicinity which is worthy of comment. The way that Matthew hid Willy's legs underneath the Swordfish (at #9071-#9076) is not ideal. He just changed the attributes to black-on-black, but that means that they reappear during the colour-cycling when the remaining air in The Final Barrier is counting down. It's better to wipe the pixels of his feet from the screen instead, which would take about 8 or 9 bytes to replace those at #9071-76 (so two or three more bytes are needed to achieve it): LD HL, #40F3 - point HL at the appropriate place in the pixel screen file [with Matthew's original code, HL will be pointing at #58F3 when flow of execution reaches #9071 so L already holds the correct value and therefore this command could be a LD H, #40 to save one byte. But Danny's more efficient method that he described in the post before this might mean that particular efficiency isn't available, and you might have to define both H and L] LD DE, #???? - point DE at somewhere in the code with 32 contiguous zero bytes CALL #8FF4 That also wipes the pixels from the character row below the one with Willy's 'ghost legs' (that part of the screen should be empty anyway so it's pointless-but-harmless). **** For two more bytes, you can only wipe one character row of pixels (the one with Willy's legs in it), meaning that you would only have to find 16 contiguous zero bytes to point DE at. To do that, replace the CALL #8FF4 with: LD B, #08 CALL #8FF6 - note the late entry point into the 'Draw a Sprite' routine, to ensure that only 1x2 character spaces are wiped, instead of 2x2 as usual

At #904C, H already holds the value #40, so the three-byte LD HL, #40B3 can be replaced with a two-byte LD L, #B3 (I suspect that might be the one that @jetsetdanny already came up with?)

Of course, if we know that C=0 throughout, then those two two-byte commands LD (HL), #00 at #9072 and #9074 can each be replaced by a single byte LD (HL), C. (Unless that's the optimisation which Danny already identified, as he referred to in the third post of this thread?)

XOR C doesn't change the value in C, it only changes the value of A. (And the Flag register - as you say, it resets the Carry Flag.)

Dr Andrew Broad, in his 2008 Remix of Manic Miner, forced the player to visit that spot in The Bank in order to collect (from below) the top-right item, and also made the cavern more challenging overall, simply by removing the trellis structure from the right-hand side of the cavern. Thus forcing Willy to navigate the cavern the hard way. Ingenious! (Although he could have added even more difficulty by moving the portal one character row higher, as that would have forced the player to jump onto the crumbly block, perilously close to the adjacent 'spider' Fire cell, in order to reach the portal - as things stand, Willy can just jump up into the portal from the mid-level water platform that is located below the platform that the portal rests on).

The same is true of two of the screen shots from original JSW on page 1 of this thread - the sea to the left of The Bow is comprised of Fire cells, as is the cross in First Landing.

Having said that, the code without the command to set initial values for BC at the start would be quite 'brittle' (to quote Andrew Broad in another context). ie it would not be a well-designed bit of code if it were exported elsewhere, where it might run into problems.

Danny, your original query mentioned the C and D registers both being set to #00. But D is set to #32, just after BC are set to #0000. Judging by subsequent posts though, I think you meant to refer to B and C in the first place? Andy, you suggested that XOR C will set C to zero via a single byte command. That is not the case - that trick only works with XOR A. Danny, there is no direct use of B in the preceding code (#903E-#9076), but that code contains two CALLs to the sprite-drawing subroutine (#8FF4), wherein B is assigned a value of #10. So there is no point setting B to zero at #903E - it would be undone at #9046 (and then again at #904F)! Fortunately for your purposes though, there is a DJNZ loop at the end of that subroutine (at #9024), and that loop by definition will not come to an end until B has reached zero. So B (and C) will always hold the value zero by the time flow of execution reaches #9077. 😊

@erix1 I'm drawing your attention to the recent discussion here about a proposed bugfix for your game Eugene: Lord of the Bathroom. (To prevent the title screen being skipped if a Kempston joystick isn't plugged in.)

I just thought that maybe he hadn't seen your earlier post suggesting that the bug fixed version be released? Edit: if he's only an occasional visitor here.

Sorry, the appropriate address for the Kempston Joystick Indicator is #8459, not #85CE. (I was thinking this was a JSW engine game, rather than a MM one.) Anyway, I just tried the above. However, even though Philip Bee's RZX recording shows the title screen and full scrolling message prior to the walkthrough if you go to the RZX Archive and click 'Watch Video', when I tried downloading the RZX file and playing it back in ZX SPIN, the title screen only showed momentarily before the game started up automatically (skipping the scrolling message) and then the walkthrough of the actual game proceeded in the same way as it does when you 'Watch Video' at the Archive. In that sense, the supposedly pre-recorded recording plays out differently depending on what method you use to view it! That seems rather odd to me (it could be a problem with the SPIN emulator?) I then took control of the game in SPIN by clicking 'Stop Playback', used the Debug feature to tweak the Title Screen routine so that the Kempston Joystick Indicator is always set to 01 before the game starts (by changing the jump length at #8629 from 05 to 00), and then abandoned the current game using SHIFT+SPACE to see what would happen. Once again the title screen only appeared briefly before the next game auto-started, but this time Eugene (the protagonist in this game) started jumping straight upwards repeatedly (and, as it happens, rapidly losing lives because the start position of the game is directly underneath a Fire cell). I should add that I didn't actually have a Kempston Joystick plugged into to my laptop during this experiment. I think what happens is that if the status of the Kempston port is tested on a Spectrum whenever a Kempston Joystick isn't actually plugged in, then the default situation - as far as the machine assumes - is that the Fire button is continuously being pressed. Or something like that? Anyway, in summary: 1. The bugfix that I came up with definitely works, in the sense of stopping the autostart problem, if you haven't got a Kempston Joystick attached, and I see no reason why the bug fix wouldn't allow you to see the title screen/scrolling message if you do have a Kempston attached (though I haven't been able to test that as I don't own one). 2. I still believe that Philip Bee's RZX recording probably behaved differently (not bypassing the title screen/scroller) because he had a Kempston Joystick plugged in at the time that he did his walkthrough (but the anomalous behaviour of SPIN(?) has prevented me from proving that definitively).

I was just thinking of playing the recording in Spin, and once game play is underway, press File - > Save snapshot. Then open up the .sna in JSWED. Or even just use the Debug feature in SPIN and look for the relevant address.

You're right to point out the need not to take the snapshot during the title screen/ scrolly message, as that might defeat the purpose of the exercise!

The check for the interface only occurs during the title screen. If the snapshot is taken once gameplay is underway, then the variable should be fixed for the duration of the game.

Did Vidar ever get back to you, Danny? It might be worth sending him a PM or tagging him into a post on this thread. Something else that might be worth doing, to verify the bug fix works and is fully understood, is to take a snapshot from Philip Bee's walk through of Eugene Lord of the Bathroom, and look at what value is held at address #85CE (the Kempston Joystick Indicator) - if my theory is right as to why he didn't encounter the bug that causes the title screen/scrolling message to be skipped, then #85CE should hold a value of 01.