Fun with Arrows

[IRF]

I'm just wondering what would happen if you were to NOP out the bytes at #925F-#9266 in the code that draws Arrows.

 

I believe (without having tried it yet) that, instead of only being drawn on the screen for 32 'ticks' out of every 256, an Arrow would continually 'wrap round' and pass through the screen again, in the same direction and remaining within its designated cell-row, but moving down one pixel-row each time it went beyond the edge of the screen (looping back to the top of its cell-row once each time it reached the bottom of the cell-row)!?

 

Of course, it would cause some interesting Invalid Arrow side-effects when the Arrow passed along the top and bottom pixel-rows!

[IRF]

I'm just wondering what would happen if you were to NOP out the bytes at #925F-#9266 in the code that draws Arrows.

 

I believe (without having tried it yet) that, instead of only being drawn on the screen for 32 'ticks' out of every 256, an Arrow would continually 'wrap round' and pass through the screen again, in the same direction and remaining within its designated cell-row, but moving down one pixel-row each time it went beyond the edge of the screen (looping back to the top of its cell-row once each time it reached the bottom of the cell-row)!?

 

Of course, it would cause some interesting Invalid Arrow side-effects when the Arrow passed along the top and bottom pixel-rows!

 

I wasn't quite right with the above - the Arrow descends through each cell-row in turn down either the top half or the bottom half of the screen (depending on whether its allocated y-coordinate in the room's guardian specification data is in the top or bottom half), but stays within the same pixel-row within each cell-row.  Therefore the Arrow in such circumstances will either be Invalid, or not, each time it appears.

 

See the attached 'Constant Arrow' test file, with the aforementioned bytes NOPped out.

Constant Arrow Test.z80

Edited August 18, 2016 by IRF

[jetsetdanny]

Ian, that's a fantastic invention, I really like it!  :D Congratulations!

 

So you have created a true "constant arrow" now. I once used that adjective to refer to what Andrew Broad described as "bouncing arrow" (because I couldn't remember which word he used - meaning an arrow which goes back and forth, really being eight arrows inserted at appropriate intervals). And now you've made my description a whole new reality :) .

 

For a possible future game design, it's better that the arrow doesn't become valid and invalid, IMO. If it did, it would mess up its possible applications.

 

Just one question now: the way you've implemented it, it would affect all arrows in the game, wouldn't it? It would be  nice to have such special arrows only in some selected rooms...

[IRF]

Ian, that's a fantastic invention, I really like it!  :D Congratulations!

 

So you have created a true "constant arrow" now. I once used that adjective to refer to what Andrew Broad described as "bouncing arrow" (because I couldn't remember which word he used - meaning an arrow which goes back and forth, really being eight arrows inserted at appropriate intervals). And now you've made my description a whole new reality :) .

 

For a possible future game design, it's better that the arrow doesn't become valid and invalid, IMO. If it did, it would mess up its possible applications.

 

Just one question now: the way you've implemented it, it would affect all arrows in the game, wouldn't it? It would be  nice to have such special arrows only in some selected rooms...

 

Indeed, I had your earlier comment in mind when I named the test file!

 

If a 'Constant Arrow' starts off as Valid (because it's been inserted in a pixel-row other than the top or bottom one within a cell-row), then it will remain Valid throughout the 256-tick game cycle (and vice versa - which could be fun!)

 

Yes, it's a game engine change that would affect all Arrows in the game.  But you could make the intervention in the code via a Patch Vector, with the correct code restored by default in rooms where you don't want the effect.

Edited August 19, 2016 by IRF

[IRF]

One other point - it wouldn't really make sense to have the 'Arrow Warning' sound at a random point when the Arrow is constantly firing?!

[jetsetdanny]

Unless the code was so tweaked that the warning sound would be when the arrow is e.g. 10 rows from Willy, or something like this...

[IRF]

Unless the code was so tweaked that the warning sound would be when the arrow is e.g. 10 rows from Willy, or something like this...

 

I think the sound is supposed to represent the Arrow being 'fired', perhaps it should occur just as the Arrow enters the side of the screen - of course, that would mean it should be sounded eight times in each 256-tick cycle, rather than once in each cycle!

 

i.e. Trigger the effect every time the Arrow occupies cell-column #00 if it's a left-to-right Arrow, or cell-column #1F if it's a right-to-left type.

 

Actually, there's only one tick difference between those two, which isn't worth splitting hairs about.

 

So you could just do a AND #1F on the Arrow's x-coordinate (stored at IX+$04 in the Guardian Buffer), in place of the command at #924C (you could also remove the commands at #9240 and #9247), then the JR NZ at #924D would ensure that the sound effect occurred each time the Arrow wrapped round the edge of the screen (just after it appears flying rightwards; just before it appears travelling leftwards).  Those code changes would all have to be put back to normal in rooms with normal Arrows, though!

 

One other point, I referred earlier to the Arrow moving one cell-row down the screen each time it reappears.  However, that only applies to a left-to-right Arrow; for a right-to-left it would move up by one cell-row each time it wrapped around.

Edited August 19, 2016 by IRF

[IRF]

One point that I didn't mention - it may be obvious but anyway - in the case of a 'Constant Invalid Arrow', the effects would occur throughout all eight cell-rows of either the upper or lower half of the playing area (being the opposite half to where the arrow is located).

[IRF]

And of course, the precise manifestation of the Invalid Arrow's 'side effect' (colour-attribute blocks, a temporary pixel trail, or a permanent pixel trail) depends on the exact pixel-row position of the Invalid Arrow (within each cell-row, and in the top or bottom half of the screen).