> Hi there!
>
> Cool stuff, looking good!
>
> > Suggestions welcome. Thanks!
>
> Uhm... angles other than 45° and some randomisation to prevent deadlocks?
For this demo, both X and Y have a starting velocity between 1 and 3 pixels
per frame. The angle and speed changes with each Reset you perform, but I
didn't want either axis to have 0 movement. Unfortunately, since I'm
dealing with whole pixels, I can't approach 90 degree intervals without
zeroing out one of my values, resulting in a boring, predictable straight
line.
I think I see subpixel movement in my future. It shouldn't be too difficult
to retrofit my existing code... err... but I've never played with 16-bit
negative numbers in assembly before.
I use this code to multiply an 8-bit number by -1:
lda ballmx
eor #$FF
clc
adc #$01
sta ballmx
For a 16-bit number, let's see...
lda ballmx+1 ; LSB
eor #$FF
clc
adc #1
sta ballmx+1
lda ballmx ; MSB
eor #$FF
adc #0
sta ballmx
This seems like it would work. I think the deflection code will still work
even though the ball won't necessarily move every single frame.
As for the deadlocking, the kind that you see in the binary I had included
shouldn't be a problem. I'm more concerned about a mostly-cleared board
having 1 or 2 unhittable bricks. In that case, a gradual velocity
shift/increase should do the trick. Also, I think adding english to the
paddles will be easier with subpixel movement.
Thanks for the feedback (and for listening to me think out loud).
-Lee
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
