IRF

I should add that your more efficient solution wouldn't work in Manic Miner (if you were using the air supply variable #80BD to keep track of when to advance through the tune), because bit 2 of #80BD acts as the game clock, not bit 0. You would have to rotate the bits of A (twice) after the AND #04, eliminating the byte saving.

That's similar to my solution, but not identical. You seem to have a spare byte in there, so you could afford to retain the original two-byte LD D, #00 command, instead of the single-byte LD D, A. That would mean the patch isn't reliant on A having been reset to zero beforehand. (Since a lot of game designers ditch the preceding inactivity code which sets A=0.)

Overnight, a couple of other things have occurred to me in relation to the above patches. In relation to the JSW patch, there's no need to use the trick of initialising the music note index to #FF at the start of the game - that might actually cause the game to begin by playing the last note of the tune first! (if the conditionality of the relative jump is such that the note index isn't incremented during the first pass through the Main Loop). And for the MM patch, because of the fact that the initial air supply differs between caverns (some start off holding an even number of units of air; others start off with an odd number), that patch will mean that in some caverns the first note will be played shorter than usual. That can be fixed by ensuring that all caverns start off with either an even or an odd number of air units (bearing in mind that a single air decrement is a value of 4). EDIT: D'oh! Sorry, that second point isn't an issue unless your game initialises the music note index at the start of each cavern. Which doesn't happen in the original Manic Miner - ITHOTMK just carries on where it left off after you go through a portal to the next cavern. But I suppose it might be the case if someone were to devise a game with a different tune for each cavern, and they wanted each tune to begin playing with its first note as the player encounters them.

Okay, with a bit more rearrangement, this should work to enable a 256-byte in-game tune for the Manic Miner game engine - insert the following at addresses #883A to #8851: LD A, ($80BD) - lower byte of the air supply AND #04 - test bit 2 LD HL, #845B - point HL at the music_note_index variable; NB this doesn't affect the Zero Flag JR Z, #8845 (or JR NZ, whichever polarity doesn't cause the first note to be missed or curtailed upon game startup) - conditional relative jump past the next single-byte command INC (HL) - the conditional jump prior to this command will ensure that the code which increments the music note index is only executed when the game tick counter holds either an odd or an even value, thereby slowing down the rendition of the tune. LD E, (HL) - pass the value of the music note index to E LD BC, #0003 - this command was previously at #884F LD D, B - resets D to zero in a single byte LD HL, #858C - point HL at the table of tune data ADD HL, DE - adjust HL to find the current note LD E, (HL) - pick up the note pitch value LD A, (#8073) - pick up the current cavern border colour Then #8852 onwards is as normal.

P.S. If you have already recycled the 'inactivity code' (#8B3C-3F), then you'll need to find an extra byte from somewhere else (two bytes to define LD D, #00 but you won't need the earlier single-byte LD D, A command). EDIT: In fact, if you're trying to apply this to a Manic Miner game then you'll have to find an additional byte from somewhere anyway, as the inactivity code doesn't exist in that game engine. FURTHER EDIT: Actually, you would have bigger fish to fry if you're trying to implement this in a Manic Miner game. The code in my previous post relies upon the minute/tick counter (#85CB in JSW) to decide when to increment the music note index. But there is no similar minute counter in the MM game engine. So you would have to introduce one (it wouldn't need a whole byte; just a single bit which acts as a flag and toggles between set & reset (probably via a XOR) every time that the Main Loop is executed. I suppose you could use the lower byte of the air supply variable (#80BD) for this purpose - it is decremented by a value of 4 each time, so you would have to test bit 2 (AND #04) for the purpose of playing the music at the regular speed. Or you could test bit 3 (AND #08) for an even slower rendition. But then you might have an odd effect in the solar cavern whereby the music either occasionally plays faster, or else gets stuck on the same note, whenever Willy is inside the solar beam? But then I suppose that could be quite a fun, quirky effect!!

The simplest way to have a 256 byte in-game tune is this: Extend your tune data to 256 bytes. Then just NOP out the commands at #8B47 and #8B49. **** However, that by itself will cause the tune to play too fast (as the note counter will be incremented during every pass through the Main Loop). To slow it down to the regular speed, a bit more editing is needed. Insert this into the range of addresses #8B40-#8B4C: LD D, A (for the addition later on - N.B. this assumes that A is still set to zero as a result of the command at #8B3C) LD A, ($85CB) (game_tick_counter variable) AND #01 (test bit 0 of the game tick counter) LD HL, #85E1 (point HL at the music_note_index variable; NB this doesn't affect the Zero Flag) JR Z, #8B4C (or JR NZ, whichever polarity doesn't cause the first note to be missed or curtailed upon game startup) - conditional relative jump past the next single-byte command INC (HL) - The conditional jump prior to this command will ensure that the code which increments the music note index is only executed when the game tick counter holds either an odd or an even value, thereby slowing down the rendition of the tune. LD E, (HL) - the conditional jump above jumps to here if the condition is met Then #8B4D onwards is as normal. P.S. You could check that part of the Main Loop in the Jet Set Mini code to see the above in situ.

First paragraph - that's how I feel whenever I hear the short, 64-byte version of the Radetzky March in-game tune, after having implemented a 256-byte version (score courtesy of Richard Hallas) in Jet Set Mini. How to achieve a 256-byte tune? I'll get back to you - although the answer may be in an earlier post of this thread?

If I Were A Rich Man. And ITHOTMK = In The Hall Of The Mountain King.

In the case of 'In the Hall of the Mountain King', I believe I did that classical piece of music justice in 'Manic Mixup' - implementing a quite faithful 128-byte loop during gameplay (which doubles in speed of play when the air supply in each cavern reaches the 'red zone' - replicating the way that ITHOTMK gains pace towards the end), and a coda that is played during the 'cavern completion' sequence (when Willy goes into a flashing portal), which matches the finale of Greg's original composition. 😎 I look forward to hearing what you've done with it, and also your extended rendition of 'If I Were A Rich Man'. 😊

I devised a similar setup for my long-gestating (currently in abeyance) project: 'Willy's Recurring Nightmare':- If Willy enters a new 'tune zone', the music note index is reset so that the new tune starts from the first note. (Incidentally, the music note index is set to 0, not to 1 as it is in the original JSW, in which the first note of IIWARM is curtailed when you first start playing a new game.) But if you enter a new room within the same tune zone (or lose a life), then the existing tune carries on seamlessly. I also added another feature - if you enter a new tune zone, the 'tune on/off' flag is reset so that the new tune starts playing even if the player had opted to turn off the music whilst Willy was in the previous tune zone. I figured that this would increase the exposure of the individual tunes - I appreciate there's a danger that it might annoy a player who wants to play without any music, but then they always have the option of just muting their laptop (if they're playing on an emulator, as most people do these days).

This cavern is interesting, in that it is both possible and impossible to complete the cavern without losing a life! A kind of Schroedinger's cavern! If you know what I mean?

I don't believe the portal in that cavern reveals itself during the 'lose a life' screen flash effect, although there is another visual effect during gameplay which helps you to locate the portal (which is at different position in the easy and hard variants!) - and having done that, Willy ends up in a position where there is no way out other than by sacrificing a life.

On that note, I recall that I was a bit precious about 'spoilers' immediately after the release of some of the games I was involved in a few years back. But I'd be happy for JSW Central to include screenshots of all the rooms in Jet Set Mini, Manic Mixup, etc, at a time of your convenience. (If they're not already there.)

Further to my previous post, I've refreshed my memory of the cavern layout (thanks to the screenshot on JSW Central, an ever-useful resource!), and it was the following aspect of the game engine that helped me to solve the cavern: Because...

I've just noticed that cryptic comment of mine from a couple of months ago, and I'm trying to remember what I was referring to! I think it was something to do with the way that items are drawn in the moment of Willy losing a life. From memory, I think there's a slight difference in the sequence of when an item is drawn in the main loop? Or maybe it's to do with the fact that each item is assigned its own PAPER setting in MM, as well as its own INK setting (which cycles through a palette of colours) - whereas in JSW, the INK colour cycles through the palette but that is then superimposed on the PAPER colour of the air cells for the host room. Anyway, the net effect was that I was able to solve more easily the puzzle in the cavern in question, in Manic Person, because... I think if the JSW game engine was operating, the would have remained

It looks like you have to exploit a game engine bug/quirky feature in order to be able to collect the uppermost item in that starting room.

It looks like there's no time pressure from the yellow horizontal guardian. Once you get past it you can take your time advancing forward to make the next jump, as its rightmost reach doesn't extend that far?

Intriguing! I will download and explore the game at some point in the near future. When I was first reading through the back story, I started wondering if the mission might be for Willy Jnr to rescue a captured Willy Snr... That wasn't the case, but it could be the basis of some future game?

Looks good! The colour-coded fall height peril is an interesting concept, but I wonder what happens if you fall from a great height in a 'green' room, off the bottom and land in a 'red' room. Or vice versa, if you fall a long way through the bottom of a 'red' room but you land in a 'green' room? 🤔

Yes it was indeed the > symbol which made me think of it as a new cell type. Perhaps we could call it a 'pseudo-cell'? (The pseudo prefix meaning false.) I see what you mean about 'throwback' not covering all possible behaviour. I can imagine some interesting potential applications of it (where overhead blocks mean that jumping over it isn't an option) - for example, its sudden effect could throw the unsuspecting protagonist straight into the path of a guardian, or conversely, timing it well could allow the player to skip past a guardian which on the face of it blocked any progress on that direction. With those scenarios in mind, a 'Displacement (pseudo-)Cell' might be a better description? And of course it would be perfectly easy to have one with a < symbol that worked in the opposite direction.

Makes sense now - I thought you meant you wanted to put it somewhere else (blocking the safe route to the large cluster of items in the middle of the room, meaning that you would have had to drop down through the items to collect them before dying upon landing as it's too great a drop). I think Sendy was right that your idea would have had adverse consequences for Quirkafleeg 2 - as it happens, I first discovered that room coming in from the left (from West Lookout), so it presented quite a puzzle - how to cross it when the rope doesn't swing? - until I subsequently discovered the 'eastern approach' to Q2. The mystery of the (initially) non-swinging rope would never have presented itself to me in the scenario you originally had in mind.

I think I'm right in saying that putting the feature in 'West Lookout' (towards the bottom-right corner, presumably?) would have meant that some of the items in that room couldn't have been collected without sacrificing a life? (That's assuming the layout of that room hasn't changed since that consideration was being made; it may well have changed since the decision was made to relocate the novel feature to 'West Wing'.)

I would say it's a new cell type implemented by a patch (vector), as opposed to being one of the standard cell types available in the regular game engine. In Jet Set Mini, I implemented several non-standard cell types via the patch vector system - though none of them displayed the behaviour that this one does. Did you or Sendy coin a name for this one? If not, are you open to suggestions? (A Throwback Cell, perhaps?) It's very quirky!

I've just noticed there's a new* cell type in the room 'West Wing' in JSW: Role Reversal. Try walking over the cyan block at the bottom left corner of the room... EDIT: Well, I'd not seen one of these before.

I just made a new observation about the Manic Miner game engine, whilst playing around in one of the caverns of Manic Person. When Willy dies by falling from a great height, or by hitting a Fire cell or a guardian, then during the brief flash of the screen as he dies, the portal is not drawn. However, in contrast, if Willy dies because the air supply runs out, then the portal does get drawn in that brief instant. This observation proved to be quite useful in solving part of the cavern's puzzle. However, I won't say which Manic Person cavern it is yet, as I don't want to provide a spoiler so soon after the release of the game. However, I will add another cryptic comment - there's another part of the puzzle in this cavern which wouldn't work so well in the JSW game engine as it does in a MM game. I will reveal all in time...