IRF

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?

Yes, you have to be very careful to 'follow the rules' when it comes to flags. I came a cropper a while back when I (falsely) assumed that a DEC A [or DEC L] command would set the Carry flag when A is decremented from #00 to #FF.

Thanks for confirmation. I was going to test it out as is, just to see how it messes with some familiar layouts - I still might, just for fun...

If I may be so bold, I feel that I must query something from one of Norman Sword's earlier posts. The two RRCA instructions, highlighted in bold in the quote below, should actually be two RLCA instructions? (Assuming that the room layout data is stored in the same way that it is in original JSW. i.e. with Bits 6 and 7 of each compressed room layout byte corresponding to the leftmost of the four room cells that are defined by that particular layout byte, Bits 4/5 relating to the next room cell along, then Bits 2/3, and finally Bits 0 and 1 corresponding to the rightmost room cell in that group of four cells.) Two RLCA operations would rotate two bits of the Accumulator into Bits 0 and 1, ready for selection by the subsequent AND #03 gate, in the correct order to consider the four cells from left to right in turn (before moving on to consider the next cluster of four room cells to the right). http://jswmm.co.uk/topic/185-free-space-and-code-optimisation-in-jsw/?p=6101 Otherwise, it's an excellent bit of optimisation.

Ah yes, the black keys on Matthew's title screen are wrong. Well spotted! (They should alternate between a pair of two black keys, and a group of three, as you move along the keyboard. But in Matthew's graphic, there are two adjacent pairs of black keys under the word 'ENTER'.) Also in the title screen of Norman's 'Software Projects + Bug Byte' version of Manic Miner, I've just noticed the Software Projects triangle rotating on the grassy area, the filling in of the blacked out areas (where parts of the layout of 'Final Barrier' would go), and the initials D.P.R. in the band of yellow and green 'scrub' (in character-row 7)...

Note that my original attempt at this just had an Earth cell platform in row 2. (Earth being chosen so that Willy couldn't collect the item by jumping up from below, i.e. so that his head passes through the platform and collects the item.) However, that didn't work - Willy jumped off the top of the room, without landing on the platform. I think that is because the effect of the POKE will only work if it detects a 'standonable' cell underneath Willy. But he is prevented him from moving into the same cell-column as the Earth cells, until he has ascended past them (into rows 0 and 1). And then during a jump, the 'Move Willy' routine checks whether Willy has gone past the top of the room before it moves him sideways to a position where he is above the end cell of the platform. Catch 22! So in the layout of the 'item reachable' attached file (the one with the POKE enabled), the platform starts off as Water (so that Willy can 'step' up onto it, and then walk along it), but it changes along its length to comprise of Earth at the point where the item is located on it (so that the item can't be collected by jumping up from below).

That's already been brought to my attention by Richard Hallas. :-) POKE #98D2, #0C fixes it.

Sorry, that last post wasn't aimed at you particularly/personally, Andy. I meant in general terms, people who use decimal numbers when coding. Everything seems so much more logical to me, once you get your head around thinking in hexadecimal. Especially things like lookup tables where the addresses have a proportional relationship with the values stored in them. Sometimes I think life would be so much easier if we had sixteen fingers, so that our whole system of counting had evolved differently! :P

I honestly don't know how you cope with working in decimal! Probably the only time I use it is when inserting POKES into SPIN (and even then, I wish it had a 'POKE in hexadecimal' function!)

No I didn't read the spoiler first - I just spotted the difference! Try POKE #A63D, #04. B)

There's a pixel missing at the driver's side of the car! I never noticed the white (chalk?) cliff-face before. I guess Willy may have lived near Dover before he moved to Surbiton...

I also suspect, from looking at the 'Move Willy (3)' routine, that the last of the seven POKES will have the following side effect: If Willy is in a room in which the Earth attribute is set to zero, then Willy will be unable to move rightwards across a cell boundary, not even through Air or Water blocks. EDIT: By the above, I mean even if the Air attribute is not set to the same value of zero (which would mean that all Air blocks would have combined Air-Earth properties, so he wouldn't be able to move either left or right through the Air). Scrap that, I was wrong. The SBC HL,DE command at #90A5 means that the Zero Flag is NOT set when the RET Z command at #90A8 is reached.

I mentioned in the past that I found the above didn't work properly when Willy attempted to climb up the left-hand wall of 'Halfway up the West Wall' (having walked into that room from 'The Bathroom'). Willy could jump up the wall but got stopped halfway up (appropriately enough for that room!) Now I have figured out why that happened. The first two POKES NOP out the CP (HL) commands in the checks for Earth blocks in the 'Move Willy (1)' routine. Ordinarily, that means that the subsequent JP Z, #8EBC (jump to the code that deals with Willy hitting his head on an Earth block whilst jumping) doesn't come into effect. However, if Willy jumps up into the top-left cell of either the upper half or the lower half of the screen, then the L register will hold the value zero (HL holds Willy's attribute coordinates), and so the Zero Flag will have been set by the CALL to #8E9C from #8DF4 (the OR L command at #8EAA is the precise culprit). As a result, the jump to #8EBC is executed when Willy is located at coordinates (0,0) or (8,0), and Willy is prevented from jumping any higher by the Earth cells. EDIT: Indeed, I believe (although I haven't tried this out yet) that the above POKES will prevent Willy from jumping straight upwards in the left-most cell-column beyond the top of the screen, or beyond the boundary between the upper and lower halves of the screen, in any circumstances - even if there is no Earth cell present to block him!

By way of explanation, the above POKE means that a jump is terminated whenever a standonable block lies beneath Willy's sprite and he is cell-row-aligned. A normal jump only comes to a premature end when the above circumstances hold true and Willy is in the descent phase of the jump. With the above POKE in place, a jump can be terminated during the ascent phase, if a solid platform lies beneath Willy's sprite. ****** The above POKE also allows Willy to access a platform in cell-row 2 via a jump from below. (i.e. a platform which has two cell-rows of air between it and the top of the room.) Normally, Willy couldn't jump up onto such a platform, because the jump would cause him to breach past the top of the room and into the room above. He could only access such a platform via another means (such as walking up a ramp or dropping onto it from the room above). This quirky manoeuvre could form the basis of an interesting room design. e.g. an item which can only be collected in the manner described above. Please see the two attached test files; the only difference between the two is that one has the above POKE implemented, the other one doesn't. Try to collect the item in 'Ballroom East' in the 'Item unreachable' file first. Then try to do the same in 'Item reachable'. (Note also the interesting 'climbing the ladder' effect of the POKE in the latter file.) Item unreachable.z80 Item reachable.z80

Andy, by 'break' [brake?] in the above did you mean pressing the 'P' key to stop Willy from running towards the toilet? (Something which I came up with a fix for, although I'm not sure if Mickey has implemented that fix yet or not?) Or did you mean pressing SHIFT+SPACE to abandon the game during the toilet dash?

Mickey, I've just spotted a minor bug in the JSW 'Game Over' routine - the 'AND #FA' at #8CAF should be replaced with 'AND #F8'. This doesn't affect the original game, it's more of a 'game engine' fix, but it allows a full range of INK colour choices for the Barrel on the Game Over screen. With the AND #FA in place, the choice of INK colour for the Foot/Willy can restrict the possible colours for the Barrel.

Looking at the 'Game Over' routine, I believe that the problem we once encountered in implementing certain INK colours for the Barrel (some choices for which were influenced by the chosen INK colour for the Foot/Willy) could be eliminated by simply replacing the value '#FA' at #8CB0 with '#F8'. i.e. the AND gate at #8CAF should only select the Barrel's PAPER/BRIGHT/FLASH bits (3-7), leaving the OR gate at #8CB1 to fully control the Barrel's INK bits (0-2).

I believe that you can save two bytes at #8DD7, one byte each at #8EDA and #8FA5, and two bytes at #8FC6. This can be achieved by deleting the BIT 7, A instructions, and then changing the conditionality of the subsequent jumps/returns, from JP Z/JR Z/RET Z to JP P/RET P. EDIT: In the case of #8FA5, it needs to be a JP M. ****** I can't see any reason why the RLC A at #8F14 couldn't be a RLCA instead, saving one byte.

The number of posts on this forum overtook those on the Yahoo group yesterday, I believe. Let's hope that a bit of healthy competition sparks a revival in the latter...