Inserting patch vectors in JSW48 games

[IRF]

I believe that if it doesn't occur during one 'game-minute' (i.e. 256 ticks/time-frames), then it won't ever happen.

 

However, it's probably worth checking that that's the case in the final file, if you've shifted items around since last time you checked, because the colour of an item in a given 'tick' is dependent on the value of the tick counter (#85CB) and the item's position in the Item Table.  And if, for example, you've deleted and reinserted an item that sits further down in the Item Table (#A400-#A5FF), then all the items may have been 'nudged down' the table by JSWED, which might affect the relationship between the location of the killer blocks and the 'colour phase' of the items.

 

EDIT:  I should perhaps point out, for the wider readership(?), that this is only a potential concern if you have the 'Eight Colour-Cycling Items' Patch in place, otherwise the items are never White!

Edited September 7, 2016 by IRF

[jetsetdanny]

Thanks, Ian. That's reassuring  :) .

 

I've checked the first two in-game minutes in "The Anteroom" and there is no collision.

 

I'll double  check "Jump'n'Jive" later on, but I'm pretty sure there is no collision there in the first minute either.

[IRF]

Thanks, Ian. That's reassuring  :) .

 

I've checked the first two in-game minutes in "The Anteroom" and there is no collision.

 

I'll double  check "Jump'n'Jive" later on, but I'm pretty sure there is no collision there in the first minute either.

 

The reason I'm confident is that the items cycle through 8 colours, whilst the trajectory of each flying block passes through 256 cells (32 rows x 8 columns, in the top or bottom half of the screen - rather like a Constant Arrow in fact!), and 256 is exactly divisible by 8.

 

It amounts to this: if there isn't a fatal collision when the flying blocks pass through the items' locations first time round, then it shouldn't ever happen.

 

In contrast, I would wager that, in the rooms where you noticed the fatal collision happening, it occurred the first time that the flying block passed through the item in question, rather than in a subsequent 'game minute'?

 

I would also surmise that you could have avoided it happening - if you had wanted to pursue inserting the flying block effect into a room where you'd had the 'collision' problem - by moving the item one cell to the left or to the right [editing the hex code to do so], so that the collision [or rather, non-collision] occurred one 'tick' earlier or later, when the Item's colour had moved on from, or had yet to reach, White.

 

Either that, or you could have transposed the item's two entries in the Item Table with the adjacent pair of entries in the Table.  (Although if the second item were also located within the same room - and of course multiple items within a room often [though not always] occupy adjacent slots in the Item Table - then there's a 1 in 8 chance that it would have caused the blocks to collide with that item instead!)

Edited September 7, 2016 by IRF

[jetsetdanny]

Thanks, Ian.

 

 

In contrast, I would wager that, in the rooms where you noticed the fatal collision happening, it occurred the first time that the flying block passed through the item in question, rather than in a subsequent 'game minute'?

 

Yes, the first time.

[IRF]

I think you're right. [The Flying Killer Blocks] kill Willy if they collide with a white ramp (I've just checked it modifying the ramp's colour in "The Anteroom" in "WNM SE").

 

However, they kill Willy if they collide with items when these happen to be flashing in white (I *think*) - that's different from arrows, which would collect them?

 

Out of interest Danny, is this the reason why you recently made an enquiry (picking up an earlier idea of mine) about the possibility of restricting the items to flashing in six colours only (excluding Black and White)?

Edited September 14, 2016 by IRF

[jetsetdanny]

No, I asked the question when the issue of the Killer Blocks had already been solved (as far as I and the needs of "WNM SE" are concerned) by their being placed in rooms where the collision with white items apparently didn't happen.

 

I asked the question because I thought perhaps it might be even better not to have any items becoming black at any time, so that they are not invisible on black backgrounds.

 

Incidentally, Geoff Eddy says in his disassembly of Geoff Mode that the code used there "animates [the items] by 8 colours as in JSWII".

 

I now believe this is not true, because AFAICT the items in JSWII are animated by 7 colours - they are never black. That's what I can see by looking at the game (JSWII), at least. From this I infer that Geoff's code in this respect is different from the code in "JSWII".

Edited September 14, 2016 by jetsetdanny

[IRF]

In which case, a more complicated intervention must be taking place in JSW2. As I recall, you inquired as to whether it could be done by a simple 'tweak', as by that stage in WNM's development you didn't have the spare bytes for a more detailed bit of code.

 

Of course, seven-colour cycling items would always 'disappear' (for one tick in every seven) on any rooms with non-Black backgrounds.

[jetsetdanny]

An idea for developing a code when you've run out of ideas what else to do:

 

Write a code which will provide for items to cycle through 7 colours, in every room skipping the colour which is this room's background, so that no item ever disappears  :) .

[IRF]

Off the top of my head: assign the previous INK colour for the host cell for the item under consideration to the A register. Increment A, then AND 07 [to select the INK Bits only]. Then do a 'CP' - whose operand is the value of #80A0 from the current Room Layout Buffer, subject to an AND 38, then RRCAx3 [i.e. pick up the PAPER colour of the current room's Air cells and shift it into Bits 0-2].  Follow that by a JR NZ that leapfrogs another INC A (so if there's a colour match, that colour is skipped), topped off with another AND 07 for good measure.

(You would need to initialise each item's colour for the first tick in the room, so that in a multi-item room they don't all constantly match. In original JSW, that's achieved based on the tick counter added to each item's position in the Item Table; you might require another check to ensure that an item doesn't start off matching the background colour.)

Edited September 14, 2016 by IRF

[IRF]

I believe all the screens in JSW2 have Black backgrounds anyway?

Edited September 14, 2016 by IRF