OK, so I have six sprites that are now all at position #30 and I am trying to move them in a straight line towards the right. Each at different velocities.

So here is what I have:

Code:

ldx #0    ldy #0 !loop:    clc    lda xpos_vel, y    adc $d004, x    sta $d004, x    inx    inx    iny    cpy #6    bne !loop- ... .pc = xpos_vel    .byte 1, 2, 4, 2, 2, 1

I am reserving sprite 1 and 2 for my main character. But the above routine doesn't seem to work. What am I doing wrong?

** EDIT **

DUH!!! I forgot to add: sta $d004, x

LOL!! Nevermind. But maybe this might help someone else?


Now, when I set the Y positions, this is what I use and it works.

Code:

ldx #0    ldy #0 !loop:            // set y positions    lda ypos, y    sta $d005, x    inx    inx    iny    cpy #6    bne !loop- ... .pc = ypos    .byte 48, 72, 96, 120, 144, 168

Thanks!

Using straight integers for velocity values limits your options somewhat.

Only gives you 10 or so useful unique values per direction - anything bigger just becomes too fast to be very useful.

You can fairly easily employ "fractional" values by using 2 bytes per sprite axis instead of 1.

Have the integer "velocity/direction" value in one byte, "fractional velocity" in the other and have the fractional part get added to an "accumulator" value, and if it overflows, it gets added to the position on that occasion.

Use the high bit of the velocity/direction value to determine if the sprite moves in a positive or negative direction.

The coding is somewhat more complex than just doing movement by integer only but you end up with exponentially more useful velocity possibilities.

Best method is probably to add the fractional to the accumulator values, store it.
Then get the velocity/direction byte. PHP to save the "N" flag.
AND with #$7F to leave velocity only, ADC #0 to add the accumulator overflow that would be left in the Carry.
Then PLP to get the previous "N" state back. Accumulator has the velocity in force for the current iteration. Then you BMI to the code that subtracts velocity from the XPos, otherwise it gets added to the XPos.


The other advantages of fractional movement is the ability to do nice smooth acceleration, and very slow movement - down to about 1 pixel every 5 seconds.

Wow. That's some insanely good ideas!!

Never thought about fractional movements. And I like the idea of using the high bit for positive/negative movement.

Thanks!!