> Hi Andrew,
>
> > Using this fractional representation for positions and movement makes
for
> > easy adjustment between PAL and NTSC speeds. You just change the
increment
> > value (added every frame) and Bob's your Uncle.
>
> You *definitely* lost me here. How can an object move 1/n pixels?
>
> Say the object is at position 15. How do you move this object to position
15.5?
>
> Is this what you're taking about? Please elaberate as this is *very*
interesting.
Conceptually, yes. Visually on the screen it is at pixel 15. But as far as
your program is concerned, it's at pixel 15.5.
Let's say it was moving 1/2 a pixel per frame. so the very next frame it
would visually shift to pixel 16. The frame after that it would still
visually be at pixel 16, but as far as your program is concerned it is at
pixel 16.5.
The point of this is that you could, for example, have two object moving at
very slightly different speeds (say, 1/20th of a pixel per frame, and 1/21st
of a pixel per frame). After 21 frames they would be visually separated by
exactly 1 pixel. You have excellent "resolution" on movement - and
adjustment for various TV frame-rates, or game features such as
acceleration/decelleration, etc., are as simple as adjusting the increment
you add to the position per frame. You don't need to play around with delay
counters or anything.
It's just a shift in thinking. Rather than thinking "actually moves one
pixel every n frames" you are conceptually (and this is closer to how
objects actually move anyway) moving the object 1/n pixels every frame.
To represent the fractional movement, it's just a matter, as I said, of
having 2 bytes per coordinate.
xCoord ds 2
lda #0
sta xCoord ; fractional
lda #15
sta xCoord+1 ; integer
the object is now at pixel position 15.0
clc
lda xCoord
adc #128
sta xCoord
lda xCoord+1
adc #0
sta xCoord+1
the object is now at pixel position 15.5
Note: the draw only cares about the integer position - that is, "xCoord+1" -
which is still 15
clc
lda xCoord
adc #128
sta xCoord
lda xCoord+1
adc #0
sta xCoord+1
We've just added another half a pixel movement.
This time the carry will be set after the first add to xCoord, so we end up
adding one more to xCoord+1
ie: the visual part of our coordinate has adjusted from 15 to 16
Adjusting things from NTSC to PAL is as simple as changing the "movement"
you add to the coordinates every frame. And you get much finer control than
"delay n frames". For example, you can set the object to move one pixel
every 3.2 frames - just set the increment to 256/3.2 (=80 exactly) - doing
that with a "delay n frames" system would be rather tricky.
Let's say you wanted an object to move 20 pixels per second. On NTSC we
have 60 frames/second, so the fractional increment is 20/60 = 1/3 of a pixel
per frame (so the increment is 256/3 = 85 (close enough)). On PAL we have
50 frames/second, so the fractional increment is 20/50 = 2/5 of a pixel per
frame (so the increment is 256*2/5 = 102 (close enough)). So we use exactly
the same code in each case - we just use different movement increments for
PAL or NTSC.
Hope that's clearer.
Cheers
A
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
