crackers@xxxxxxxx wrote:
> Here's the code....
I've no time to examine the details of your code, but here are some advices...
- I would recommend to write a demo with a sprite alone first, then try to
add other things like a playfield. That may be easier than adding a sprite
to a playfield-only program, so that you can concentrate on the
sprite-related probles.
- your code seems too hmmm.... "spaghetti" :), please try to avoid the
branches in the kernel: in my game there are some of them, but usually very
"compact" and avoiding the "back and forth" things, ie:
CPX something
BCS not very far
LDA something else
EOR #$FF
INY
not very far:
STA ...
- it is usually very useful to have to deal with powers of two... so a good
height for a sprite is 8 scanlines. This isn't really true for the following
demo, but it's a wise choice in general.
The following picture will help you to understand the code.
A key point is that the variable with the sprite Y position refers to the
LAST line of the sprite.
---------------------------
start of tv screen
^
!
!
border, blank, score scalines...
!
!
V
---------------------------
first scanline -> 100
099
098
...
072 72-64 = 8>=8 -> draw the blank sprite
071 !------| 71-64 = 7<8 -> draw the 1st slice
070 ! ! 70-64 = 6<8 -> draw the 2nd slice
069 ! the ! ...
068 !sprite!
067 ! !
066 ! !
065 ! !
sprite y pos. -> 064 !------! 64-64 = 0<8 -> draw the last slice
063 63-64 = -1 = $FF >= 8 -> draw the blank
sprite
062
...
001
last scanline -> 000
---------------------------
^
!
!
border, blank, score, etc...
!
!
V
end of tv screen
---------------------------
Here's how could be the code... let's suppose an 8 lines height sprite.
SCANLINE is the current scanline in the kernel loop, and YSPRITE the sprite
Y position.
LDA #100
STA SCANLINE
...
LOOP: STA WSYNC ;3 (0)
LDX #0 ;2 (2)
LDA SCANLINE ;3 (5)
SEC ;2 (7)
SBC YSPRITE ;3 (10)
CMP #8 ;3 (13)
BCS NOSPR ;2 (15)
TAY ;2 (17)
LDX SHAPE,Y ;4 (21)
NOSPR: STX GRP0 ;3 (24) (worst case)
... 24*3-68= pixel 2
DEC SCANLINE
BPL LOOP
...
As usual, the data for the sprite shape will be upside-down...
SHAPE: BYTE %11111111
BYTE %10000001
...
BYTE %11111111
Please notice that I've done the cycle/pixel counts above in a hurry, so
they might be wrong :)
But it seems that the routine will write to GRP0 when the beam is about to
draw the second pixel on the scanline, so your sprite can't stay too near to
the left edge.
And now, the $1.000.000 question...:
"but if it must be a single scanline thing, where can I find the cpu time
for another sprite, missiles, background..."
Hints:
- Greg's "Rescue" is a single-scanline game, and uses a completely different
approach to draw the lander.
- My game is a double scanline resolution program, and uses a complex
variant of the example above.
Hope this helps...
Ciao,
P.
--
Archives updated once/day at http://www.biglist.com/lists/stella/archives/
Unsubscribing and other info at http://www.biglist.com/lists/stella/stella.html
