Jump to content


Member Since 23 Aug 2015
Offline Last Active Dec 10 2017 10:16 PM

#8241 Free space and code optimisation in "JSW"

Posted by IRF on 07 December 2017 - 06:36 PM

A few efficiencies can be found around the IN commands that take signals from the keyboard.

Wherever there is a LD BC,#0000 followed by an IN A,© - this can be replaced with a LD A,#00 [the value that was previously being loaded up to B] followed by an IN A,(#FE).

Also, in places where a routine responds to any keypress from one or more entire half-rows of keys*, you can replace this sequence:

CP #1F

which leaves the Zero flag reset if and only if one of the appropriate keys is pressed, with this:

OR #E0
CPL  [Note that the CPL command leaves the Zero Flag unchanged, even if the Accumulator ends up with a value of #00.]

INC A  [This replaced the CPL command, which didn't work.  INC A will set the Zero flag if and only if the previous value of A was #FF i.e. all bits set, because no keys in the relevant half-row are being pressed.]

which has the same effect on the Zero flag, but requires one less byte.

(*Such as pausing/unpausing the game, toggling the music on/off, or pressing a Jump key other than '0'. It wouldn't work when specific keys out of a half-row are being tested, such as Left-Right movement or the SHIFT+SPACE abandon-the-game key combo.  Note that this won't work if the situation requires the precise value in A - as determined by the particular key in the half-row that was pressed - to be used for other purposes.)

#8234 A test file for JSW

Posted by IRF on 06 December 2017 - 11:55 AM

In the attached, I've tweaked my Game Over test file in accordance with Norman Sword's suggestions.  I've also come up with a way of having a pause instead of (but of the same length as) a note, to punctuate the music.  That required four additional bytes in the code, and the use of the value '01' in the music data to denote the 'dead notes'.

Attached Files

#8209 A test file for JSW

Posted by IRF on 05 December 2017 - 01:20 PM

Thanks Norman.

I was aware that I had implemented a 'quick and dirty' solution, which causes the changes in duration of the notes. (It's probably a deliberate effect in the original routine, as the increasing pitch causes the Monty Python foot to speed up as it descends onto Willy.)

#8196 A test file for JSW

Posted by IRF on 04 December 2017 - 01:39 PM

Spot on, Danny!

#8192 A test file for JSW

Posted by IRF on 03 December 2017 - 11:46 PM

I just had an idea this evening, and so I knocked up a test file to try it out.


Load up the attached, kill Willy (he only gets one life) and see what happens...

Attached Files

#8172 Free space and code optimisation in "JSW"

Posted by IRF on 30 November 2017 - 09:53 AM

If the following two commands (five bytes) are added at the start of the subroutine at #9584:


LD HL, (#85D2)

SET 0, (HL)


then the eleven bytes at #8A00-#8A0A can be removed from the Main Loop entirely.




To achieve the above:


- The four bytes at #9580-83 can be replaced by a relative jump to the code that is currently at #9596 (but that will need to be adjusted to take account of the next step); that saves two bytes;

- The three-byte command at #959A is redundant, and can be removed (remember to adjust the length of the relative jump which takes you to that entry point, from #9539).

#8163 A test file for JSW

Posted by IRF on 29 November 2017 - 05:21 PM

Interestingly, when Willy is standing (stationary) at certain positions on the ramp in The Bathroom, as the BLOB passes (harmlessly) through his legs, he is drawn at a higher position than usual..  But only for a single time-frame, before he drops back down to the regular height.


This is presumably because when the BLOB is coincident with the ramp cell upon which Willy is standing, it changes the attribute-based behaviour when Willy is drawn, and so in that moment his y-coordinate is not adjusted for the fact that he is standing on a ramp.


The BLOB is probably acting as a Water cell by default.  You could maybe get some other interesting effects by making the BLOB's attribute coincide with that of:


- the Conveyor cells - it could cause Willy to turn around, or increment his frame of animation, as it passed under his feet?;


- the Ramp cells - i.e. the reverse of the behaviour seen in Norman's file, causing Willy to bob down as it passes under his feet (perhaps into the path of a guardian?);


- the Air cells - if Willy was standing on a single Water/Earth block and the BLOB passed through that block, then it would briefly turn to Air, causing him to fall through the block upon which he is standing (the BLOB would be invisible against the background though, unless it was given a pixel pattern and the Air INK and PAPER had different settings?);


- the Fire cells - the blocks would be lethal if they hit Willy (that's already been done in a Geoff Mode patch actually);


- the Earth cells - you could create a moving 'Innocent Looking Block' which Willy has to try to perform a quirky jump through, in order to access a lower level?!?;


- Crumbly cells - causing a platform to crumble only when Willy is standing on it and the BLOB passes through it?


- In JSW64, moving Trampoline or Trap cells?  The former would force Willy to jump as it passed under his feet; the latter would cause him to start falling if it passed under his feet (even if he is also standing on a solid block with the other half of his sprite).

#8127 JSW As Manufacturer (probably) intended .. kind of...

Posted by IRF on 24 November 2017 - 09:28 PM

However, she is tapping her foot... The yellow Maria on the right isn't animated at all - but if you made her animate, I fear that would also cause the Foot guardian to start flicking to the Barrel sprite and back again? (Since it shares the same Guardian Class).


I've just realised that it would be possible to make the yellow Maria in The Nightmare Room animate through two, or indeed all four of her sprite-frames, if you wanted her to, without causing the yellow foot guardian (which shares the same guardian class number) to deviate from the foot sprite - but only if you swapped around the position of the foot and the barrel on their sprite page (i.e. Page #9C - put the barrel at #9C40 and the foot at #9C60).


Of course, you would then have to adjust other instances of a foot or a barrel guardian elsewhere in the game, and also amend the pertinent addresses in the 'Game Over' routine accordingly.

#8123 Pokes for Fixing the Cell Graphics Bug in JSW

Posted by IRF on 24 November 2017 - 06:21 PM

Not that the defined ramp pattern in 'Under the Megatree' actually makes any sense for a ramp - it's a horizontal line, due to the value #FF stored at #C2C8.  Willy would 'sink through' the line as he walked along it, if ever it were present and visible on the screen.


Possibly Matthew inserted that non-zero graphical byte by mistake, whilst inserting values of #FF as default attributes for the ramp and conveyor (at #C2C4 and #C2CD)?

#8108 Post #4000

Posted by IRF on 24 November 2017 - 10:54 AM

Gentlemen, we have just reached post #8000!

#8064 Pokes for Fixing the Cell Graphics Bug in JSW

Posted by IRF on 22 November 2017 - 04:34 PM

What is noticeable is there are very few incorrect matches.

Which could suggest that Matthew knew about the problem, but worked around it rather than fixing it? I guess we'll never know.

Thanks for the file and the analysis.

P.S. One thing that your graphics on the line below the room name doesn't show, is any defined pixel patterns that are 'hidden' because the associated cells have a defined attribute with matching INK and PAPER settings. e.g. the ramp cells in 'Under the MegaTree'.

#8060 Pokes for Fixing the Cell Graphics Bug in JSW

Posted by IRF on 22 November 2017 - 03:49 PM

I have posted a method elsewhere that draws exactly what was defined.

For reference, this was the post that Norman Sword is referring to (thanks Norman):


#7956 Pokes for Fixing the Cell Graphics Bug in JSW

Posted by IRF on 18 November 2017 - 08:05 PM

I'm not sure if "spotted" is the right word here, but yes, when I said "If I understand the output correctly, SPECSAISIE shows the Cell Graphics Bug (=Block Graphics Bug) occurs in rooms 16, 31, 33, 41, 47, 51, 52, 62 and 63", I was only referring to the rooms where SPECSAISIE prints the initials 'BGB'.


I could see there were others bits of information in some rooms which seemed abnormal (in relation to other rooms), but I didn't try to analyse them. But you've done a thorough job of it :).


The point I was making is that SPECSAISIE prints the initials 'BGB' for at least half of the rooms in JSW!  But you only appear to have spotted the ones that happen to sit in the right-hand columns of the tables ('jutting out' from the main tables, so to speak).


If you look again you will see there are 'BGB' entries scattered throughout the tables that you failed to spot the first time!  ;)

#7947 Pokes for Fixing the Cell Graphics Bug in JSW

Posted by IRF on 18 November 2017 - 06:17 PM

I've just come across the first of the previously-documented instances of the CGB: the conveyor in Room 24 ('West of Kitchen').


Interestingly enough, the conveyor attribute matches one of the Water cell graphic bytes - but even if it didn't, the buggy CPIR loop would have encountered a match with two of the Earth cell graphic bytes anyway, before it reached the proper conveyor attribute byte!


EDIT: A similar thing is true of the instance affecting the conveyor in 'Tool Shed'.




Room 29 'The Nightmare Room' - the previously-documented instance of CGB affecting the conveyor is present in the table - but that only occurs because the attribute byte for conveyor is located at the wrong Offset Byte within the room data!  Once the misaligned bytes are shunted into where we think are their correct locations, the Cell Graphics Bug stops occurring even without the CGB Bug-Fix in place!


Also in the Nightmare Room, as I spotted earlier, the Fire cells (which are unused but which have a defined pixel-pattern and non-#FF attribute) would be affected by the CGB if any were placed in the layout.




I've been through all the tables, and I'm now confident that there are no more* matches that would give rise to the Cell Graphics Bug, other than with a default #FF attribute byte for unused room elements.


* i.e. no more matches other than the conveyors documented in the SkoolKit disassembly, the recently discovered instance affecting the Fire cells in 'A Bit of Tree', and the 'theoretical instance' affecting the unused Fire cells in 'The Nightmare Room' (which has a defined attribute and graphic, even though it is unused).




P.S.  I'd be happy to analyse similar tables for 'Manic Miner', if you have the time and inclination to put MM through the same SPECSAISIE analysis?

#7946 Pokes for Fixing the Cell Graphics Bug in JSW

Posted by IRF on 18 November 2017 - 06:10 PM

I've been going through the data.  As I highlighted above, there are lots of instances of an unused room element with attribute set to #FF (or -1 as it is referred to in the SPECSAISIE tables), which matches with a full-infilled pixel-row that is listed earlier in the room data.  Which is not a problem for unused room elements, of course.


Aside: This has prompted me to think of something - if any of the non-conveyor tiles in 'Conservatory Roof' had happened to have a fully filled-in pixel-row, then the Cell Graphics Bug would have caused the conveyor present in that room to have a pixel-pattern, even though Matthew never defined one!  Although since the conveyor attribute is set to #FF, this pixel pattern would only display itself when Willy is killed in that room, causing all the infilled pixels in the primary pixel-buffer instantaneously to flash in white-INK-on-black-PAPER!


Anyway, one non-#FF value that I have come across is in Room 18 ('On the Roof').  The ramp attribute byte is set to #07, and there is a graphic byte with that value in the Earth cell data (third pixel-row down).  However, the Cell Graphics Bug does not occur, because Water and Ramp cells share a common attribute in that room, and so the Water cell pixel pattern (which comes before Earth's definition in the data) takes precedence for the Water-Ramp combined cell-types.