Inserting patch vectors in JSW48 games

[IRF]

It could be useful to have a room-setup patch vector in addition to the main-loop patch-vector.

 

John Elliott

Edited April 24, 2016 by IRF

[jetsetdanny]

If it is, then so is setting the flying pig as Willy's sprite in "The Nightmare Room" in the original JSW, isn't it?

 

And *if* the Jukebox routine is called 'Danny's Jukebox routine' (which is an honour to me, of course :blush:), it should be called (as of "Willy's New Mansion SE", when it's released) 'Danny's Jukebox routine perfected by Ian', or something like that, since Ian has noticed and suggested a very significant increase in its efficiency since the release of "The Nightmare Edition" (in the sense of using significantly fewer bytes while achieving the same effect)  :) .

[IRF]

I think the Flying Pig Sprite, like the end sequence elements, is hard-wired into the Main Loop (in the original game, at least; although I seem to recall you saying there's a game in which Willy's sprite is determined according to the value of a particular offset byte in each room - which inspired your solution for the tunes).

So perhaps the Flying Pig Willy fulfills the 'patch' aspect, but not the 'vector' part?
 

The "as perfected by Ian" is a bit wordy, but maybe a brief mention in the readme would be in order?

 

And to continue the 'pig' theme, my assistance in this regard makes me feel better about that fact that you inadvertently ended up acting as my 'guinea pig', in implementing my initial suggestion for a patch to ensure the music is on at the start of the game.

 

A suggestion which required you to find spare bytes, when ultimately (only a week or two later, such is the speed at which my Z80 coding skills came on!) I identified an alternative which could have actually saved* you some bytes!!

 

(* EDIT: Although having thought about it again, I can see that this is not quite that simple, as three and two of the potential five bytes are located respectively before and after the 'Initialise Willy's Room number/coordinates' commands [the operands of which are treated by JSWED as variables, hence they can't easily be moved from their current locations].)

Edited April 26, 2016 by IRF

[jetsetdanny]

My comments in blue:

 

I think the Flying Pig Sprite, like the end sequence elements, is hard-wired into the Main Loop (in the original game, at least; although I seem to recall you saying there's a game in which Willy's sprite is determined according to the value of a particular offset byte in each room - which inspired your solution for the tunes).

 

That game is Andrew Broad's "Jet Set Willy: The Lord of the Rings" (highly recommendable to play - a classic  :) ).

So perhaps the Flying Pig Willy fulfills the 'patch' aspect, but not the 'vector' part?

 

The 'jukebox routine' is also hard-wired into the Main Loop [Main Loop (2) in SkoolKid's disassembly], so I believe there is no difference between it and the Flying Pig Willy check. One checks the value of Offset 237 (and acts accordingly), the other checks the room number (and acts accordingly). It's the same thing, essentially.

 

The "as perfected by Ian" is a bit wordy, but maybe a brief mention in the readme would be in order?

 

Yes, I will give credit in the Readme everywhere I feel it's due.

 

(* EDIT: Although having thought about it again, I can see that this is not quite that simple, as three and two of the potential five bytes are located respectively before and after the 'Initialise Willy's Room number/coordinates' commands [the operands of which are treated by JSWED as variables, hence they can't easily be moved from their current locations].)

 

I'm glad you've mentioned it. I wanted to comment on it before, but decided that it would be too complicated to describe and that the matter wasn't important enough to merit some kind of convoluted description. But you've made a nice, concise job of it  :) .

[IRF]

EDIT: I've taken this one off to a Private Message, as it was more of a specific suggestion to Danny, as opposed to a general post for wider consumption.

Edited April 27, 2016 by IRF

[IRF]

It could be useful to have a room-setup patch vector in addition to the main-loop patch-vector.

 

Excuse my being slow on the uptake, but I've just twigged what the distinction is between the above two examples!

 

The Main-Loop Patch Vector is called from the main loop at #89AD (as it 'says on the tin'!), whereas a Room-Setup Patch Vector would be called up from the routine at #8912 (which initialises upon entry, or resets after a loss of life, the state of the current room).

 

Danny, recalling your early attempts to implement the Screen Flash routine in The Nightmare Room, via a (main-loop) patch vector - they didn't actually flash, because the value of the Screen Flash Counter was being reset to the same chosen value on every pass through the Main Loop.

 

If instead, the Screen Flash Counter had been set to a (non-zero) value via a patch vector that was only called up when Willy first entered The Nightmare Room (i.e. a room-setup patch vector), then the Screen Flash would have descended through the colours in every subsequent game 'tick', until the counter reached zero - which is what we were trying to achieve (and which we later achieved by other methods)!

Edited July 9, 2016 by IRF

[IRF]

One of Geoff Eddy's patch vectors sends 'flying killer blocks' across the screen - am I right in thinking that these are effectively arrows, as far as the collision detection is concerned, and that they would be fatal to Willy if they hit anything with White Ink (e.g. ramps, for which White is the most common Ink colour)?

[jetsetdanny]

One of Geoff Eddy's patch vectors sends 'flying killer blocks' across the screen - am I right in thinking that these are effectively arrows, as far as the collision detection is concerned, and that they would be fatal to Willy if they hit anything with White Ink (e.g. ramps, for which White is the most common Ink colour)?

 

I think you're right. They 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?

[IRF]

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?

 

That would be because the Items are drawn before the Patch Vector (which causes the flying blocks) has been enacted.

 

Items are collected if, when the program comes to draw them, there is White Ink present in the cell where they are due to be drawn.  So if there's a White arrow already drawn there, it will collect the item.  At that point the killer blocks (I can't recall if they are White in any case?) haven't been drawn yet.

 

The arrow routine won't trigger a fatality by coinciding with a White item because the regular arrows are drawn before the items.  Conversely, the killer-block code which replicates the arrow routine, comes after the item-drawing code, so i guess they can potentially kill Willy if a killer block coincides with a White item in a given time-frame.  (By the way, does this ever happen in WNM-SE, or are the locations of the items such that they are never White when a killer block reaches them?  If that's not the case, I believe it could be made to be so by rearranging a few of the items within the Item Table.)

[jetsetdanny]

My replies in blue.

 

That would be because the Items are drawn before the Patch Vector (which causes the flying blocks) has been enacted.

 

Items are collected if, when the program comes to draw them, there is White Ink present in the cell where they are due to be drawn.  So if there's a White arrow already drawn there, it will collect the item.  At that point the killer blocks (I can't recall if they are White in any case?) haven't been drawn yet.

 

They are not white (although I'm sure they could be). In fact, in "WNM SE" the PV has been modified so that the killer blocks are cyan in "The Anteroom" and red in "Jump'n'Jive".

 

 

The arrow routine won't trigger a fatality by coinciding with a White item because the regular arrows are drawn before the items.  Conversely, the killer-block code which replicates the arrow routine, comes after the item-drawing code, so i guess they can potentially kill Willy if a killer block coincides with a White item in a given time-frame.  (By the way, does this ever happen in WNM-SE, or are the locations of the items such that they are never White when a killer block reaches them?  If that's not the case, I believe it could be made to be so by rearranging a few of the items within the Item Table.)

 

In both rooms where the killer blocks are applied in "WNM SE" I haven't noticed the effect of the block killing Willy because of colliding with an item which happens to be white at that moment.

 

I cannot say with certainty that if Willy were long enough in either of the two rooms, he wouldn't *ever* get killed because of a killer block - white item collision. However, it doesn't happen during the time he typically spends in either room, necessary to negotiate it successfully.

 

However, during the creation of "WNM SE", when I tried applying this PV in some other rooms, I had a constant problem of their killing Willy (unjustly) because of colliding with white items. This is one of the reasons why I finally applied this PV in "The Anteroom" and "Jump'n'Jive", where I don't observe such collisions.

 

Is it actually possible that in these two rooms the killer blocks don't *ever* collide with white items?

 

(it's OK if not; if they do, it must happen rarely enough not to be an issue for me).