IRF

The png scans of the original comic strip (which I hadn't ever seen before) have convinced me that the pattern/arrangement of Fire cells at the bottom of the 'Gaping Pit' are the specific element which inspired the eventual name!

My interpretation of the GUI is (or was) the 'Rooms' page (and 'Start' page etc), where you can view and directly edit the room graphics, rather than the tickbox menu for applying patches to the code. But that's probably my misinterpretation of the terminology. :blush:

I recall reading an article which was published before Jet Set Willy was first released, which featured an interview with Matthew Smith along with some preview screenshots of various rooms, one of which was the 'Gaping Pit'. i.e. that was Matthew original name for the room which eventually became known as '...Quirkafleeg'. Incidentally, my guess is that the Fire cells at the bottom of the room are meant to resemble people lying down with their legs in the air, which ties in with the explanation for this room's final, peculiar name: http://skoolkid.github.io/jetsetwilly/reference/facts.html#weMustPerformAQuirkafleeg

It isn't perhaps something for the GUI to implement, as it isn't actually a separate cell type. With the changes that I made to the MM game engine in place, any Earth block can be butted away*. Rather, I envisage it would be something that might be implemented by ticking a box on the 'Game' Menu page in JSWED (like the 'Specials by room' patch), in order to implement the necessary changes to the game engine. (* However, Norman Sword's implementation of the feature, in the JSW game engine, is switched on on a room-by-room basis, using a flag in the border byte.)

Another side-effect of the above bug fix is that shuffling the code between #876F and #879F 'downwards' seems to confuse JSWED such that its GUI doesn't display the likes of vertical guardians or the solar beam (although they appear okay in the game itself). That might be resolvable by leaving those CALLS in with, NOPping out the CALL to draw the items from #876C and inserting it after the CALL to draw the portal at #879F by other means.

I've removed the previous 'Wraparound MM' test file from my earlier post, and re-uploaded it here, after making a couple of small tweaks to the Central Cavern: - Firstly, I had messed up with the positioning of the leftmost Fire block in the top cell-row of the cavern, which was intended to stop a shortcut (going straight from the bottom of the cavern by dropping through a hole to emerge at the top). Moving the Fire block one cell to the left has eradicated that shortcut. - Also, I have relocated one of the items, so that it now sits within the same cell as an Earth block. Now Willy has to 'mine away' the Earth block - by headbutting it eight times! - in order to collect the item This is very in keeping with the 'mining' theme of the game, is another novel aspect of gameplay, and is the sort of thing I had in mind when I first devised this feature (although calling it a "new cell type" in the topic header is probably a bit misleading, as Norman has pointed out - it's more of a new application of an existing cell type). Note also that I have changed the PAPER colour of the relocated item (something which is possible in the MM game engine, though not in JSW), in order to blend it into the wall better (whilst the other items, located in Air cells, retain their original PAPER setting). Please delete the previous version of the 'Wraparound MM' test file, if you've already downloaded it, and replace it with the one attached here. ****** A few more comments on the 'headbutt' feature: - Norman Sword gets joint credit for the implementation of the 'headbutt' idea. It works like the crumbly code in reverse, with pixel-rows disappearing from the bottom upwards. Using Norman's earlier notes as a basis, I have implemented it using shared code for both crumbling and headbutt effects, feeding in a variable beforehand using the C register (translated into either an INC H or a DEC H in order to progress through the pixel-rows). - For both the headbutt feature and the crumbly blocks, blank pixel-rows at the midway point through the blocks do not cause the block to 'disappear early' (i.e. attribute change to that of Air before all infilled pixels have been cleared), so there are no 'ghosts' left behind as can happen in the original MM game engine. (Thanks again to Norman for his rewrite of the crumbly code, which fixes the 'ghost crumbly' bug via a cunning use of a looped OR operation.) - Placing an item on top of an Earth block, as implemented in the updated version of the test file, is rather similar (in an opposite kind of way!) to a trick which is commonly used in Andrew Broad's games - namely, placing an item over a crumbly block, so that Willy can't collect the item by jumping up from beneath, but has to stand on top of the block in order to crumble it away to Air, before the item can be collected. Only this time, Willy has to jump up from below to bash away the block first. - I haven't tried this yet, but I suspect that if Willy jumps through an Earth block at head-height at the correct angle (i.e. an 'Innocent-Looking Block' as they're known in the trade), then one pixel-row could be removed each time he passed through the block in that way. So you could have a quirky situation where Willy has to jump through such a block up to eight times, in order to clear it completely! (e.g. to collect an item that is embedded in it?) - Other quirky possibilities could arise if the colour attribute of a cavern's Earth blocks is matched to that of another cavern element(s). ****** Note to self: try to implement a sound effect for both headbutting and crumbling blocks (a slightly different sound for each). Wraparound MM.TAP

A Manic Miner bug-fix: In the Main Loop, if the CALL to draw the items at #876C is shuffled down to after the CALL to draw the portal at #879F, then this fixes the 'persistent item' in the Sixteenth Cavern: http://skoolkid.github.io/manicminer/reference/facts.html#thePersistentItem (The destination of the JUMP from the Skylab routine at #8E7E, back to the Main Loop, also needs to be tweaked to point at #879C.) This change also means that you can have items located in the path of vertical guardians, without the guardians colliding with the items and killing Willy! However, it will have the following side-effects: - White vertical guardians can collect items (as well as white horizontal guardians, which can occur in the original MM game engine); - The solar beam can collect items; - You can't place a 'hidden' item within/behind a portal - it is drawn in front of (i.e. after) the portal, whereas Willy is drawn behind (i.e. before) the portal, making the item uncollectable* (and the cavern therefore impassable!) (*Unless the portal has white INK, I guess, but that would mean that the portal would 'auto-collect' the item upon entry to the cavern, and so that item would never get drawn anyway.)

I've just attached it - try again. :)

I'm pleased to be able to announce that I've managed to rewrite the 'Move Willy' and 'Draw Willy' routines in the Manic Miner game engine, in order to allow Willy's sprite and attributes to wrap around the screen, both vertically and horizontally. Whilst I was at it, I added the 'headbutt' facility for clearing wall tiles/Earth cells. In the attached test tile, only the Central Cavern has had its layout affected to showcase these changes to the game engine. But I would suggest that the changes could be exploited more widely in the 'Manic Mixup' project (currently being worked on in the Contributor Lounge). EDIT: The test file is now attached to a later post in this thread.

Try walking up the 'West Wing' ramp into 'West Wing Roof' with POKE 63154,209 in place.

Update: you would need to preserve A (e.g. by bookending the new code with two EX AF, AF' commands), so that after the loop has ended, A still holds a cumulative tally of all the infilled pixels in the cell.

Mickey, I don't know if you ever managed to implement a fix for the above, but I've just managed it - please see the attached file, collect the single item in the Master Bedroom and see what happens! I think it looks more 'realistic' - I wonder if this is indeed "as manufacturer intended"? ;) (In the attached, I've also prevented the anomalous behaviour of the 'P' key during the toilet run, and I've also fixed the 'Jagged Finger' display problem, because it was even more prominent when Willy was changing animation-frames whilst running at double speed.) Proper Toilet Run.z80

Some interesting philosophical points there, Danny! Although it could be argued that, if the Up exit from Rescue Esmeralda to Ballroom East is a valid route, then so is using WRITETYPER to access any room! Perhaps that is even more valid, as Matthew obviously intentionally implemented WRITETYPER, whereas the Esmaralda/Ballroom shortcut may have been an unintentional mistake. In fact, this discussion has led me to consider that shortcut further, and as a result I may have come up with a rationale for it..? Rescue Esmeralda is Room #0E in hex (that's 14 in decimal), and Ballroom East is Room #14 in hex (20 in decimal) - perhaps the Up exit from Esmeralda was supposed to be set to itself*, and Matthew got his hexadecimal and decimal systems mixed up on this occasion? (*Maybe the room even had a rope in it at one point of development, so the setting was supposed to prevent Willy climbing up to the top?) In relation to the Watch Tower, I believe the Up exit to the Off Licence was probably a simple case of the default value being #00, and of course the Off Licence is Room 0.

Another way of phrasing what I was trying to say in my previous post: I think* that this project may be rather akin to Andrew Broad's 'Advanced MM/JSW Trainer' tool. e.g. If you were in the 'Innocent-Looking Block' room, and managed to collect an item via another method (which Andrew hadn't anticipated) that didn't involve jumping through an Innocent-Looking Block, then the purpose of playing that room (namely to learn about ILB's) would remain unfulfilled. (* Admittedly without having actually used Andrew's AMJT tool - not for lack of trying to install it!) Anyway, at some point I'll probably provide walkthrough recordings of my own, with commentary to point out any features that you may have missed.

The primary aim of this project was to exhibit the different behaviours of the two variants of the game engine, hence my suggestion to seek out different solutions to each pair of items. However, in relation to your comment about efficiency, I would suggest that the alternative solutions would indeed provide a more speedy walkthrough.

Thank you for the recordings Danny, I've watched them now - good stuff! However, you didn't quite comply with the mission that I set - to use different collection methods for each of the 16 pairs of items. If you would care to do so, please try and find alternative solutions in the 'Before' game for: - The lowest three items in 'On top of the House'; - The rightmost item in 'Emergency Generator'; and - The item which is located above the first 'e' of 'Generator' (it lies at the left of an Earth platform which is three blocks in length). Other points of interest (all relating to the 'Before' file): - You managed to collect the bottom-left item in The Attic in a rather different way to the one that I had in mind (and which I hadn't thought of); - I wonder did you attempt (unsuccessfully) to collect the uppermost item in 'Dr Jones...' by jumping onto the elephant's back? It exhibits an interesting difference in Willy's behaviour between the two files; - The upper part of 'The Attic' in the 'Before' file is 'Forbidden Holy Ground' (whereas it is accessible in the 'After' file).

Well done Danny! I'm heading out now, but I'll watch your recordings later. If you haven't already, it's interesting and instructive to try and collect each item using the 'wrong' method for each game file, to see how the differences in the 'Willy mechanics' manifest themselves.

Norman, I have now managed to achieve a rewrite of Willy's movement code which allows him to make jumps into 'cut outs' between underfoot and overhead wall blocks, such as the ledges in the Wine Cellar, AND which preserves the smooth arc of Willy's jumps, avoiding the sudden 'jerking downwards' as he hits a wall which you described above. All of which is implemented in a symmetrical manner, with shared code for both leftwards and rightwards movement. ;) Please see the file titled 'After Comprehensive Willy Movement Rewrite', attached to this post: http://jswmm.co.uk/topic/415-comprehensive-rewrite-of-willys-movement-code/?do=findComment&comment=9109 N.B. Achieving this required a redesign of the following: - the 'Move Willy (1)' routine [deals with vertical movement - a modified version of the 'eject Willy downwards if his head enters a wall block' subroutine at #8EBC is used to eject him upwards if his feet enter a wall block!]; - the 'Move Willy (3)' routine [deals with horizontal movement, including along ramps - the changes were mostly taken from your code, as provided elsewhere in this forum, but with some minor tweaks - Willy's head can only enter a wall block if he is jumping and his Jump Counter variable holds a value of 17, one increment short of the end of the jump], and; - the 'Draw Willy' routine [to over-ride the tendency to draw Willy downwards whilst he is standing on a ramp if he is also standing on a wall tile - I drafted my own code for this purpose, although part of it was initially based on one of your contributions].

This 'mini-game' builds on earlier coding efforts by myself and Norman Sword (thanks for your unwitting contribution, Norman!) Attached is a zip folder containing two game files. The layout of the playable area of each file is identical (including the guardian settings and item placements). There are four playable rooms, all located in the upper region of Willy's mansion. The game contains a grand total of 16 items (#10 in hex!). Maria and the toilet are present - once you've collected all the items, make your way to the bottom of the ramp in The Attic to set off the end sequence. The 'Before' file is based on the original JSW game engine (with only a minor hack to allow the toilet dash to take place within the four rooms). i.e. the mechanics of Willy's movement are unchanged. In the 'After' file, I have implemented significant changes to Willy's movement, in order to prevent him from being able to pass through Earth/wall blocks in any circumstances. [The only exceptions to that rule are (a) if he enters a room at a position that happens to coincide with a wall, or (b) if he is swinging on a rope that passes through a wall - although I would add that neither of those scenarios pertains in the attached files]. All 16 items can be collected using different methods in the 'Before' and 'After' files, because of the differences in the mechanics of Willy's movement between the patched and unpatched variants. For some items, using two different manoeuvres between the two files is essential. For other items, one method might allow it to be collected in both files, with the alternative method only possible in one of the files. So your mission, "should you choose to accept it", is to use different solutions for each of the 16 items, across both of the game files. Oh, and without 'kamikazeing' any items (sacrificing a life in the collection thereof). Enjoy!! Comprehensive Willy Movement Rewrite.zip

Thinking about it, that latter change might mean that Willy is moved and drawn one more time before Game Mode 3 kicks in. Which wouldn't be too much of a problem is he is running towards the toilet, but might mean that he loses a life if he falls into the toilet as part of the end sequence? Area for investigation...

Some changes in logic in the Main Loop which could save a few bytes: - In between the existing commands at #89CC and #89CE, insert a JR Z, #89E9. Change #89CE and #89DE to unconditional CALLs. Then the commands at #89D9 and #89DC become unnecessary (net saving of three bytes). - Possibly the three byte command at #89E1 can be done away with too, if the commands at #89E4 and #89E6 are relocated prior to #89CE (the CALL to Move Willy). I would need to check that though, especially if another efficiency that I identified has been implemented: http://jswmm.co.uk/topic/185-free-space-and-code-optimisation-in-jsw/page-18?do=findComment&comment=8172 (The SET (HL) might have to be replaced with a RES (HL) to keep Willy running.) EDIT: I'm not sure about that bit so I've struck it out.

Just to clarify, the above isn't strictly true - the eight bits of C are rotated rightwards once by the operation. What I meant to say is that the RRC C command doesn't alter the balance of the number of set/reset bits in C, and so the balance of parity isn't changed by the operation; rather it tests what that balance is (i.e. whether an odd or an even number of bits are set), and then the conditionality of the subsequent jump is determined on that basis. Whereas the three preceding RR C commands did determine the balance of parity in C (because RR is a nine-bit rotation, bringing the Carry Flag into Bit 7 of the register), the RRC is an eight-bit 'internal' rotation of C (it also copies Bit 0 of C into the Carry Flag, but that is of no consequence here). N.B. It's easy to get mixed up between "RR C" and "RRC" - perhaps I should have swapped the roles of the B and C registers to reduce the prospect for confusion!?

A nice bit of detective work, Danny! One query: have you uploaded the same attachment twice, instead of two different files?

More analysis on the use of the Parity Flag in the above, for handling wraparound vertical guardians: C starts off holding 00000000 (Parity Even) Normal vertical guardian - three scenarios (other than a guardian located exactly on one of its bounds, which is dealt with by a separate check): TOP OF SCREEN GUARDIAN POSITION UPPER BOUND IN D LOWER BOUND IN E BOTTOM OF SCREEN C=01100000; Parity Even, guardian is out of bounds TOP OF SCREEN UPPER BOUND IN D GUARDIAN POSITION LOWER BOUND IN E BOTTOM OF SCREEN C=00100000; Parity Odd, guardian is within its permitted bounds TOP OF SCREEN UPPER BOUND IN D LOWER BOUND IN E GUARDIAN POSITION BOTTOM OF SCREEN C=00000000; Parity Even, guardian is out of bounds Wraparound vertical guardian - three scenarios (other than a guardian located exactly on one of its bounds, which is dealt with by a separate check): TOP OF SCREEN GUARDIAN POSITION LOWER BOUND IN E UPPER BOUND IN D BOTTOM OF SCREEN C=11100000; Parity Odd, guardian is within its permitted bounds TOP OF SCREEN LOWER BOUND IN E GUARDIAN POSITION UPPER BOUND IN D BOTTOM OF SCREEN C=10100000; Parity Even, guardian is out of bounds TOP OF SCREEN LOWER BOUND IN E UPPER BOUND IN D GUARDIAN POSITION BOTTOM OF SCREEN C=10000000; Parity Odd, guardian is within its permitted bounds

Several things needed to be done to achieve these wraparound guardians. - In the 'Draw a sprite' routine (#9456), I added a command after the code at #9482-85 [original addresses] which moves HL down from one vertical screen-third to the next. The command RES 4, H ensures that the guardian doesn't extend from the secondary pixel-buffer into the primary pixel-buffer, but wraps back round to the top of the former. i.e. a value #70xx is adjusted to #60xx. - Also in 'Draw a sprite', after the INC L command at #9462 [original address], I made a check to see if the right-hand half of the sprite is wrapping round to the left-hand side of the screen: LD A,L AND #1F If that sets the Zero Flag, then subtract #20 and load back to L, draw the graphic byte under consideration and then add #20 again before moving down to draw the next pair of graphic bytes on the next pixel-row. - The 'Draw a guardian' routine also needs to be adjusted, in a similar manner to the above, to keep the guardian's colour attributes within the same character row when it is wrapping round past the right-hand edge of the screen, and also to prevent its colour attribute being written permanently onto the primary attribute buffer when it is wrapping past the bottom of the screen. In the latter case, a RES 1, H command is used to adjust a value for the attribute coordinates of #5Exx to #5Cxx, which is back within the valid range. - In the 'Move the guardians' routine, a simple adjustment has been made for horizontal guardians at #9151 and #9174 [original addresses], in order to prevent the guardians from changing sprite (which previously occurred because the DEC (IX+$02) / INC (IX+$02) commands meant that the adjustment of the x-coordinate in Bits 0-4 was spilling over into the Base Sprite setting in Bits 5-7). Preventing this was achieved by loading the guardian byte definition byte 02 into both the Accumulator and the C register, then adjusting A accordingly for the appropriate direction of movement (e.g. applying a DEC A or an INC A, although in the test file uploaded above I have implemented the shared left/right movement code for guardians), and then doing the following sequence: XOR C AND #1F XOR C before reloading the result in A back to IX+$02. That adjusts the x-coordinate from #00 to #1F or vice versa, whilst leaving the Base Sprite setting unaltered. - The changes to the vertical guardians part of the 'Move the guardians' routine are the 'piece de resistance'! After the code which updates the animation frame for vertical guardians (or not, depending on the animation speed), I have devised the following [starts at #9193 in the original code], which was built upon an earlier draft of this part of the routine provided by Norman Sword: (Note that HL is pointing at guardian definition byte 00 going into this, after a pair of commands PUSH IX / POP HL.) INC HL INC HL INC HL ;HL points at guardian definition byte 03 (pixel y-coordinate) LD A, (HL) INC HL ;HL now points at guardian definition byte 04 (vertical speed) ADD A, (HL) LD B, A ;A and B now both hold the updated y-coordinate LD C, #00 ;C will be used to keep track of various flags LD D, (IX+$06) ;upper bound of guardian in D LD E, (IX+$07) ;lower bound of guardian in E CP D ;has the guardian moved past its upper bound? RR C ;rotate a raised flag into C if so CP E ;has the guardian moved past its lower bound? RR C ;rotate a lowered flag into C if so [or if it is exactly at its upper bound, but that situation is dealt with separately below] LD A, E ;load the guardian's lower bound into A CP D ;if this is a normal vertical guardian, then E>D; if it is a wraparound, then D>E RR C ;rotate a flag into C (raised only for a wraparound vertical guardian) BIT 7, (HL) ;is the guardian currently moving downwards? JR Z, down ;if so, skip the next command LD A, D ;otherwise, load the guardian's upper bound into A (the guardian is currently moving upwards) down: CP B ;has the guardian exactly reached the extent of its permitted range for the current direction of travel? JR Z, change_direction ;if so, then jump to toggle the direction of travel RRC C ;this command doesn't change the value in C, it merely test the status of the Parity Flag JP PO, y_update ;If Parity is odd, then jump to update y-coordinate with the value stored in B (the guardian is within its permitted range) LD B, A ;otherwise, if Parity is even, then the guardian has exceeded its permitted range, so load up B with the extent of its permitted range for the current direction of travel change_direction: LD A, (HL) ;load vertical speed into A NEG ;toggle it to reverse the guardian's direction of travel LD (HL), A ;and load back into guardian byte 04 y_update: DEC HL ;HL points at guardian definition byte 03 again (pixel y-coordinate) LD (HL), B ;update the guardian's y-coordinate with the value stored in B That is then directly followed by (or a jump is made to) the existing command LD DE, #0008 at #91B6. I'll add some commentary about the use of the Parity Flag when I get more time.