>I'm not quite sure, if I understand your theory corectly. Are you
>trying to say, that if you hit RESP0 and then hit it again 11 cycles
>later, what you'll get is two copies for each hit to RESP0 and
>not one copy for the first hit and three copies for the second?
>
>If that is the case, then I think you are wrong. If you do
>sta RESP0
>sta RESP1
>sta RESP0
>sta RESP1
>the second hit to RESPx happens after the first pixel of the second
>copy of a three sprite set. The output will be three sprites
>positioned five pixel after the second hit to RESPx. That would
>not be the case, if the first copy belonged to the first hit to
>RESPx.
Not quite. I tried what you just said - RESP0/RESP1/RESP0/RESP1. The
first RESP0 occurred on cycles 25, 26, and 27. I get Player 0 sprites at
pixels (counting from 0) 34, 52, 68, and player 1 sprites at pixels 43, 61,
77. I'm dead sure about those numbers. Note the 18-pixel gaps between the
first two copies of each player.
Doing the math, (27 * 3) + 5 - 68 = pixel 18 for the first (undisplayed)
copy of player 0, then 34 for the second copy of the first hit, which gets
displayed. Then, the first (undisplayed) copy of the second hit should be
at (33 * 3) + 5 - 68 = pixel 36. The second copy of that hit will be 16
pixels later, at 52, which we get, and the third copy of that hit will be
at 68, which we also get. The same thing happens with all the player 1
copies.
If you want to see this effect more clearly, instead of the second STA
RESP0, make the second instruction STA $2000+RESP0, to delay it an extra
cycle. The gap between the first two displayed copies of player 0 this way
makes it clear that the first displayed copy is coming from the first hit
and not the second - those first two copies do not match any possible NUSIZ
spacing.
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
