IRF

So if I understand correctly, in Norman's latest file the item definitions for Rooms 0-63 are stored at Offsets #80-#FF in pages #A4 and #A5 of the code, whereas item definitions for Rooms 64-127 are stored at Offsets #00-#7F on the same pages? If this was ever developed further with 128 (or 120) fully independent rooms (rather than the new rooms 'shadowing' the original rooms), then may I humbly suggest that a similar arrangement could be put in place to what Andrew Broad did in his game 'Party Willy'. Namely that Rooms 64-127 are located on the far side of Maria, and then an AND #7F gate is inserted in between the two commands at #9422 and #9425 (original addresses) in the 'Draw the items' routine. This has the effect of splitting the game into two halves - the player must complete the first 64 rooms (collect the first 128 items) before they are able to proceed to the second half. For reference: http://www.worldofspectrum.org/pub/sinclair/games-info/p/PartyWilly_TechnicalNotes.txt

Having thought about the above, I'm not sure if it's feasible to come up with an arrangement that's more byte-efficient than the current one. Firstly, the direction of travel for horizontal guardians would have to be determined from Bit 2 of Byte 04. But there's no easy way of checking when the value in Byte 4 has spilled over past Bits 0-2, other than by checking for the individual values 08 or -01 (#FF). The Carry Flag wouldn't respond in these circumstances. Maybe if all the values for animation frame were doubled (and the 'Draw the horizontal guardians' routine was amended accordingly, with an additional RRCA inserted at #8DD0), then the Half-Carry Flag could be used. But I don't think there are any Z80 instructions (conditional jumps etc) which are determined by the status of the H Flag. You would need to fundamentally change the function of Byte 04 for horizontal guardians - edit all the horizontal guardian data, so that Bits 5-7 holds the animation frame (with Bits 0-4 unused, although perhaps they could be recycled for other purposes?), rewrite the 'Move the horizontal guardians' routine in accordance with my previous post, and then NOP out the three RRCA's in the 'Draw the horizontal guardians' routine at #8DCE-#8DD0. Probably not worth the hassle.

The above approach may be more appropriate for optimising the horizontal guardian movement in Manic Miner (i.e. having a shared set of commands for both left and right movement), since the guardians 'face themselves' in their sprite pages rather than being 'back to back', and as a result there would not be a need to swap the two halves of each sprite page. I haven't tried it out yet though.

That would make sense about the mediaeval scrolls. I haven't had time to process the rest of the previous post yet (will do so later).

It's interesting that the second switch doesn't work at all for dispatching Kong, but with the first switch, it's the exact opposite: you don't need to flip it at all, because the opening wall collapses as soon as Willy enters the cavern! None of the above would happen if the Cell Graphics Bug was fixed! It's a rare case where the CGB has a side effect that isn't purely aesthetic!

Did you try to kill the Kong Beast?

POKE #CE5E, #06. There are some strange, indirect, perhaps unexpected side-effects from this one...

You shouldn't have any trouble finishing it, especially with the Infinite Lives facility available in the loader (and the fact that we eliminated most of the IDS's). :)

Nice one Norman. The 'aura' fix is highlighted well by the 'printing press' guardian in the room 'Mondrain', because of that guardian's 'transparency'. The yellow 'bat' guardian also illustrates the fact that when guardians are passing through cells with a non-black PAPER setting, the BRIGHTness settings of the guardians are inherited from the cells through which they pass - rather than the other way round, as was the case in the original JSW. **** I'm guessing that the decision as to which variant of each room to display, at a given moment in time, is based on whether the 'tick' counter (#85CB in the original game) has an odd or even value (i.e. status of Bit 7 of that variable) at the point when Willy enters the room.

Unless, of course, you discover certain things that you haven't found yet! ;)

No worries. :-) A question for Andy, out of interest: did you ever make a complete recording of Jet Set Mini?

I guess what I'm asking is that if you do record an efficient recording, then please let us know as I'd like to have a go at beating your timing before you submit to RZX Archive. So it wouldn't cause too much of a delay between your making the recording and your submitting it (I'd just need to find the time to sit down and have a go at an efficient walkthrough myself). I think this is one of the few occasions where I might have a snowball's chance in hell of beating your completion time (but only because of 'insider knowledge'!)

I forgot to mention that I implemented the above (successfully) in 'Jet Set 40-40'. If I recall correctly, the out-of-situ part of the patch is located at #93BB-CB, just before the short Easter egg message 'ANDYF' in the code. (And in fact, reworking the Guardian Aura Patch enabled me to fit a five-character message into that location.)

Danny, if you do manage to find any such clues, please put any discussion of them in the following thread for now: http://jswmm.co.uk/topic/164-jsw-mini-contains-spoilers/page-126

Also, you might want to try out the POKES provided in the 'Mini' readme, which allow Willy to access the 'invalid rope' in 'Front Door' (if you haven't already).

Maybe let me know your completion time and I'll see if you've beaten mine yet? By the way, look out for a few 'clues' along the way...

I might release it as a 'bonus feature' alongside 'Willy's Recurring Nightmare'.

I believe I've had the best completion time for 'Jet Set Mini' to date (better than yours Danny!), but I'm not releasing the recording because it contains spoilers (there are aspects that even you haven't discovered yet!)

Thanks Norman, I've edited my post above as well accordingly.

There's a big chunk of unused addresses in the Manic Miner code at #934C through to #9CFF (although the very end of that is used for the stack). So you could either: - Use H=#12 (with the SET 7,L command retained), and insert the font characters at #9500 to #97FF; - Or have H=#13 (and replace the SET 7,L with a RES 7,L), with the font being stored at #9900 to #9BFF. Note that the SET 7,L command is at #92CE in the Manic Miner code (that's in the Bug Byte version, it may be different in the Software Projects variant although I don't think the differences extend that far).

"Mid-sprite bounce" it is then! :-)

IRF, on 25 Oct 2017 - 12:06 PM, said: Norman Sword replied: I meant to reply to this earlier but forgot. The Geoff Eddy patch which draws a single moving block (disassembly below) does actually work on the Master Screen, rather than the Working Screen, and so it does have to erase the previous block's position after it has moved. However, it does both of those things during every game loop anyway, which seems like it could be a waste of effort (causing a needless slowing down of the game), based on what you said above. The reason that the block has to be drawn to the Master Screen and not the Working Screen, is because the Patch Vector subroutine is CALLed from the Main Loop after Willy has been moved during each time-frame. So at the point in time where the 'Move Willy' routine tests for a solid platform underneath Willy's feet, the moving block would not yet exist if it was being created at the Working Screen level.

I've now managed to achieve the shared left-right code for horizontal guardians, including a mid-path bounce (a phenomenon which is best exemplified by the Monks in the room 'Gregorian Chant' in the 'total rewrite of JSW in 48k' project that was uploaded by Norman Sword - 'Gregorian Chant' is a very nicely presented room by the way!). This change used up most (but not all) of the bytes that had been freed up by combining left and right movement into a shared piece of code. Starting at #9133 (changes from my initial code are highlighted in bold): PUSH IX ; copy the address of Byte 0 of the guardian definition POP HL ; to the HL register-pair LD DE,#E0FF ; parameters for a LD B A,(IX+$06) ; guardian moving left BIT 7,(HL) JR Z, left LD DE,#2001 ; parameters for a LD B A,(IX+$07) ; guardian moving right left: LD B,A LD A,(HL) ADD A,D ; increment animation-frame of guardian BIT 7,(HL) ; sets the Zero Flag for a left-moving guardian LD (HL),A ; update guardian definition Byte 0 with correct animation-frame JR Z,carry_okay CCF ; Complement the Carry Flag for a right-moving guardian carry_okay: JR C,#91B6 ; not time to update the guardian's x-coordinate; proceed to Move the next guardian XOR #80 LD (HL),A ; time to update the guardian's x-coordinate, so reset the animation-frame to the first one for the next cell-column LD A,(IX+$02) ; guardian definition byte 2 LD C,A ; temporarily save in the C register AND #1F ; extract guardian's current x-coordinate CP B ; has the guardian reached the extremity of its range in the current direction of travel? JR Z,mid_path_toggle ; if so, jump to toggle the mid-path bounce on/off, and then reverse the guardian's direction of travel RLC D ; moving left, Carry is now set; moving right, Carry is cleared INC A ; adjust A to account for width of guardian(?) SBC A,(IX+$04) ; has the guardian reached a mid-path bounce point? ; [N.B. If you use a SUB command instead of a SBC here, then the guardian gets stuck at its mid-point!] JR Z, turn_around ; if mid-path bounce point has been reached, reverse the guardian's direction of travel LD A,C ; retrieve guardian definition byte 2 ADD A,E ; adjust x-coordinate LD (IX+$02),A ; and save JR #91B6 ; proceed to Move the next guardian mid_path_toggle: LD A,(IX+$04) XOR #40 LD (IX+$04),A turn_around: LD A,(HL) XOR #E0 LD (HL),A JR #91B6 ; proceed to Move the next guardian There are six spare bytes now remaining at #9179 to #917E. The mid-path bounce point is specified by the guardian's (previously unused) definition Byte 4. EDIT: Perhaps the term 'Intermediate Bounce Point' is more appropriate; it doesn't necessarily have to be mid-way (i.e. halfway) between the leftmost and rightmost extremities of the guardian's horizontal range. (N.B. If you have a quirky guardian which wraps round past the edge of the screen, then set IX+$04 = #80 to avoid an inadvertent mid-path bounce caused by the default value of zero for Byte 4.)

For reference: http://jswmm.co.uk/topic/390-a-test-file-for-jsw/?p=8162 I presume that after the first of each pair of arrows is drawn, IX is incremented and then the arrow-drawing code is repeated for the other half of the pair?

Yes, I think just black would be suitably sombre. EDIT: For what it's worth, I've just re-uploaded the file with the above suggestion implemented (attached to original post on previous page of this thread). If anyone should be apologising for taking the thread off-topic, it's me, as this doesn't really have anything to do with Norman Sword's original post/attachment (I'm not sure how I ended up diverting it with this particular micro-project!)