IRF

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. :)

The 'homing sprites' are cool. I seem to recall that there were some sprites with odd movements in the earlier file that you posted as well (the file attached to the first post in this thread). Those ones weren't quite as devious as these latest ones though. Might we look forward to seeing a disassembly of the code that creates some of these 'alternative logic' sprites? :) (P.S. In case anyone missed it, I've just noticed that Norman has uploaded a new 'homing test2' file to his post #20 on the previous page.)

And you can't go to bed until you've put them in the right order!

Good stuff Norman! Also, I like the little extra feature that I spotted in 'Master Bedroom' (although note that there's a misplaced apostrophe in it).

I think another three bytes could be saved in this patch, by sharing the LD A, (IX+$01) command across both parts of the code. (This relies on the fact that neither the LD C, A command, nor the LD A, (IX+$01) , affect the Zero Flag. Therefore both of those can be placed after the AND #38 command - which does determine the status of Z - but prior to the JUMP back to #91F2. Then the LD A, (IX+$01) command in the main 'Draw the Guardians' loop - at #91F2 - can be removed.)

In the 'Watch Tower', I think the Water cells should perhaps be drawn with blue PAPER colour, to match the PAPER colour of the air cells (as well as the Fire cells, and the ramp and conveyor in that room). As things stand, there is an unseemly black stripe underneath each Water cell, which jars against the background. POKE #F2A9, #0E would fix it. :)

A good example of the use of a lookup table in a Patch Vector can be found in the first part of Geoff' Eddys patch for Room 11 ('Under Your Spell') in 'ZX Willy the Bug Slayer': https://web.archive.org/web/20080511161939/http://www.cix.co.uk/~morven/jsw/patches.html I later adapted Geoff's method for the PV in the 'Master Bedroom' in 'Jet Set Mini'.

Thanks Norman. That one reared its head during the development of a couple of projects we worked on. I came up with a simple workaround by using AND #38 at #8AFC, which helped Daniel Gromann to fix the problem in the SE of his game 'Willy's New Mansion'. (My fix has the disadvantage that it stops the likes of the cross in First Landing from flashing whilst the game is paused.) Then Richard Dymond (SkoolKid) came up with the same solution as you (AND/ADD/AND). I used that method in 'Jet Set Mini' (to fix a problem with the flashing letters on the Title Screen), and I think Mickey has fixed it in that way in his project here?