IRF

It did strike me that there's still some repetition of code in my rewrite - the use of D and then E as pitch delay counters for the two notes could possibly utilise a shared subroutine, if the registers were swapped about carefully? Oh, I presume that there's a comma missing in the last post: "My final edit for the overall Manic Miner Music routine is around 57 bytes smaller than the Music routine from post #0" should read "My final edit for the overall Manic Miner Music routine is around 57 bytes, smaller than the Music routine from post #0" - unless you've managed to compress the routine down to 14 bytes in length! :o

This doesn't relate to code optimisation, but it's an observation about a bug/glitch/peculiarity in the original Manic Miner. When the title screen tune is playing, there is a pause towards the end (enacted by having a pair of 'zero notes', at #8541 and #8542). You might expect that none of the piano keys are highlighted at that point, since no notes are being played, but in fact the left-most key of the piano is highlighted (in cyan). I know that the positioning of the coloured keys isn't actually representative of the notes that would be played on a real piano, but the above seems particularly incongruous.

I thought I might create a similar 'optimisation' thread to the JSW one. I implemented a lot of code optimisations of the MM game engine in the recent release 'Manic Mixup'. However, this one slipped through the next (I've only just thought of it): It involves a rewrite of the routine at #92DC which plays the theme tune (Blue Danube). I think this saves around 12 bytes. EDIT: It actually saves eight bytes. (I forgot to count the CALL to test the Enter key, and the RET back to the Title Screen routine if Enter is pressed.) start: LD A, (IY+$00) INC A RET Z LD BC, #5028 CALL update_piano_keys LD B, #00 LD C, (IY+$00) LD H, D LD L, E tune_loop: OUT (#FE), A DEC D JR NZ, not_time_for_note_1 LD D, H XOR #18 not_time_for_note_1: DEC E JR NZ, not_time_for_note_2 LD E, L XOR #18 not_time_for_note_2: DJNZ tune_loop DEC C JR NZ, tune_loop LD BC, #3838 CALL update_piano_keys CALL #9337 Check whether ENTER or the fire button is being pressed RET NZ LD DE,#0003 ADD IY, DE JR start update_piano_keys: LD A, (IY+$01) LD D, A CALL #932B LD (HL), B LD A, (IY+$02) LD E, A CALL #932B LD (HL), C RET

"JR NC,keyloop1" should read "JR C,keyloop1"? This entry: "IJKL ", should be "LKJH ", (with the Space character at the end, before the symbol shift entry)?

Nice one Norman. :) That's a logical extension of what I did. Incidentally, in the experimental project I referred to, L is used to point at the previously-unused Offsets #EE-#EF in the definition for the chosen room (H), wherein a suitable starting location is stored (Willy's initial x- and y- coordinates, and initial frame of animation and facing direction, are all compressed into two bytes). The LD A, (HL) command is used to pick up the data. But that wouldn't preclude me from using L instead of E to count down the inner loop, in the way that you suggest.

I've recently been working on an experimental project where a keypress is detected, and used to determine the starting room of the game (there are forty rooms in the game, and forty Spectrum keys). A partial disassembly is included below. I could adopt it to a similar method to Norman Sword's, by reversing the conditionality of the test of the Carry Flag from a JR NC to a JR C instruction. However, that would also require the insertion of a CPL command - I don't think it could be done without requiring that additional byte? Also, this method necessitates the use of the BC register-pair to read the ports via IN A, (C) - the Accumulator A is too 'busy' to use the IN A, (#FE) here, I believe. start_again: LD BC, #FEFE BC starts off pointing at the half-row of keys SHIFT-V (Bit 0 of B is reset) LD DE, #0805 D counts the eight half-rows; E counts the five keys in each half-row LD H, #C0 H keeps track of the room number keypress_loop_1: IN A, (C) If a key in the half-row currently being interrogated is depressed, then one of bits 0-4 of A will be reset keypress_loop_2: INC H RRCA A is rotated rightwards by the inner loop; JR NC, room_selected if a reset bit moves past Bit 0 then the Carry Flag is reset, indicating that a room has been chosen DEC E JR NZ, keypress_loop_2 LD E, #05 RLC B B is rotated leftwards by the outer loop, so that Bits 0-7 are reset in turn; this allows each half-row in turn to be interrogated by the inner loop DEC D JR NZ, keypress_loop_1 JR start_again None of the forty keys were pressed, so go back to the start to check again room_selected: If we reach here then a keypress has been detected, and the H register is now pointing at the corresponding page of memory (#C1 to #E8) where the chosen room's definition is stored. (N.B. Room 00 is not selected, corresponding to page #C0 of memory; that is a 'Cheat' screen.)

Optimised code to check for any keypress: loop: XOR A AF IN A, (#FE) DB FE OR #E0 F6 E0 INC A 3C JR Z, loop 28 F8 Optimised code to check for no keypresses (i.e. to ensure that the player has let go of all keys before proceeding - this is useful to stop 'accidental selections' if a key is pressed for too long): loop: XOR A AF IN A, (#FE) DB FE OR #E0 F6 E0 INC A 3C JR NZ, loop 20 F8

Fair enough. :) Although, after having come up with the code tweak that causes the alternative opening mechanism, I think I actually prefer it that way - it seems more 'natural' that the wall blocks turn to Air one at a time, and it facilitates interesting challenges such as the one which Willy encounters in the 'fixed'* test file attached to the first post in this thread. I wonder if there is a spare bit in the Opening Wall Guardian definition bytes, which could be used as a flag to determine which mechanism is used when a wall opens up? Either on an individual 'wall instance' basis, or else on a 'per room' basis (with the code change to switch between the two mechanisms implemented via a 'Room Setup' Patch). (*In hindsight, 'Fixed' and 'Unfixed' are inaccurate descriptions, in light of John's confirmation that the existing behaviour is as he intended. 'Changed ' and 'Unchanged' would be better; or 'Series' and 'Parallel' - the blocks turn to Air either in series or in parallel.)

Are you referring to the 'forcefields'? Variations on them can be created using standard guardians that have fixed boundaries, with 'slow' animation settings, and most of the animation frames left blank. The non-blank animation frame appears once in every 16 time frames, so Willy has to carefully time his pass through the gap where the forcefield appears.

It works differently in MM's Kong rooms - there are two blocks which open up in parallel, the upper block opens 'upwards' (the bottom pixel-row clears first, then the next one up, etc) whilst the lower block opens 'downwards' (from the top pixel-row downwards). Because both blocks become cleared of all pixels at the same time, they turn to Air at the same time. In JSW64 you can have a wall of arbitrary height (in terms of the number of Earth blocks), which opens from the top pixel-row downwards. Your code clears each pixel-row in turn, and then once the entire height of the wall is cleared of pixels, the attributes of each component block of the wall turn from Earth to Air. But the latter part of the code appears to allow for the possibility of turning each wall block to Air in turn, as each block's pixels become cleared. Indeed, reversing the conditionality of a single relative jump achieves this outcome, as I discovered. The Manic Miner code doesn't really give a precedent from which we can draw a conclusion - at no point is there a 'completely cleared' wall block that is left retaining its 'INKless Earth' status, pending the clearance of the pixels of a separate block of the wall. **** Incidentally, I have recently discovered a previously-undocumented bug in Matthew Smith's MM code: if you insert a blank pixel-row (00 graphic byte) midway down the Earth cell bitmap, then the opening wall turns to Air prematurely, leaving a 'ghost' of some remaining uncleared pixels - which the nearby horizontal guardian (whose range is edited once the wall has fully opened so that it passes through the gap created) promptly crashes into!

Over on the World of Spectrum forum, 'Pgyuri' has just reported having completed Jet Set Mini! I've replied to some of his comments (as best I can given that there's a bit of a 'language barrier' :lol: ) https://www.worldofspectrum.org/forums/discussion/54931/a-jet-set-willy-double-bill

Thanks Norman. I would just add that the T-state overheads are higher for setting up a greater number of parameters prior to the loop, in the case of LDIR. But of course that is outweighed by the faster loop (Unless the loop is very short e.g. The LDIR method at #8684-90 in Manic Miner wouldn't be much faster overall).

At #8828-34 and #88B8-C4, the LDIR method of editing the attributes of a character row can be replaced with a simple loop which uses the LD (HL), xx command. The latter approach consumes fewer bytes, employs fewer registers and is probably marginally faster. EDIT: I removed that latter point, in light of Norman Sword's comments below. e.g. the original code at #8828-34 requires 13 bytes: LD HL, #5A60 LD DE, #5A61 LD BC, #001F LD (HL), #46 LDIR But the same thing could be achieved in 10 bytes: LD HL, #5A60 LD B, #20 Loop: LD (HL), #46 INC HL DJNZ Loop **** The LDIR method for copying the same value across multiple addresses is only necessary when updating #100 bytes or more, which is beyond what a single register can keep track of (e.g. see #8813-27). When updating fewer than #100 (256) bytes, LDIR is only necessary if different values are being copied across to the individual addresses (e.g. #88FC-#8906).

The excerpt of the code that Andy (Spider) attached missed the end of the loop off. The loop is executed numerous times during each pass through the Main Loop, in order to draw the whole solar beam. See entry 36264 of the additional screenshot attached here - this is why it's '4 decrements per cell occupied by Willy', as discussed last night.

Of course the escape route doesn't work in the 'unfixed' version, because Willy can't safely drop down one cell row at a time.

Well done Danny on completing it the 'official' way, and well done Andy on spotting the 'loophole'! I've updated the files to prevent the latter, 'unofficial' solution (with a judiciously placed additional file cell), and reuploaded to the first post in this topic.

Air supply is normally decremented once per time-frame (i.e. once per pass through the Main Loop). If the solar beams passes through Willy, it is usually decremented nine times per time-frame (the usual once, plus 4x2= eight extra), because Willy usually straddles two cell-rows. But if Willy happens to be jumping at the time that he passes through the solar beam*, then at certain points during the jump when he isn't cell aligned, he is straddling three cell-rows (i.e. character rows) on the screen. In those instances the air supply is decremented 13 times per time-frame (1+4x3). (*Unless the part of the solar beam through which he is passing is horizontal at the time - Willy never occupies more than two cell-columns.)

Yes, four additional decrements of the air supply per cell which is occupied by Willy's colour attribute.

I was looking at the code which implements opening walls in the JSW64 game engine. The way the existing code works, the pixel-rows disappear from top to bottom, and then the attributes of the blocks are turned from Earth to Air. However, if you have a opening wall which is several blocks high, none of the blocks get turned to Air until the whole wall has had its pixels cleared. So you can temporarily have an INKless wall, several blocks high, before the whole lot turns to air. Having scrutinised the pertinent code, and thinking out loud, I wonder if the original intention was for each block in turn (from the top one down) to turn to Air as the eight pixel-rows of each are cleared. A simple single POKE can be used to achieve this - and it involves reversing the conditionality of a relative jump (so a simple mistake by John Elliott when writing the code might explain the way the feature ended up, if my hunch is right that they were intended to disappear one-by-one). Have a look at the two test files attached. They illustrate the difference between the two variants of opening wall mechanics. The opening wall in the 'unfixed' file behaves exactly the same as in the unpatched JSW64 game engine. In the 'fixed' file, I've changed the value of address #FFD9 from #20 (JR NZ) to #28 (JR Z). Willy starts off in the Off Licence. Collecting the single item in the room causes the wall to start opening. I've come up with a little challenge based on the different behaviour of the opening wall - only in one of this pair of files is it possible for Willy to leave the room and access The Bridge. EDIT: Both files have been updated, with the addition of an extra Fire cell to prevent an (unintended) loophole. MM Unfixed Opening Wall Test File JSW64X v.0.01 HL 12.tap MM Fixed Opening Wall Test File JSW64X v.0.01 HL 12.tap

I like the portal feature; it's a bit like saving snapshots in SPIN, except that the author (yourself) has some control over where the player is 'allowed' to save their progress. (There's nothing to stop the player saving their own snapshots, of course, but this allows the player to complete the game without 'cheating' in that way, yet without having to go back to the start of the game repeatedly.) It would also be a very handy feature for anyone playing the game on a real Speccy, where saving snapshots isn't an option. ** What is the significance of the yellow sprite that appears on the status bar in, for example, the Banyan Tree in this project? It looks like an arrow hitting a target, or a dartboard?

See the comment by pgyuri in the WoS thread, and my reply: https://www.worldofspectrum.org/forums/discussion/comment/947238/#Comment_947238

Putting this here for reference: https://www.worldofspectrum.org/forums/discussion/56546/manic-mixup

The Special Edition of 'Jet Set Mini' is now available for download!

View File Manic Mixup "Times are tough for poor old Willy. Decades of excessive partying have taken their toll on his finances. Despite already having downsized his mansion in 'Jet Set Mini', he is finding it increasingly difficult to afford the cost of maintaining his home, and keeping his formidable housekeeper Maria in the style to which she has become accustomed! And so, after dusting down his trusty hard hat, Miner Willy descends back into the subterranean realm where he first made his fortune 35 years ago. Emerging into the Central Cavern, he soon notices that things have changed somewhat since the last time he ventured down here..." *********************************** 'Manic Mixup' is a remix of Matthew Smith's classic ZX Spectrum 48K game 'Manic Miner', and is released in 2018, 35 years after the original game. It can be played on a real Spectrum, on the Sinclair ZX Spectrum Vega/Vega+ or on a computer, games console or another device using a ZX Spectrum emulator. The starting point for 'Manic Mixup' was an amalgamation of two projects by Dr Andrew Broad: his laterally-inverted version of 'Manic Miner' ('reniM cinaM') and Andrew's 2008 remix of 'Manic Miner'. Into this melting pot was poured a cluster of newly-designed special features, making 'Manic Mixup' quite unique amongst games based on the MM game engine. Thematically, 'Manic Mixup' is a sequel to the authors' previous game 'Jet Set Mini', which was a modified version of 'Jet Set Willy' - that in itself being Matthew Smith's sequel to 'Manic Miner'. What a mixup! All of the original caverns (and their perilous occupants) have had an overhaul in 'Manic Mixup', and the in-game music has been significantly enhanced. Furthermore, nearly all of the routines in the 'Manic Miner' game engine have been rewritten or redesigned for this project, for various reasons: to provide additional functionality (such as new sound and visual effects, and additional gameplay elements - including putting Willy's hard hat to good use!); to increase the efficiency of the code; and to fix various bugs in the original game engine. However, the essence of this 8-bit, 48K game will be very familiar to devotees of 'Manic Miner'. We hope it gives you 'unalloyed pleasure'! ********** UPDATE: A minor visual bug during the title screen sequence has just come to light, which crept in because of a tweak to the routine which plays the title tune ('The Blue Danube' by Johann Strauss II). When a single note is played, only one piano key is supposed to be lit up (whereas two keys are highlighted simultaneously whenever a chord of two notes is played). The rewritten routine caused two adjacent piano keys to light up when a single note was played. This bug during the title screen sequence has now been fixed, and the corrected game file re-uploaded. This change does not alter the gameplay of 'Manic Mixup' in any way. Submitter IRF Submitted 10/26/2018 Category JSWMM Releases