>
> IMHO this is exactly the wrong way to do ball movement.
> Ball should be adjustable to move any number of pixels per frame, for
> example
>
> .23 pixels per frame... or 1.56 pixels per frame.
> Just because you program things on a frame by frame basis doesn't mean your
> objects have to move on a frame by frame basis. If you have a variable
Oy, it's going to tax my meager 6507 skills, but I'll try to buck up.
My understanding of 6502/7 math has always been a weak point, clearing
the carry and overflow bits and what not....I even have to boilerplate
simple stuff like a "greater than" comparison, because when I try to
rewrite it from scratch/memory, it never seems to come out right...
>
> This is the way that you also get nice smooth movement on the paddle
> controls, too, by the way. Not sure if you realise this yet... are you also
> doing the "every frame" or "two out of every three frames" method for that?
Er, method for what?
I've started to do some frame-by-frame analysis of Joust.
At first I thought they were using some speed limitators, but
maybe it just is a nicely divorced-from-pixels speed thingy, and
the fact that you can't speed up all that much even falling from
the ceiling. There's a lot of 4 pixels, 5 pixels, 4 pixels,
5 pixels, 5 pixels kind of falling in that...though that's for
every *other* frame, since its alternating the sprite with the
computer controlled bird.
--
KirkIsrael@xxxxxxxxxxxxx http://kisrael.com
"We're all soldiers in the war against entropy." --alt.folklore.computers
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
