Re: Re: Moving objects 1/n pixels (was Re: RE: [stella] Climber5 source and binary)

Subject: Re: Re: Moving objects 1/n pixels (was Re: RE: [stella] Climber5 source and binary)
From: Christopher Tumber <christophertumber@xxxxxxxxxx>
Date: Fri, 18 Apr 2003 14:11:13 -0400
Dennis wrote:

>I thought you were saying to move the player a fractional position. Now I see it's sort of a count delay. Conceptionally I think this makes more since vs. "delay" per frame as I was doing. I'd like to spend some time looking into changing my system into the one described. This seems so straight forward now that you explained it.

This is also really usefull for games with a "thrust" button (presumably like, say, Thrust, but also if you're familair with the Veccy, Minestorm and Omega Chase Deluxe). Where instead of a fixed velocity, velocity is a factor of how long the "thrust" button has been pressed and velocity gradually decreases once the "thrust" is let go.

Building on Andrew's example:

    lda xCoord
    adc CurrentVelocityX
    sta xCoord
    lda xCoord+1
    adc #0
    sta xCoord+1

Where CurrentVelocityX starts at zero, increases gradually up to a certain maximum as long as the "thrust" is applied and then drops back down to zero once "thrust" is let go.

It becomes a little more complex if you're dealing with 360 degrees of possible movement, then you have to apply the thrust to both a CurrentVelocityX and CurrentVelocityY based on the direction of the thrust (vector projection - I'd generally just use a table of values with a preset X and Y acceleration depending upon the ship's directional facing rather than figure it on the fly).


Archives (includes files) at
Unsub & more at

Current Thread