IRF

For the record, in my code which optimises the horizontal guardian movement routine (by using shared code for both left and right movement), there is a further optimisation to be had by replacing: LD A, (IX+$06) / LD A, (IX+$07) LD B, A with: LD B, (IX+$06) / LD B, (IX+$07) EDIT: Now implemented at source.

A play on the name of the musical "Thoroughly Modern Millie", of course. :)

I seem to recall an advert for the game which contained the phrase "But beware the Attic..." (part of the attempt to pass the bug off as a 'deliberate mistake').

Makes Maria rather less formidable?

I would hazard a guess that the way that was achieved was by modifying the rope-drawing code, so that collisions are detected in the same way as the arrow-drawing code. i.e. a pixel-collision has to take place when a segment of rope is drawn AND the attribute of the cell within which that rope segment is being drawn also has to have a white INK setting?

Danny, did you notice that Ligan uploaded a corrected version of the file to post #13 in this thread?

Having thought about the above, I'm not sure if it's feasible to come up with an arrangement that's more byte-efficient than the current one. Firstly, the direction of travel for horizontal guardians would have to be determined from Bit 2 of Byte 04. But there's no easy way of checking when the value in Byte 4 has spilled over past Bits 0-2, other than by checking for the individual values 08 or -01 (#FF). The Carry Flag wouldn't respond in these circumstances. Maybe if all the values for animation frame were doubled (and the 'Draw the horizontal guardians' routine was amended accordingly, with an additional RRCA inserted at #8DD0), then the Half-Carry Flag could be used. But I don't think there are any Z80 instructions (conditional jumps etc) which are determined by the status of the H Flag. You would need to fundamentally change the function of Byte 04 for horizontal guardians - edit all the horizontal guardian data, so that Bits 5-7 holds the animation frame (with Bits 0-4 unused, although perhaps they could be recycled for other purposes?), rewrite the 'Move the horizontal guardians' routine in accordance with my previous post, and then NOP out the three RRCA's in the 'Draw the horizontal guardians' routine at #8DCE-#8DD0. Probably not worth the hassle. To contradict myself again, I managed to get my suggested approach to work in Manic Miner. :) I used three RRCA's at the start of the 'Move the horizontal guardians' routine to rotate the animation frame (loaded up to A) into Bits 5-7, and then three RLCA's at the end of the same routine to rotate the updated frame value back into Bits 0-2, before loading back into guardian Byte 04. (No need to change 'Draw the horizontal guardians'.) Even with all those additional rotate commands, there are still at least ten spare bytes left over because of the merging of the left-right movement commands!

Thanks Ligan! So is the official name for this project "Manic Miner: Back to the Mine"? I should point out that the additional wording on the Title Screen actually says "Back to to the Mine"!

Note to self: my shared code for left-right horizontal guardian movement could be optimised further. e.g. Instead of having LD A, (IX+$06) then LD B,A - just do LD B, (IX+$06). Also use a shared command at the end LD (HL),A to update the animation frame (i.e. an earlier jump destination). (Temporarily posting this here because on the PC I'm currently using, I can't seem to edit earlier posts.)

No solar beam in Solar Power Generator, I notice.

All of the little pink gremlins have lost their left arm in that version!

Yes, the 'ghost' Fire cells and the 'bunch of grapes' items - both fitting in with the Pac-Man theme.

I think Norman Sword drew my attention to this a while back, when he did his project that combines both versions into one file. It is a notable absence from John Elliott's list of differences between the two versions: https://www.seasip.info/Jsw/mmengine.html

37708 = #934C That's the large area of unused code in Manic Miner (soon to be put to better use in a forthcoming remix...), whereas I think Andy was referring to the unused region of JSW at #FD00 (64768)?

Clarification: the above is sometimes the Software Projects triangle, but at other times it is the 'thresher' guardian. i.e. the sprite drawn in that position on the title screen depends on which version of the game you are about to play - corresponding to whichever vertical guardian appears in 'The Warehouse'.

Actually, having checked the above, the item would still have been collectable in that location in both files, and whilst it is still collectable from below in both, the slightly altered positioning might actually encourage the player to make the quirky jump-through-the-wall in the 'Before' file - see attached JSWED screenshot (the relocated item is in the square cursor).

I could have made all the manoeuvres in each file compulsory. e.g. placed an item to the right of Esmeralda underneath the Earth ledge in the 'Before' file. However, the problem that would have presented is that an item located in the same place would have been uncollectable. The challenge I faced as a designer of this particular project was to have two parallel files with identical layouts but different 'Willy mechanisms'. That meant that in some cases, Move 1 has to be used to collect Item A in one file, and whilst Move 2 is available for Item A in the other file, Move 1 also works in that case (if you see what I mean?). Though there are some items for which different moves HAVE to be employed for the two files (which is ideal). So in order to 'enforce' the manoeuvres I had in mind, I had to change the 'rules of the game' by asking for two different collection methods for each item.

Danny, did you observe in my 'Before' recording, the alternative collection method for the item behind Esmerelda in 'Emergency Generator'? i.e. Jumping through a head-height Earth block and falling through it. (It's possible that you may have attempted that manoeuvre but been unlucky with the timing, and clipped Esmerelda's arm as it swung out whilst Willy fell down past her?) Note also that when Willy attempts the same method in my 'After' recording, he is caught by the (Earth cell) ledge, instead of falling through it (thus demonstrating my symmetrical fix for the 'Wine Cellar' quandary). Also, you can see that I took a different approach for the bottom-left item in 'The Attic' - jumping leftward through an 'Innocent-Looking Block' from above, whereas in Danny's earlier recording, Willy jumped upwards through the same block, treating it as as an 'overhead ILB'. But neither of those moves are possible (or at least don't have quite the same outcome) in the 'After' file. **** Some other commentary on my recordings: In the modified game engine, Willy can no longer walk leftward up a ramp and pass through an overhead Earth block (though if his head hits such a block whilst you are pressing Jump+Left keys simultaneously, he can be made to pass sideways through the ramp, underneath the Earth block - see the ramp in 'Emergency Gwnerator'). Also, Willy can no longer walk down a ramp and pass through an Earth block located at its base (as he can do in the original game engine - see the ramp in 'On Top of the House'). ** With regards to the 'standard' quirky behaviour whereby Willy can jump through standonable blocks (at foot height) that are situated adjacent to Fire cells, the changes to the game engine have an interesting effect on that particular manoeuvre: In the 'After' recording, note the difference between 'On Top of the House' (where he can perform the manoeuvre), versus 'Dr Jones...' (where he can't). The difference between the two scenarios is caused by the presence of an Earth cell in the latter (though the Earth block is not actually adjacent to the Fire cell; there is a Water cell in between). Note also that I have exploited these two contradictory behaviours in the 'After' file. In the case of 'On Top of the House', the fact that this quirky manoeuvre is possible means that Willy is able to reach the lowest three items. Whereas in the case of 'Dr Jones...', the item on the elephant's back is only collectable because Willy doesn't fall through the standonable surface adjacent to a Fire cell (the nearby Earth block prevents him from doing so). And furthermore, I proved this point in the 'Before' recording by making a futile attempt to collect the item via the same method (before then going back to collect it by walking leftward through a head-height Earth block inside the elephant's head). ** There are two identical gaps in 'The Attic' (with five clear columns of Air in between, and with the platform on the far side of the jump situated one row above the platform from which Willy starts the jump). Such a jump is normally impossible for Willy to clear, as demonstrated in the 'Before' recording based on the unmodified game engine. However, in the modified 'After' variant, one of those apparently identical jumps can be safely cleared by Willy, yet the other jump remains impossible (I sacrificed one of Willy's lives in the recording to demonstrate this point). The difference can be explained by the fact that for one of the jumps, the end of the platform onto which Willy must jump is comprised of an Earth block. ** Another thing which I attempted to demonstrate by sacrificing a life in the 'After' recording (while jumping from the left-hand stack in 'Emergency Gwnerator'), is that when Willy hits the side of an overhead Earth block whilst descending from a leftwards jump, his 'Airborne' counter is no longer reset to zero (by a CALL to the 'ILB' subroutine at #9EBC when his head enters the Earth block). This has consequences for how far Willy can safely fall at the end of such a jump. On the other hand, the same 'ILB' subroutine at #9EBC also resets Willy's 'Sideways Movement' flag, so the fact that this isn't triggered in the modified engine, means that Willy can jump onto a conveyor, banging his head on the side of an Earth block on the descent, but then he can still proceed upstream along the conveyor. (Compare and contrast the jump leftwards from a position adjacent to Maria in 'The Attic', in the 'Before' vs 'After' recordings.) However, if Willy stands a bit further back before making such a jump (as seen at the end of the 'Before' recording, once Maria has cleared out of the way to make this possible), he can land on the conveyor in such a position that his head doesn't enter the overhead Earth block for long enough to reset his Movement flag (so he can eventually proceed up the conveyor, although he must have already collected the item that was located there, in order to have moved Maria out of the way in the first place - Catch 22!)

You could buy your own mansion, with a stern housekeeper and a crazy chef...

From post 77 in this thread: I think I'm right in saying that the 'multiple graphic definitions with shared colour attributes', made possible in JSW via Norman Sword's approach to expanding the room graphics, would NOT be possible in Manic Miner? Because of the way that the cavern layouts are distributed: each cell is assigned a block type based purely on its colour attribute, so for example if you had crumbling walls, it would be impossible to distinguish between blocks that are intended to use the graphic defined for crumbly and ones that are meant to be drawn using the solid wall graphic definition. Therefore you could only have one graphic for such a combined block type; it would use the graphic of the first block type to appear in the list - see http://skoolkid.github.io/manicminer/asm/8020.html for the order in which block types are considered. However, all the blocks drawn with the shared attribute/graphic would exhibit the behaviour of both crumbly and wall (in the example above). i.e. they would stop Willy walking/jumping through them, but they would crumble away when he stands on them.

Actually, I take that back - for his graphic, the Eugene routine uses the data from the copy of Eugene's Lair in the cavern buffer (#80E0-#80FF), rather than the original data at #C2E0-#C2FF. So in other rooms, in order to insert a Eugene you would have to copy the graphic data into the equivalent slot in the primary cavern data (Offsets #2E0-#2FF), meaning that you couldn't also have a vertical guardian or Skylabs (whose definitions occupy the same slots) in the same cavern as Eugene.

You can have Eugene with Skylabs, but none of the other specials work alongside Skylabs, because the program enters and exits the Skylab routine via jumps - on the way back to the Main Loop it jumps straight to the CALL to draw portals - rather than a CALL and RET.

I've just realised the reason for the difference between MM and JSW64 - in the latter, there is a room offset byte which can specify the low byte of the solar beam's start point (anywhere within the upper half of the room). Whereas in MM, it's set within the game engine - if you had more than one room with a solar beam, then moving it in one would change its position in the other (ditto with Kong and Eugene). So it's 'safer' to make the game designer change the position within the hex editor. It does mean that in MM, in theory, you can change both low and high bytes of the address, and therefore have a solar beam which starts in the lower half of a cavern - e.g. in Final Barrier, where it could represent light coming in from the outside world as drawn in the top half of the screen!

Furthermore, inserting a CALL* to #8A52 into the Cavern setup routine (just after the full characters of air supply have been initially drawn) means that you can draw the correct number of pixels of air supply at the start of each cavern, which removes a visual glitch that can occur when Willy first enters a cavern (whereby the rightmost character space of air is initially fully filled in [or fully empty with my previous three POKES in place], and then gets adjusted on the first pass through the Main Loop to reflect the proper value for the initial air supply. (*Needs consolidation to get it to fit.)

Correct me if I'm wrong, but there is no way in JSWED's GUI to edit the location of the 'entry point' of the solar beam in 'Solar Power Generator', for a file based on the Manic Miner game engine? You can change the start of the beam, but you have to manually adjust the appropriate addresses in the hex editor (namely #8D74-5). In contrast, in a room with a solar beam in a JSW64 game, there is an option to move the beam's starting point within the GUI.