Piero Cavina wrote:
>
> > Da: Greg Troutman <mor@xxxxxxx>
>
> > The harder part was making them move at different speeds, but
> > it makes it much nicer I think.
>
> Sure... how did you do it?
> In my game, each enemy has a 16-bit register for the horizontal position.
> Only the high-order part is used to position the sprite.
>
> At the beginning, I had also a 16-bit, two's complement increment value for
> each enemy; then, to save RAM, I've chosen a 3-bit index to a table of
> increments.
> Since 1 bit is for direction, there can be up to 2^2=4 different speeds for
> the enemies. That seems a decent compromise and I could save a lot of
> memory.
I store the coarse (BNE-DEY) in the low, and the fine (STA HMPx) in the
hi part of one byte per, and one other byte that has a simple pixel plot
that creates the other byte each frame during VBLANK. That value I inc
or dec when it's time to move. I decide to move one pixel or not at all
on a frame by frame basis, via an indirected AND of the current frame
against a table of modulo values. But I wanted to twiddle things and
hand select the various speeds of each asteroid for each level and these
tables proved easy for that. Here's the pertinent code:
thisTime
ldy gameLevel
lda speedUpTable,y
sta speedUpIndirect
ldx #10
moveEnemies
txa
tay
lda frame
and (speedUpIndirect),y
beq moveOne
lda enemyX,x
jmp loopEnemies
speedUpTable
dc.b #<level1, #<level2
level1 dc.b 3,3,3,7,3,3,7,3,3
level2 dc.b 3,1,3,3,3,7,3,1,3
etc.
Each byte corresponds to the rows the asteroids occupy.
So the speeds I have are every frame, every 2nd, 4th, or 8th frame...
You don't really have much chance when the asteroids move 60 pixels per
second though, so I'm only using three speeds.
--
mor@xxxxxxx
http://www.crl.com/~mor/
--
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
