Re: RE: [stella] Climber5 source and binary

Subject: Re: RE: [stella] Climber5 source and binary
From: "Andrew Davie" <atari2600@xxxxxxxxxxxxx>
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
value (added every frame) and Bob's your Uncle.


Archives (includes files) at
Unsub & more at

Current Thread