## Re: RE: [stella] Climber5 source and binary

 Subject: Re: RE: [stella] Climber5 source and binary From: "Andrew Davie" Date: Fri, 18 Apr 2003 23:31:54 +1000
```> I found time to play with these routines and I have a few questions. Some
I'm sure will benefit others in their conversion process.
>
> > Example:
> >    lda playerMotion
>
> Would playerMotion here be the "delay" frames I have set up for the
players (i.e. 4, 3, 2, and 1)?

I haven't really been following this discussion of motion carefully, but the
above question suggests that you're basing motion on "move one pixel, then
delay n frames".  If you change your thinking around and instead of moving 1
pixel every n frames, actually move 1/n pixels every frame.  Then you have
the same movement speed, but you are now able to handle movement in a more
generic fashion.

But how do you move "1/n" pixels?  Easy.  Instead of storing coordinates as
just a whole number, have a 2nd byte which represents the fractional part of
the coordinate.  ie:  instead of position being 3 pixels across.... it is
3.0 pixels across.  The decimal point is imaginary.  Basically handle your
movement calculations with 16-bit values, but have a conceptual decimal
point between the two bytes.  So you have 8 bits of "whole" pixels, and 8
bits of "fractional" pixel.  So to move "1/n" pixels, you add "1/n * 256" to
the low byte of the 16-bit value (and carry to the high byte as
appropriate).  If n were 3, then your increment value every frame would be 1
* 256 / 3 = 85 roughly.

Using this fractional representation for positions and movement makes for
easy adjustment between PAL and NTSC speeds.  You just change the increment