IRF

Two bytes - one per set of five colours, there being ten coloured number buttons (five BRIGHT and five non-BRIGHT). But I haven't checked whether, in the context, DE (and BC) are being used in a loop to keep track of something else - if so, then having to PUSH and then POP would negate the saving!

Danny, if the BC or DE register-pair weren't being used at the time, then maybe you could have done for example a LD DE, #0101 and then four ADD HL,DE commands (7 bytes in total), replacing four INC H and INC L (8 bytes)?

I have resisted recent attempts by my laptop to install the latest upgrade of W10, mainly for reasons of laziness (not wanting to hang around and wait while it does it). In light of this news, I will probably resist the upgrade even more vehemently! I'm sorry that doesn't really help with your predicament!

Nice one Norman! I came up with an optimisation which placed the INC, AND and OR in a subroutine, that is then CALLed eight times - but it only yielded a net saving of about ten bytes or so.

The LD BC command at #8C8E only actually needs to be a LD C (one byte shorter), since the B register is redefined after that before B is used. **** In the 'Lose a life' routine, at #8C19, there is the sequence: LD C,E RRC C RRC C RRC C It occurred to me that this can be replaced by the following, which saves two bytes (net): LD A,E RRCA RRCA RRCA LD C,A After I came up with the above, something else then occurred to me. Immediately afterwards, at #8C20, there is an OR #10 command which SkoolKid identifies as (currently) being redundant (since it is immediately followed by an XOR A, which resets A to zero). However, if the above approach is used, then perhaps the intention of the OR #10 in Matthew's original code might be fulfilled (note that the OR gate has to be placed before A is loaded into C): LD A,E RRCA RRCA RRCA OR #10 LD C,A This has the effect of slightly lengthening the sound effect when Willy is killed, and the sound has a little more 'depth' to it. It is an extremely subtle effect - only really noticeable if you play modified and unmodified files in tandem, killing Willy in each file in turn. However, if you study the possible values that are held by the C register as the 'death sneeze' progresses, I am convinced that this was the original purpose of that OR #10 command! To recap: the 'death' sound effect loop is repeated eight times, as A descends through consecutive values from #47 (01000111b) to #40 (01000000b). Each time, the duration of the note is assigned to the C register (copied from A, via E) using the above operations. This yields the following values of C: #E8 (11101000b) #C8 (11001000b) #A8 (10101000b) #88 (10001000b) #68 (01101000b) #48 (01001000b) #28 (00101000b) #08 (00001000b) Note how Bit 4 of C always holds zero for each possible value of C. The OR #10 command sets Bit 4 of A, which would slot in perfectly in between the highest three bits and the always-set Bit 3. If this was the intention, then Matthew may have made the mistake of assuming that OR #10 would set Bit 4 of C in that context - something which can be achieved by my suggested tweaks to the code. (Although doing so will negate the two-byte saving that was my original aim when I started playing around with this part of the code!)

This is the simplest layout change that will prevent an IDS jump off the top of Dr Jones to 'Quirkafleeg' - see the attached screenshot. The only room cell change is the addition of a single Fire block (the one directly underneath the square blue JSWED cursor). Oh, and I removed a pixel from the top-right corner of the Fire cells, to reduce the 'unicorn factor'. (Then again, if Dr Jones wouldn't believe it anyway, then there's no harm in making the creature as fantastical as possible!)

Good stuff. It's probably always a good idea, when performing rotate operations, to hand over to the Accumulator wherever possible, instead of rotating one of the other registers (and especially avoid rotating an indexed offset byte). Using A is more efficient both in terms of saving bytes (because there's no need to use shift opcodes) but also in terms of reducing the number of T-states that the operations take to perform. (Incidentally, doesn't AND #7F do exactly the same thing as RES 7,A - but requires fewer T-states? ;) EDIT: It's small beer in the scheme of things, mind.)

I don't think a crash will happen, because the value of A won't ever be odd if you've applied an AND #0C which resets Bits 0 and 1, and then only applied one RRCA command. :) I'm still not sure that the changes will fit into the original routine without further code-shifting, I think it's still too long by two bytes. (The two instructions ADD A,IYL and LD IYL,A each require a 'FD' shift-opcode; perhaps that is where the discrepancy lies?) However, Matthew usefully left a redundant two-byte instruction very nearby, at #930C. ;)

Thanks for the update Norman.

Actually, prior to this command: wouldn't you now need to have an AND #7F operation? Otherwise, when the rope is left-of-centre, the Animation Frame Index (which is added to the Segment Counter to point at the appropriate entries in the rope table) would have values greater than #80. The original code accounts for this by using SET 7, L and RES 7, L commands to ensure that it is always accessing the correct half of the table, but with the two halves merged, there is a need to force the routine to always look up the lower half of the table.

I think the compressed Rope Animation Table, in full, should be as follows: x8300 DEFB $60,$60,$60,$60,$60,$60,$60,$60 x8308 DEFB $60,$60,$60,$60,$60,$60,$60,$60 x8310 DEFB $60,$60,$60,$60,$60,$60,$60,$60 x8318 DEFB $60,$60,$60,$60,$60,$60,$60,$60 x8320 DEFB $61,$61,$61,$61,$61,$61,$61,$61 x8328 DEFB $61,$61,$61,$61,$62,$62,$62,$62 x8330 DEFB $42,$62,$62,$42,$62,$42,$62,$42 x8338 DEFB $62,$42,$42,$42,$62,$42,$42,$42 x8340 DEFB $42,$42,$41,$42,$42,$41,$41,$42 x8348 DEFB $41,$41,$42,$42,$43,$42,$43,$42 x8350 DEFB $43,$43,$43,$43,$43,$43 Note that the first 32 (#20) values should all be '$60'. This corresponds to the situation where the rope is hanging straight down (the Animation Frame Index = 00), so all 32 (#20) segments of the rope have zero horizontal displacement (i.e. the lower nybble of entries x8300 to x831F are all zero).

Ah, I see what you've done there - very cunning! Although I think a few of the lines of data were misaligned when you merged them - should it be this?: X8328 DEFB $61,$61,$61,$61,$62,$62,$62,$62 X8330 DEFB $42,$62,$62,$42,$62,$42,$62,$42 X8338 DEFB $62,$42,$42,$42,$62,$42,$42,$42 **** (And just to clarify - the AND commands in your post above have operands expressed in that antiquated numbering system that I believe some luddites still stick to, known as 'decimal'? ;) In hexadecimal, we're talking about: AND #0E / AND #0F i.e. pick out the lower nybble in one instance, and Bits 1-3 in the other.)

I thought that would be the case. Thanks for the considered response though.

Talking of the effects of various operations on the flags, I've just noticed that the ADD command, applied to a 16-bit register-pair, doesn't set the Zero flag even if the output rolls over to zero (0000). However, the ADC command does set the Zero flag in that circumstance, although you may need to do an XOR A beforehand to reset the Carry Flag (like the 'Move Willy' routine does when using the SBC command - there being no such thing as a 16-bit SUB).

In order to conserve bytes, could those 32 consecutive LDI commands be placed within a sub-loop? (With the shadow register A' used for the count.) Or would doing that effectively undo the speed increase that you achieved when you wrote out the LDIR loops?

In a project I'm working on, some of the guardians briefly wrap around the vertical screen-edge, so setting byte 4 to 00 would accidentally cause a match. However, I think that setting Bit 5 or 6 for Bytes 4 of such a guardian's definition should prevent a match from occurring unintentionally.

Of course, silly me! It's been a while since I played the game file, and I forgot about the Manic Miner style caverns (multi-item), where of course the opening walls take the place of the flashing portals in original MM. Funnily enough, we're working on a forthcoming project in another thread, which has all the items arranged in a particular order, and which edits the value of the 'Index to the first item' (#A3FF) as the game progresses, in order to implement a 'moveable window' looking into the Item Table. I can't say more than that right now... Of course, placing a collectable item within the same cell as a crumbly block is a good way to ensure that Willy has to climb up to collect an item, in circumstances where he could otherwise collect said item by jumping up from below and hitting it with his head.

Here are a few comments/queries about some of the 'changing room elements' in Norman's file from the crashed hard drive (see first post in this thread): The 'extending/retracting' platform at the top-left of The Bathroom reminds me of the moving platform in one of the Geoff Mode patches (in 'Willy Takes a Trip's room 10: 'A Quiet Corner to Rest in'), except that in The Bathroom it has 'asymmetrical logic': - After the Geoff Mode moving platform has been moved along by a cell-column in either direction, the room cell which it has just vacated is restored with an Air block; - In Norman's The Bathroom, the cells to the right of the platform are reverted to Air as the platform retracts leftwards, but when the platform is extending rightwards, the cells to the left of the rightmost end of the platform remain as floor/Water cells. **** Opening walls - I think I'm right in saying that all instances where these appear are in rooms that only contain a single item (e.g. The Bathroom, Top Landing, First Landing)? So are these triggered by watching the 'collection flag' for the item in the room? (Are the item definitions still stored in a global Item Table?) In Geoff Eddy's 'Willy Takes a Trip', there's a wall in Room 53 which opens when all the items in Room 24 have been collected, but that entails re-counting all the items in the global item table during each pass through the Main Loop, so it can cause a noticeable slowing down of the game! **** Crumbling floors - presumably these operate using a similar mechanism to Manic Miner (i.e. a check for the appropriate attribute underneath Willy's feet)? However, because of the '2 bits per cell type' compression format for rooms in JSW, I would guess that the crumbly platforms have to be superimposed on top of the basic 'four element' (Air/Water/Earth/Fire) room layout, around the same time that the ramps and conveyors are added?

Thanks for that, Norman. It's a good use of the spare offset byte. :) I presume that 'homing sprites' are much more complicated than that? :blink:

http://www.seasip.info/Jsw/jswdiffs.html I thought it would be a useful resource to provide the source code for the guardian expansion code in the JSW128 game engine. John Elliott's otherwise excellent document (link above) only does half a job in relation to this! Here's the bit that John does provide: And here's the missing part (using the same notation, for consistency): ;128k ORG C4B6h ADD HL, HL ADD HL, HL ADD HL, HL LD BC, (W80DF) ADD HL, BC RET

In the file you uploaded, it is still possible to jump off the top - see attached (very short) recording! If you bring the Fire cell at the top of the room down by three rows (staying within the same column), it should prevent the jump (and look much better!) EDIT: It would basically then be placed one cell to the right of where you had it in the screenshot you uploaded a few posts back. Dr Jones jump.rzx

Either that, or shorten the Water platform in the elephant's head by one cell on the right-hand side. (The upper of the two Water platforms that pass through the head, although visually it might look better if both those Water platforms had the rightmost Water cell removed.)

The problem is that if Willy is standing on the Earth blocks that are directly above the Moon-face guardian, he can do vertical jumps and (after landing on the Water cells) breach the top of the screen.

I think it would still be possible to jump off the top in that arrangement though.

I think that's a big improvement - there were a missing couple of pixels it seems, which you've now restored. :)