IRF

I think I might(?) have come up with a further optimisation of the room expansion code - I haven't tried it out yet though... Suggested changes are in red: EDIT: Now that I've tallied up the 'before versus after' difference, it might not be any more efficient in terms of memory after all! There are fewer commands overall though, so perhaps it's marginally faster? In addition to the above, the 'Print a message' (#9680) and 'Print a single character' (#9691) routines would need to be rewritten, as follows: ORG #9680 LD A, (IX+$00) ; Collect a character from the message CALL Print_ASCII_character ; Print it INC IX ; Point IX at the next character in the message INC E ; Point DE at the next character cell LD A,D ; (subtracting 8 from D compensates for the operations performed by the subroutine at 9691) SUB $08 LD D,A DEC C ; Have we printed the entire message yet? JR NZ,$9680 ; If not, jump back to print the next character RET Print_ASCII_character: ; Formerly #9691 LD H, #07 LD L, A SET 7, L ADD HL, HL ADD HL, HL ADD HL, HL Print_non_ASCII-character: ; Formerly #9699 ; Label renamed for clarity LD B, #08 ; There are eight pixel rows in a character bitmap Loop: ; Copy the character bitmap (or triangle UDG, or item graphic) to the screen (or screen buffer) LD A, (HL) LD (DE), A INC HL INC D DJNZ Loop LD A,D ; Subtracting 8 from D compensates for the operations performed by this subroutine SUB $08 LD D,A RET As I say, I haven't tested this out yet. Off the top of my head, I can't think of any reason why it wouldn't work, but careful consideration is needed bearing in mind that the 'Print a (non-ASCII) character' late entry point into the 'Print a single character' subroutine is also used by other code (such as the Impossible Triangle and item-drawing routines).

These labels (in the room expansion code) made me chuckle: ****** Regarding the clock update, I came up with the use of XOR to toggle between 'am' and 'pm' independently, and suggested it to Metalmickey for his 'As Manufacturer Intended' project. But the rest of the method is an innovation - ditching the use of an indexed register (IX) saves quite a few bytes (no need to use the 'shift opcode' DD), and the comparison against a table of 'upper limit values' for each digit ("clock_master") is rather ingenious!

Did the project present any unprecedented problems because of the protagonist's prominent proboscis? (Collecting the item in The Chapel, perhaps?) **** Out of interest, I wonder if, after completing the game, you pressed SHIFT+SPACE whilst still recording, in order to showcase (as part of the recording) the final passage of the Noseybonk theme, which is played during the Game Over routine? (Note to self for when I get round to watching your recording.)

I thought it might be a deliberate reference to Willy's grand abode...

Deliberate typo, m'lud?

Your compression of the Title Screen is impressive, Norman Sword. This is small beer in the scheme of things, but instead of the commands in bold: You could just test BIT 1, D. (And swap the conditionality of the jump to JR Z, logo_draw). Saves another byte! :)

Are all the different heads stored in a table? You could almost call this "JSW: The Worzel Gummidge Edition"! :lol:

I guess this means that it's time to say "Happy Birthday Andy!"

"Words fail me" that no-one has cracked this yet...

Thanks Norman. I notice that that method overwrites the intermediate byte twice, with the same value (not that it matters).

Small rewrite in the JSW game initialisation code which saves a byte: 87F5 LD HL,$857C 87F8 LD (HL),$30 87FA INC HL 87FB LD (HL),$30 87FD INC HL 87FE LD (HL),$30 LD HL, #857C LD BC, #0330 loop: LD (HL), C INC HL DJNZ loop

Well done Danny! I wonder if your statement here: was facilitated by your having utilised the SPECSAISIE comparison tool for the task? (Which you recently installed and used in relation to the MM10CC project.)

76+16=92, but in any case doesn't the LD HL, (counter) require 20 T-States (source: http://z80-heaven.wikidot.com/instructions-set:ld ) Plugging that in yields about 8 T-States for the overhead per byte in the Stack Copy method, therefore a total of 18.5 T-States per byte. i.e. the LDI method is even more efficient in comparison with the Stack Copy method than your rough calculations suggest(?)

Is anyone "seeing red" in frustration over this yet?

Having refreshed my memory, the flaw doesn't work in the way that I outlined in my previous post. The items jiggle up from their default position, not down (as I had misremembered). If you have an item in the top cell-row, then it discolours the cell in the bottom cell-row directly below it. (The top graphic byte of the item is interpreted as an attribute byte, overwriting the primary attribute buffer.) This is normally disguised, because in Mono mode, everything is overwritten in black-and-white anyway, even though technically all the room blocks remain retain their colour attributes (upon which Willy's interaction with them is based). So it's normally a harmless effect (an 'invisible visual glitch'!) But if the top pixel-row of an item's graphic definition matches the attribute byte of a defined room block type, then other effects can occur. In the attached test file, I have defined an item shape in West Wing and added some items in the top and bottom cell-rows. There is no collision with the vertical guardian, as I had initially expected, but there are a couple of effects: (1) If you try to walk down to the bottom of the ramp, you will notice that Willy is killed for no apparent reason. The item's top pixel-row is entirely filled in - all eight pixels are on; it holds the value #FF - this matches the defined attribute byte for Fire cells, so there are two invisible Fire cells created in the bottom cell-row; (2) The bottom two items disappear after two time-frames - because the #FF Fire cells hold white INK, collecting the items. (The slight time delay occurs as the secondary buffers take a while to catch up with the corruption of the primary buffers.) Jet Set Willy - Mono Jiggle Test File.tap

I seem to recall that I identified a flaw with the Jiggle patch, which causes the bottom pixel-row of the graphic of an item located in the bottom cell-row of the screen, to spill over into the top pixel-row of the top cell-row on the screen, causing a permanent overwriting of that graphic byte. Such graphical corruption would be prone to collision with guardians, imperilling Willy. I identified an easy fix for that flaw, which is detailed somewhere in the Yahoo! Group. This problem shouldn't affect the games you've just uploaded, since (as far as I can recall) there are no items in the game which are located in the bottom cell-row of any of the rooms. But if the game were modified to that effect, then the flaw could rear its head. Though if the graphical corruption were to occur in an air cell in the top cell-row, then it may not be visible unless the Air's PAPER and INK settings are different, such as in a room with a rope.

Correct! Hip hop hip Hooray!!

No! In fact the opposite!

Thanks, as ever, to Richard Hallas' tone chart 'A Miner Triad'. ?

Just a bit of fun... See if you can recognise the in-game tune in the attached file... EDIT: I've made a slight tweak to the second half of the tune in the additional attachment 'rev1', for a bit of variety. MANIC With New Tune.TAP MANIC With New Tune rev1.TAP

Norman Sword, you were duly credited in the Readme file which accompanies the file by Metalmickey which is referred to in post #7 of this thread. :) (Metalmickey also mentions me in the same sentence of that document, as it was I who recommended that he implement this since he was attempting to collate "fixes for all known bugs" in JSW, and I helped him to implement your fix into his project. However, the credit should really be all yours. [Having said that, I would say that I had some modest input into it, by encouraging you to 'synchronise' the updating of attributes for each character row in association with the associated eight pixel rows, an improvement which reduces another element of screen flicker.]) I have updated my post #7 to make it more explicit that you were the author of the 'Jagged Finger Fix'. (When I posted earlier, I thought I had made the authorship clear, but on reflection perhaps I didn't make it clear enough.)

I believe that another jswmm member, called Metalmickey, implemented the Norman Sword's fix for the flickering sprites into his 'JSW As Manufacturer Intended' project: http://jswmm.co.uk/topic/244-jsw-as-manufacturer-probably-intended-kind-of/ As well as fixing the 'jagged finger' imperfection, the patch also reduces the issue whereby the attributes of fast-moving entities can be noticeably delayed behind their pixels. (You can see this in effect when Willy drops into 'Entrance to Hades' - his feet flicker in green as he falls, because green is the defined INK colour of the air cells and it provides a strong visual contrast with the yellow PAPER background in that room. Try that manoeuvre in the original 'Jet Set Willy' and compare/contrast with the same manoeuvre in the 'As Manufacturer Intended' file.) EDIT: I should point out that whilst the flickering is fixed/reduced in the aforementioned project, the speed of the game is not increased to anything like the same extent as is the case in Norman's more recent files (JSW 128 VK / VL). As far as I can tell, the most recent version of that 'As Manufacturer Intended' project is the one which is attached to this post: http://jswmm.co.uk/topic/244-jsw-as-manufacturer-probably-intended-kind-of/page-26?do=findComment&comment=6238 Since that version was uploaded, some more refinements were discussed (such as making the end-of-game toilet-dash appear more as if Willy is running, instead of sliding, to the toilet!), but I'm not sure if Metalmickey ever got round to incorporating those changes into a more recent build?

Check out this topic - is that what you meant?: http://jswmm.co.uk/topic/299-file-jsw-jagged-finger-effect-demo/?hl=jagged

Enjoy!

ThINK again...