29.10.01 07:36:48, Glenn Saunders <cybpunks2@xxxxxxxxxxxxx> schrieb:
>As they say, two steps forward, one step back.
You'll get used to that :-)
>Now the bad news.
>
>I noticed that the sprite scanout routine is broken and I never even
>noticed it until now!
>
>For one thing, it's showing one scanline too few of data for P1.
>
>Also, when I set the starting Y positions of P0 and P1 to different
values,
>neither displays at all.
>
>When I comment out either the P1Loop or P0Loop code, it makes the
other
>sprite not show up. I have no idea why the code for one is so
dependent on
>the other.
>
>So I'm definitely stuck there in need of some assistance, please? ;)
That's easy. You are using VDELPx to position your sprites in a two line
kernel with single line resolution. So you *must* write to both GRPx
registers, even when only one of the sprites is displayed. The easiest
way to do so, is to *always* write both registers during kernel.
Change your kernel into this:
P0Loop
TYA ;+2
SEC ;+2
SBC P0_Y ;+3
ADC #CarHeight+2 ;+2
BCS .drawP0 ;+2/+3
LDA #0 ;+2
BEQ .setP0 ;+3
.drawP0:
LDA (P0_CurrentFramePtr),Y ; +5
.setP0:
STA GRP0 ;+3
; MAX 20 cycles
TYA ;+2
SEC ;+2
SBC P1_Y ;+3
ADC #CarHeight+2 ;+2
BCS .drawP1 ;+2/+3
LDA #0 ;+2
BEQ .setP1 ;+3
.drawP1:
LDA (P1_CurrentFramePtr),Y
.setP1:
STA GRP1 ;+3
That increases your cycle count by two. If you are running out of cycles,
you could remove the SEC in the P1 code and put it into the LDA #0
branch of P0. This reduces the maximum cycle count for P0 by one, but
decreases the count for P1 by two. So that will save you one cycle.
BTW: Please define PF_Reflect in your code, not in your special vcs.h.
That makes it easier to compile your code.
Have fun!
Thomas
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
