IRF

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.

Do the pink fire cells at the bottom represent a vat of strawberry flavoured Angel Delight? What a way to go - drowning in Angel Delight!! 😜

I wonder whether you should give the protagonist's sprite some angel wings? Would make the game harder (more chance of pixel-collision with guardians).

In the 4th post of the thread at the link below, I provided a patch for the JSW64 game engine, which should allow you to have both Skylabs and Droplets in your game: The first post in that thread describes what the problem is - basically, John Elliott's Droplet patch permanently overwrites the Skylab routine, so as soon as you encounter a Droplet whilst playing the game, all Skylabs elsewhere in the game are turned into Droplets. ie the periodic horizontal displacement of all Skylabs is switched off. It's been a while so I can't recall off the top of my head whether my aforementioned fix is a proper robust one, or whether it's just a Room Setup patch that undoes the damage caused by the Droplet patch that's implemented when you enter the Skylab room. Either way, it could be adapted for Strangel 2.

Nice nod to 'Tree Root' in Sammy's bullet point 3. 🙂 However, Sammy is a mere sapling in comparison with the Allerton Oak - a thousand year old tree near my house, that is only a couple of miles away from the Bearbrand Complex where Software Projects used to be based, so I reckon it has a stronger claim to be at the 'root' of the MegaTree concept. https://images.app.goo.gl/fKsYZaNU9zC1DpJT9

Willy also has a cleaning business in Liverpool called 'Willy Wiper'.

The answer to that is: quite possibly, yes! There's a flaw in the game engine which means that if Willy jumps up above the top of a cavern, part of his sprite gets written over the data in some of the other caverns! The precise effects of that corruption can vary (and depend on the game engine - Bug Byte or Software Projects).

Is it physically possible to jump (from three steps back from that, on the edge of the precipice) over the two fire cells and escape down the ramp without getting hit by the rolling cuckoo egg? Edit: I can answer my own question. Willy can jump back over the two fire cells and land on the other side without hitting them. But then he doesn't have time to get down the ramp before the egg hits him.

Technically, that precise spot on Cuckoo's Nest is not accessible because Willy has already collided with the rightmost fire cell. (At least, his colour attributes are overlapping that fire cell, even if the is no pixel collision since his sprite in that frame of animation only occupies one character column.)

You're quite right! However, I was talking in the context of having recently been exploring your game Manic Jet Set Willy, not with a view to completing the game, but just checking out all the individual rooms. It did help me to access Under the Drive in that context - after the Forgotten Abbey I had dropped down into Entrance to Hades out of curiosity, then after dropping through the new, empty room below that, I ended up at the top of Security Guard. Rather than go all the way round again, I used the shortcut of falling through one of the guards to resume my subterranean journey. Incidentally, is there an invisible item in the empty room above Rescue Esmerelda in MJSW? (Or possibly visible in theory, but you never see it because Willy collects it immediately upon entry in the one place above Esmerelda where the room can be entered?)