Calculating speed of an object in a game

[mcgeezer]

Again... math..ughhh

I'm struggling with the math behind how to move objects at very slow speeds in a game.

Take in the Bomb Jack example when the UFO hits a platform and is very close to Jack, the UFO will go after Jack at a very slow speed....so it's if its 8 pixels away, the UFO will move toward Jack at about 2 frame per second.

At the moment I update the UFO every frame, meaning it will move 50 pixels every second... but how the hell do I get it to only update at a smaller frame rate based on distance from another object. On this partiucar problem I actually understand the math of Speed = Distance / Time, it's just I'm struggling to code it.

Do any of you guys have any good 68000 assembler examples that I could look at and adapt that could help me out?

Any help is really appreciated.

Geezer

[Apollo]

I guess that fixed point arithmetic could be the solution. My favourite site about this topic seems to be vanished but you can still find its last version on webarchive.org

https://web.archive.org/web/20070206...c/fixedpnt.htm

You'll get fractional pixels per frame movement so you're not bound to absolute numbers.

[bloodline]

Originally Posted by Apollo

I guess that fixed point arithmetic could be the solution. My favourite site about this topic seems to be vanished but you can still find its last version on webarchive.org

https://web.archive.org/web/20070206...c/fixedpnt.htm

You'll get fractional pixels per frame movement so you're not bound to absolute numbers.

Fixed point is a really good way to do this, but is still a bit CPU hungry on a 68000, if the framerate was 50fps, my solution was to add a tiny delay counter to the beginning of each object's update function to make the movement a fraction of the screen update frequency.

in C it would look like this:

void update(int delay){

    static int countDown =0;

    --countDown;

    if(countDown>0){
        return;
    }

    countDown = delay;

    //update code
}

This way you don't waste CPU cycle calculating an update that would not be visible on screen.

[Apollo]

I don't think that the lsr.w/asr.w after adding/substracting the fixed point delta has that much of an impact performance wise.
Of course to existing code that means that you probably should "convert" all your coordinates into that magnitude/fractional format you've chosen (most of the time I use 8:8) so you stay in the 8:8 all of the time and only do the final bit shifting if you want to "render" your objects in to the framebuffer.

In the end I don't know of any other way how to overcome the "move an object slower than 1px per frame" problem, other than inserting a "frame-skipping" delay.

[hooverphonique]

if using frame-skip, one would need to calc how many frames to skip after each actual move, otherwise only moves of whole fractions of 50 pixels per second are possible.

[Leffmann]

The snippet I posted in the other thread does exactly this. It moves the ufo to Bombjack in a fixed number of steps, so it moves slow if he's near and fast if he's far. You only have to add code to determine when the ufo has hit the screen edge or something else.

As the code is written it does this in 64 steps, which seems to be what the arcade game is doing, but the code can be changed to allow finer control.

[mcgeezer]

Originally Posted by Leffmann

The snippet I posted in the other thread does exactly this. It moves the ufo to Bombjack in a fixed number of steps, so it moves slow if he's near and fast if he's far. You only have to add code to determine when the ufo has hit the screen edge or something else.

As the code is written it does this in 64 steps, which seems to be what the arcade game is doing, but the code can be changed to allow finer control.

Hi Leffmann,

Yep - until I asked the question in this thread I didn't realise what your code was doing.

Thanks to everyone who's replied - such a simple solution and now the UFO floats very slowly if I need it to.