IRF Posted January 4 Author Report Share Posted January 4 (edited) 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!! Edited January 4 by IRF jetsetdanny 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted January 4 Author Report Share Posted January 4 (edited) 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. Edited January 4 by IRF jetsetdanny 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted January 5 Author Report Share Posted January 5 (edited) 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. Edited January 5 by IRF jetsetdanny and Spider 2 Quote Link to comment Share on other sites More sharing options...
Spider Posted January 5 Report Share Posted January 5 Nopping out #8B47 and #8B49 would do but its too fast then. So... XOR A ;8B3C ; clear the inactivity timer at L85E0 LD (inactivity),A ;8B3D ;L85E0 LD D,A ;8B40 ; initialise the mSB LD a,(game ticker) ;8B41 ;L85CB the game ticker at 85CB AND 1 ;8B44 ; issolate odd or even game ticker bit LD HL,(ingame_music) ;8B46 ;L865F set HL to the music offset pointer LD E,(HL) ;8B49 ; get the present offset ADD A,E ;8B4A ; add the ticker (odd/even) value LD (HL),A ;8B4B ; store the updated offset NOP ; 8b4C ; back to the original code LD HL,ingame_music ;8B4D ;L865F ADD HL,DE ; 8B50 ; >>> HL IS POINTING AT THE NOTE value IRF, jetsetdanny and Norman Sword 1 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted January 5 Author Report Share Posted January 5 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.) jetsetdanny and Spider 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted January 5 Author Report Share Posted January 5 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. Spider and jetsetdanny 2 Quote Link to comment Share on other sites More sharing options...
jetsetdanny Posted January 5 Report Share Posted January 5 13 hours ago, IRF said: 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. That's exactly what happens in "Manic Person"! IRF 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted January 6 Author Report Share Posted January 6 1 hour ago, jetsetdanny said: That's exactly what happens in "Manic Person"! Indeed! Only 64 bytes per tune though. If you had 20 tunes of 256 bytes each, that wouldn't leave much room for anything else! jetsetdanny 1 Quote Link to comment Share on other sites More sharing options...
jetsetdanny Posted January 6 Report Share Posted January 6 11 hours ago, IRF said: Indeed! Only 64 bytes per tune though. If you had 20 tunes of 256 bytes each, that wouldn't leave much room for anything else! Exactly. Even with 64-byte-long tunes there was no room left for any extras. A suggestion was made after the game was released that it could do with a non-standard font. It was a very good suggestion, but unfortunately impossible to apply without far-reaching changes to the game engine that would optimise the code 'a la Norman Sword' and free up enough space to implement a new font. IRF 1 Quote Link to comment Share on other sites More sharing options...
jetsetdanny Posted January 6 Report Share Posted January 6 Ian, I never thanked you for answering my request and for all the information and code solutions you have provided! Thank you so much, it is all greatly appreciated! 🙂 👍 I remember once in the past I did have a look at the Jet Set Mini code, but couldn't make enough sense of it to be sure what you had done there. I probably didn't try hard enough (I didn't need a 256-byte-long tune 'seriously', I was only toying with some ideas). In any case, it's great to have everything explained plainly in this thread! So thanks again 🙂. Spider and IRF 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.