IRF

I noticed that the movement keys to climb up or down a rope have been reversed (in relation to the direction that the rope is swinging at a particular moment in time). That takes a while to get used to!

I've made a minor variation to the previous file - see the attached. The patch* has been re-written slightly more efficiently, saving three bytes. And in the test room I've put all eight ropes into adjacent pixels (the top segments are all located within the same cell-column, although they could just as easily have straddled two columns), so the composite whole now resembles a swinging rope ladder. That can be scaled back to achieve a 'fat rope' by having, say, just two ropes sitting adjacent to each other, one pixel apart - which would have the benefit that it doesn't slow the game down to the same extent (as well as only requiring two guardian instances, of course). EDIT: *I forgot to say last night: the patch for this and last night's test file is contained in a subroutine at #9718 (which is CALLed from #92AC, near the start of the 'Draw the Ropes' code). Swinging Ladder Test.z80

I must admit that the 'new' Solar Beam is the least developed of the four 'Specials', as all I did was fix the bug which means that sometimes it doesn't kill you instantly when the air supply runs out. However, In terms of enhancing the Solar Beam with something 'a bit different', Norman Sword has come up with the goods in his Manic Miner rewrite by giving the Beam a neat 'sapping' sound effect whenever Willy stands inside it. :o ****** Another thing which I should mention is that, in order to achieve the maximum flexibility in the 'Skylab/Droplet regime', I had to redivert one of the Eugene Guardian Types to a different number (i.e. a different value for Definition Byte 0). Non-colour changing Eugenes are now classed as JSW64 Special Guardian Type #48 instead of Type #18. Type #18 was reassigned for use by leftwards-moving Skylab/Droplets. This was essential in order to prevent the 'Draw the guardians' routine from picking up incorrect frames of animation for some of the Skylab/Droplets. (Type #08 is used for rightwards-moving Skylabs and for 'horizontally static' Droplets, whilst Type #78 has been freed up for other purposes. Previously, Type #08 was used exclusively for 'standard' Skylabs, and Type #78 was used by John Elliott's original Droplet Patch.)

Please see the attached test file. PREAMBLE: In 'Jet Set Mini', I managed to implement perfectly laterally-inverted ropes, partially by changing the position of the top segment of each rope within its host cell. (i.e. In original JSW, the top rope segment occupies the leftmost pixel in the defined start-column; whereas in 'Jet Set Mini' the top rope segment occupies the rightmost pixel.) This test file extends that concept further. I have slightly rewritten the 'Draw the Ropes' routine, so that the precise horizontal pixel-position of the top of each rope in the game may be specified separately. i.e. on a 'rope instance' basis. The pixel position of the top segment is stored in the highest three bits* of Byte 2 of the Rope Definition (which is copied over, from the second byte of each rope's specification in the room's guardian list, when the 'Room Setup' routine is executed). The value of that three-bit number is then translated into the correct pixel to infill for the top segment, using a similar principle to that which is used in Manic Miner to draw the remaining pixels of air supply at the right-hand end of the air bar (except that I've used the RLC E command here, instead of RRC E, and there is no setting of additional bits during each pass through the DJNZ loop). Within the the start-up room (Swimming Pool) in the attached file, there are eight** ropes which are very closely spaced horizontally (only three pixels apart). I have called this effect a 'Swinging Curtain', as that's what I think it looks like! Note that the game is slowed down somewhat in the room in question, because of the need to perform eight complex rope-drawing operations during each time-frame. ****** * One consequence of this change is that you lose the ability to create an 'Invalid Rope' like the one in the 'Overgrown MegaTree' in 'Jet Set Mini' (the top segment of which is drawn further down the screen than is usually the case, because I assigned an 'invalid' value [greater than #1F] for the x-coordinate of the top segment of rope, in the room's guardian table). However, that's probably not a great loss - Invalid Ropes can be very 'quirky', especially if they extend down beyond the boundary between the top and bottom half of the playing area, which causes segments to appear in strange places (the one in 'Jet Set Mini' is sufficiently short to prevent this from happening). ** Note that because there are eight ropes present in the room, it can be quite difficult to dismount the ropes/curtain! The 'Draw the Ropes' routine usually allows Willy 16 time-frames to elapse, after jumping or falling off a rope, before he can be caught by a rope again. However, with eight ropes being drawn consecutively in each time-frame, that reduces to two time-frames! (Although that is not a result of the changes that I made in the attached; it is a curious feature of the JSW game engine, and would be the case in any JSW room with eight ropes.) Swinging Curtain Test.z80

The new sound effects are good, particularly the one which occurs when Willy stands in the Solar Beam. :) Incidentally, I notice that you have fixed/eradicated/prevented the bug in the original Manic Miner which meant that Willy didn't always die as soon as the air supply ran out if he was standing in the Solar Beam at the time. (i.e. The final character of air could reappear, and be re-depleted, several times before the air supply - and Willy! - finally expired.)

Okay, 'patch' wasn't the right word - I was going to say 'bug fix' but I wasn't sure that the 'Jagged Finger' effect is classed as a 'bug'? (You originally referred to it as a 'flaw'.)

Am I right in thinking that you've implemented the patch which re-orders the way in which the graphical bytes and attributes are copied across from the buffers onto the physical screen? The 'Jagged Finger' effect is much less pronounced, and the attributes don't seem to lag behind the graphics to the same extent. This is particularly noticeable in 'Eugene's Lair', where previously Willy's head/feet, and parts of the yellow toilet guardian, could momentarily be observed to turn black at times (because the background INK in that cavern is set to black, whilst the background PAPER is non-black), but now that phenomenon is almost eliminated. :)

The alternative style of jumping and movement is similar to that found in JSW2, I believe? (e.g. the ability to turn around more quickly in between sideways jumps in opposing directions.) Although I don't think it is identical to JSW2 movement? (In JSW2, Willy progresses an additional frame of animation at the end of a sideways jump, in contrast with JSW/MM, or with this MM remake.)

Please see the attached test file, based on the JSW64 game engine, which features experimental/novel implementations of each of the four 'special' Manic Miner 'guardian' types. Skylabs/Droplets: The opening room, a modified version of 'The Bridge', features an unprecedented mixture of 'standard' Skylabs, and Droplets of various types, all operating simultaneously. (They don't actually pose a threat to Willy in this test file, unless he jumps up and hits one.) All of the Droplets display distinct behaviour: - The white Droplet doesn't have any horizontal displacement in between consecutive incarnations, and drops down consistently in the centre of the screen; - The yellow Droplet has a horizontal displacement of 16 columns, so that it alternates between two positions half a screen-width apart; - The cyan Droplet has a rightwards horizontal displacement of 8 columns, so it progresses from left to right across the screen through four possible 'drop zones', just like the classic Skylabs in Manic Miner; - The green Droplet has a leftwards horizontal displacement of 4 columns, so it progresses from right to left across the screen through eight possible 'drop zones'. N.B. the starting columns of all four Droplets have been carefully selected so that they shouldn't ever collide! Angry Eugene: If you walk rightwards from the start-up room and enter 'The Off Licence', there is a vertical guardian which displays 'Eugene' behaviour, but with a twist... Your mission is to try to collect the item and escape safely from the room (it's a 'No Kamikaze' room, so the item will be reinstated if Willy loses a life before exiting). I suggest that you first try walking rightwards into the room without stopping, proceeding under the guardian and up the ramp, then jumping to collect the single item as soon as possible, and watch how events proceed. Then try taking a bit more time before collecting the item, and see the difference. Solar Beam: If you walk leftwards from the start-up room into 'Under the MegaTree', you can see that I have implemented a fix for the Solar Beam Bug which meant that, in original Manic Miner, the Solar Beam did not always kill Willy as soon as the air supply ran out. i.e. in this test file, the Solar Beam does kill Willy at the instant when the air supply is depleted to zero. Ditto for the Kong Beast (see below). Kong Beast: There is also a Kong Beast in 'Under the MegaTree' that displays a novel feature, the idea for which was inspired by the following exchange between John Elliott and Andrew Broad in a post on the Yahoo Group: Well, in the attached test file, there is an incentive to kill the Kong Beast - because it also saps Willy's air supply in 'Under the MegaTree'! See how quickly the air supply is being depleted in that room, even when Willy isn't standing in the Solar Beam! (N.B. The 'lethality' of the Solar Beam and of the Kong Beast can be set independently of each other.) In order to survive in 'Under the MegaTree' for more than a few seconds, it is necessary to flip the Switch (the yellow thing in the branches at the top-left, which uses 'Willy's head' as its sprite) and thus kill the Kong Beast. Note that there is a handy flashing Portal which provides a shortcut up to the Switch from the bottom of the screen, and Willy's progress is further assisted by the room's Portal Patch Vector, which automatically sets him jumping leftwards as he exits it - another technical novelty, I believe? - so that he lands just a few steps away from the Switch! Note that there are also a few bug fixes implemented in the attached test file, including some tweaks to the Kong Beast code to make it more 'generic' (for instance, making the Kong Beast's animation dependent on the global 'tick' counter rather than the current air supply, so that Kongs are still animated even if they appear in rooms without an air supply limit), and a patch for the bug in JSW64 which causes the Air Supply bar to become invisible (albeit still operational!) when you pause and unpause the game (something which remains in Dr Andrew Broad's 'to do' list for his 'Advanced JSW/MM Trainer project!). ****** A final word: I was wondering whether the scale of the interventions in the attached file (if they were extended to all six JSW64 variants) would mean that it could perhaps be considered to be a 'Hack Level 13' of the JSW64 game engine? Any thoughts? MM Specials Test File a JSW64X v.0.01 HL 12.tap

I've just noticed that the 'Willy is falling' sound effect in Manic Miner is somewhat different from the equivalent sound effect in JSW (in terms of how the pitch of the sound 'loops') - I don't know how this fact had escaped my attention for so long!! :blush: EDIT: In JSW2 it's different again (and different for jumping as well) - the pitch seems to be determined by Willy's current y-coordinate in JSW2.

At least one of SkoolKid's patches makes use of some of the commands in the TRS code, in order to minimise the number of POKES required by the patch.

I've edited the first post in this thread (and the link to the download) to make it clear that 'Ligan' is the third party author, in accordance with his earlier confirmation that this is the case. :)

I've just posted this on the MM&JSW Yahoo Group; I thought it would bear repeating here:

My 12 POKE fix for the bug that occurs when the air supply runs out whilst Willy is inside a Solar Beam, could've been done in 10 POKES (SkoolKid's self-declared upper limit), if only I hadn't taken care to tidy up the stack!

There's plenty of room on the stack, so it's only a hypothetical concern really. But it's good programming practice not to let the stack build up in that way.

I think that will cause stack build-up over time. It would be better to edit the jump address to #8FDB (Software Projects version; may be different for other versions), to clear the RET address.

So 'ASAP' is actually a bit too soon in the circumstances then!

On that note, try POKE #CE6A, #02 and POKE #CE6B, #01 and then enter 'Miner Willy meets the Kong Beast'. I haven't tried it out yet, so it will either give the player a helping hand or lead them to infinite death...

Well spotted! I would add: #E269, #03 #E669, #03 #F269, #00 to sort out the animation frames.

I believe that in a game with fewer than 256 collectable items, it would be possible to use the spare range of addresses at the top of pages #A4 and #A5 for other purposes. However, extreme care would need to be taken if subsequent editing of the item definition bytes is carried out - individual entries would need to be edited in the hex editor. If items are deleted in the JSWED GUI, then all other entries above in the item tables are shunted down, which would mean any Patch Vector subroutines would be brittle. A 'safer' use of the spare addresses at #A4xx / #A5xx would be for data such as graphics, or an in-game tune. (I resisted the temptation to use the spare bytes in this range when working on 'Jet Set Mini'.)

And with another three POKES that I've just come up with, you can also have an initial value of 0,1,2 or 3 for the game counter, without causing the aforementioned glitch: POKE #86DA, #23 POKE #86DC, #24 POKE #9F23, #52 EDIT: In decimal that's: POKE 34522, 35 POKE 34524, 36 POKE 40739, 82 The first two POKES adjust the 'Cavern entry' routine, so that the entire air supply bar is drawn, in the first instance, one character further to the left. Whilst the third POKE 'disguises' the leftmost character of air supply, by assigning Bright red INK (as well as red PAPER) to the 'blank' character in between the word 'AIR' and the air supply bar. So the air supply is now drawn across the 'blank' character to the right of the word 'AIR', but this isn't visible on the status bar, because the INK and PAPER settings for that character are identical. Meanwhile, the rightmost character of air supply isn't drawn until the first pass through the Main Loop, at which point only the correct number of pixels of air are filled in (and there is no danger of leaving any pixel undeleted by setting the game counter to zero at the start of the cavern). And the air supply still runs out when the character of air at address #5A24 in the attribute file has been cleared of pixels, just as before (there remains one character of air bar left undeleted at that point, but it is invisible to the player). With the above POKES as well as Norman's in place, a cavern can have any pair of values at Offsets 700/701 within the range from '#25 #00' [a single character of air = 64 time-frames] to '#40 #00' [28 characters = 1792 frames], without causing a glitch or freezing up the game. EDIT: With a single POKE #86E2, #25, you can have any value for initial air supply from #26 #00 [two characters of air = 128 time-frames] to #40 #00.

Am I right in thinking that using a one-byte DEC A wouldn't work in lieu of the two-byte SUB A, #01 ; because the INC and DEC instructions don't set the Carry Flag? (And therefore the conditional jump which follows won't be triggered when the value of A wraps round below zero.)

I think the 'c' should be lower case, or else the 'G' and 'L' from 'Grid Location' should be upper case for consistency.

SkoolKid's excellent assemblies, available in both decimal and hexadecimal. :)

John Elliott's cunning and efficient use of the Stack Pointer register, in his code which handles Triggers in JSW64, can only be described as audacious! :o