IRF

There is also some detail of code changes provided in the readme for 'ZX Willy the Bug Slayer', which isn't included in Geoff's disassembly pages for either his game engine or his patch vectors. http://www.worldofspectrum.org/pub/sinclair/games-info/z/ZXWillyTheBugSlayer.txt In particular, some of the PVs for that game (in Room 0 'Dead Flesh Nightmares' and Room 5 'PUSH BC') CALL up #8700, so I thought I would include the code here for ease of reference: EDIT: This is useful for printing a sequence of characters to arbitrarily-distributed addresses on the screen (each character and address being defined by pairs of values in the table pointed at by HL) - rather than for printing a contiguous message in adjacent character spaces (which can, of course, simply be done by CALLing #9680).

Thanks Mickey. I haven't got time to study this in detail at it right now, but I've grabbed the file and I'll have a look at it when I get a chance. :)

The buffers are located in 'contended memory' (everything from #4000 to #7FFF, from what I gather). I'm not sure what the implications are of that - Andy may be able to elaborate further? - but I believe that you shouldn't put things such as routines or data bytes within that range. Hence the buffers are located there (#5C00-#7FFF), I think?

For reference, this noise-creating subroutine at #8590 is not included in any of Geoff Eddy's disassemblies (as far as I can tell), although it is CALLed from the PV for Room 8 ('The Garden of Forbidden Fruit') of his third game 'Willy Takes a Trip': #8590 3A E4 85 #8593 5F #8594 AF #8595 01 20 00 #8598 D3 FE #859A EE 18 #859C 43 #859D 10 FE #859F 0D #8600 20 F6 #8602 C9

How would that free up space? You'd still need to have those buffers somewhere, so you'd just be 'robbing Peter to pay Paul' wouldn't you? :wacko:

Although having said that, perhaps the Jagged Finger effect is particularly pronounced as Willy runs down the ramp in Master Bedroom during the toilet dash? And if you made the Air INK red in one of the rooms that he runs through en route to the toilet, then the Delayed Attribute effect might be very noticeable (in the unpatched file) during the end sequence?

Just to report that there is an error in the files that I uploaded earlier in this thread to demonstrate the patch in action; at #8A30 I put '7E' LD A, (HL) when I should have put '77' LD (HL), A. However, this only affects the code which causes Willy to run at double speed during the toilet dash (the error means that he just automatically proceeds leftwards at the normal speed after reaching the bed). It doesn't diminish the ability to use the files to compare the 'before vs after' effect of the patch on the Jagged Finger and Delayed Attribute Effects.

I think he's saying that the opcodes aren't compressed, but the data bytes are? But yes, he did come across a bit like a Brit abroad asking the Spaniards why they can't speak English as well as he can!

Some posts have been a bit slower than usual in appearing, but that's all.

I think that the three-byte command at #8926 may be superfluous, as DE will already hold the value #8100 by that point. (Having been incremented to that value by the preceding LDIR loop, at #8920.) That would provide enough space in the Room Setup routine to CALL a Room Setup Patch Vector. (Although it wouldn't be the best place for it; better to shuffle it down to sit after the CALL to #8D33 at #8955.)

I should add that in the original JSW, with the 'JF&DA' patch not in place and the Air INK and PAPER in West Wing both set to black, if the glitch does occasionally present itself, it would be manifested as a few pixels of Willy's sprite disappearing for a microsecond (i.e. rendered in black on black, as he crosses a cell-boundary). But that would be virtually imperceptible to the human eye - it's only when the Air's INK and PAPER settings are distinct (and in starkly contrasting colours) that you can briefly detect it. (I think 'Entrance to Hades' is the best example of that in the original game.)

In terms of the definitive fix, I would go with Norman's code in post #40 of this thread. I have no problem with it being used in third party projects. :)

Danny, in relation to the flickering in red in the West Wing, I think that in the 'patched' test files I changed the Air INK setting in that room to red, to illustrate the 'delayed attributes' effect. I intended to do the same for the 'unpatched' test file, to allow a direct comparison. But I can see that I omitted to do that. That explains the discrepancy you noticed. (My apologies for the confusion!) In the corrected 'unpatched' file attached here, I have changed the Air INK to red in West Wing. Hopefully you will agree that rather than creating the the glitch you can observe, the patch actually improves it. But the 'patched' files illustrate the point that the glitch is mostly, but not entirely, eliminated. There will always be an infinitesimal delay between the graphic bytes being drawn and the associated attributes being copied - the program cannot do both things at precisely the same time. But the final patch minimises the delay (and hence the glitch) as much as is physically possible. JF&DA_Bugs unfixed_Red INK in West Wing.z80

Is this a reference to my earlier post elsewhere, regarding the item in the Swimming Pool? I agree that it is conjecture to try to guess where the other unused item forms, defined by Matthew and buried in the JSW game code but never used, might have ended up being placed (if anywhere). However, Matthew DID place an item at a specific location in the Swimming Pool, but it doesn't get seen during play because of a bug (white Air INK) causing it to be auto-collected upon entry to the room. I made a humble suggestion that the Swimming Pool item could be included in what I thought was an ongoing project of yours. This was based on the observation that the starting point for JSW2 was to base it on the existing JSW room layouts. Were it not for the accident of history that the Swimming Pool item was subject to the aforementioned bug, I feel sure that you would have included it in JSW2 (I can't think of any other instances where you purposely removed an existing JSW item from the JSW2 layout?) In making that suggestion, I certainly didn't intend to denigrate your wider efforts. Thinking back, I can only presume that you took umbrage at my suggestion, hence your curmudgeonly attitude towards me ever since? However, you have taken some of my other suggestions on board: - supplementing your 'Jagged Finger' patch with a fix for the (even more pronounced) 'Delayed Attributes' problem; - and I notice that you have quietly edited a couple of typos which I pointed out in your substantive posts on this thread (presumably that was 'pedantry' on my part - yet if anyone had tried to implement the uncorrected code it could have caused a crash, so there's something to be said for being a pedant!) Therefore some positive things have emerged from my bristly encounters with you. P.S. I won't quote your messages again, since it appears to cause you such distress.

I could point to numerous examples in various recent projects, where implementing a small code efficiency (sometimes a single byte) has facilitated the introduction of specific modifications, which otherwise couldn't be implemented without significant rejigging of the code. Furthermore, as a novice programmer, I have often taken on the challenge of getting chunks of code to 'fit' into the available space, as puzzles to be solved in their own right. And the process has been very much of a learning curve for me, enhancing my knowledge of the workings of the JSW game engine and of the Z80 instruction set.

The whole point of this thread, when Daniel Gromann set it up, was to identify places in the original JSW code where efficiencies could be made. (In the context of several ongoing projects being worked on at the time, which could - and indeed have - benefited from such efficiencies.) At #944C, Matthew defined B=08, and then at #944E he CALLed a late entry point into the 'Print a single character' routine, namely #969B. If instead he had CALLed #9699, then the two-byte command which defines B in the item-drawing routine would have been unnecessary. Furthermore, Geoff Eddy's alternative room-drawing code effectively replicates the latter part of the item-drawing code, when it could have just CALLed #9699 (as indeed your alternative room-drawing routine does). I listed them here as potentially-useful optimisations for prospective game designers.

This doesn't really fall into the category of 'code optimisation', rather it relates to optimisation of the speed of the game: It strikes me that there is an inefficiency in the part of the Main Loop (in both JSW and MM) which checks the teleport keys (WRITETYPER/6031769). Currently, the program checks if the 'activator' key ('9' for JSW, '6' for MM) is being pressed before it checks whether the teleport key counter has reached the appropriate value to allow the teleport function to be activated. Wouldn't it be more efficient to switch that around, and check the value of the teleport key counter first? Then in circumstances where it hasn't reached the right value, the program would jump to the next pass through the Main Loop, without having to perform operations relating to '6-0' keypresses. (Which might be being used as movement keys, thus needlessly causing both checks to take place during the 'teleport' part of the code.)

Check your PMs in about five minutes...

It's not actually a lot of work, please bear with me as I really think it would be worth adding to the project.

Regarding the above, it's actually mostly 'Norman Sword's solution, although I inspired him to go further than his original approach, so that it addresses two distinct visual glitches in a shared solution. It might (or might not) have to be 'tailored' to fit into your modified game file. Question: in the 'As Manufacturer Intended' project, have you made any modifications to the code in the range #89F5 to #8A30?

Was this the 'distraction' that you were talking about? ;)

Looking at the above, I believe your Char_print should be pointing at #9699, rather than at #969B, because you've made use of the fact that B is already assigned a value of 08 in the 'Print a single character' routine (at #9699). (An efficiency which Matthew could have made use of with the CALL command at #944E in the 'Draw the items' routine, but he didn't.) (Also, Geoff Mode could have made use of a similar efficiency, but didn't.)

I believe you have inserted some of your extra code into the vicinity of #96F4-97FF?

I guess you could modify the code in the MM game engine. First thoughts: swap around the DEC A and INC A at #8E07 and #8E12 respectively, and then modify the y-coordinate at which Eugene comes to a halt (#8E14). I have a further suggestion for a modification to Eugene - in fact suggestions for all four 'special' MM guardians, in the JSW64 game engine - but they will have to wait for a future post, when I have the time.

I think Geoff Eddy's games may take a similar approach. Certainly there's a room in which there are two ramps, drawn in opposite directions. However, getting both ramps to behave as they should in terms of Willy's movement along them (and the pixel-height at which he is drawn whilst on a ramp) requires a Main Loop Patch Vector approach, to vary the Ramp Direction Byte in the room buffer as Willy's horizontal coordinate changes within the room.