Timing

SDL Development
1

Hello,

Can anyone here post the source to something that uses timing to control
the game speed?

I have been working on it for days, and I can not comprehend what to do
and what I am doing wrong. :frowning:

Thanks.

2

Ryan Wahle wrote:

Hello,

Can anyone here post the source to something that uses timing to control
the game speed?

I have been working on it for days, and I can not comprehend what to do
and what I am doing wrong. :frowning:

Thanks.

Just include this in your program loop and you program won’t need less
than TPF milliseconds per frame.

Karl.----------------------

int TPF=30

void wait()
{
now = time_ticks();
if ( now < next_frame ) {
time_delay(next_frame-now);
}
next_frame = time_ticks()+TPF;
}

3

With that your going to set yourself to one specific framerate, so no
matter how fast someones comp is, they will always get that same framerate
(or slower). What you should do is get the time for the beginning of the
current frame and compare it with the time from the beginning of the
previous frame. Then find the difference of the two values and use that to
calculate animation speeds and movement amounts, lets see, an example would
be.

int UnitMovementRate = 30; //Unit moves 30 pixels per second
int PreviousFrame; //time of beggining of previous frame
int CurrentFrame; //time of beginning of current frame

Now if the difference CurrentFrame-PreviousFrame is less than 1000
milliseconds, you have to move the unit less than 30 pixels. So you would
move the unit

((CurrentFrame-PreviousFrame) / 1000) * UnitMovementRate

I have source code from one of my old windows RTS’s I was writing. Bah,
DirectX. Im never going there again, but if anyone wants it for sample code
Ill glady zip it up and send it.

At 03:20 PM 9/4/99 +0200, you wrote:

Ryan Wahle wrote:

Hello,

Can anyone here post the source to something that uses timing to control
the game speed?

I have been working on it for days, and I can not comprehend what to do
and what I am doing wrong. :frowning:

Thanks.

Just include this in your program loop and you program won’t need less
than TPF milliseconds per frame.

Karl.

int TPF=30

void wait()
{
now = time_ticks();
if ( now < next_frame ) {
time_delay(next_frame-now);
}
next_frame = time_ticks()+TPF;
}

-Mongoose WPI student majoring in Computer Science
This messge sent from Windoze… ugh.

4

An explanation of the 3 methods that have been posted:

  1. The Bad Way
    Move the object a preset number of pixels for frame, this makes
    apparent speed dependent on frame rate, if it drops, game speed drops,
    and vice-versa.

    So Every Frame:

    PositionX+=VelocityX;
    PositionY+=VeloctiyY;

  2. The Mediocre Way
    Stall in a while loop every frame so that the fram rate never exceeds a
    set value say 20fps and move the object a preset number of pixels every
    frame. This is no good because you force people with machines that can
    do 60fps to run at 20 and people with less than 20fps still get altered
    game speeds.

    So Every Frame:

    While( SDL_GetTicks - FrameLength < StartOfFrame ) {}

    PositionX+=VelocityX;
    PositionY+=VeloctiyY;

  3. The Good Way
    Instead of considering you velocity units in Pixels per Frame, use
    Pixels per Second. This means that the speed of the object is constant
    no matter how long the frame took. Since Distance = Rate * Time we
    multiply the time since the last frame (in seconds) by the Velocity in
    Pixels per second to get the displacement for the current frame. This
    source for this can be consolodated, but this is very easy to read.

    Uint32 StartOfFrame = SDL_GetTicks();

    DrawThings();

    //TimeDelta is the number of ms the frame took to draw

    float TimeDelta = SDL_GetTicks() - StartOfFrame;

    //Convert to Seconds
    TimeDelta /= 1000;

    //Calculate how far the object moved in the time that elapsed d=r*t
    Sint32 DisplacementX = VelocityX * TimeDelta;
    Sint32 DisplacementY = VelocityY * TimeDelta;

    //Add the Displacements to get the new location
    PositionX += DisplacementX;
    PositionY += DisplacementY;

Stuart

5

You’re completely rigth. That’s the second good method. It increases
performance, but the CPU has no time to handle other processes. Of
course that’s not too bad, cause a game isn’t usually run in the
background. The other disadvantage is that this method is harder to
implement(eg. you can’t call your collision once per frame…).

Karl.

Garrett Banuk wrote:>

With that your going to set yourself to one specific framerate, so no
matter how fast someones comp is, they will always get that same framerate
(or slower). What you should do is get the time for the beginning of the
current frame and compare it with the time from the beginning of the
previous frame. Then find the difference of the two values and use that to
calculate animation speeds and movement amounts, lets see, an example would
be.

int UnitMovementRate = 30; //Unit moves 30 pixels per second
int PreviousFrame; //time of beggining of previous frame
int CurrentFrame; //time of beginning of current frame

Now if the difference CurrentFrame-PreviousFrame is less than 1000
milliseconds, you have to move the unit less than 30 pixels. So you would
move the unit

((CurrentFrame-PreviousFrame) / 1000) * UnitMovementRate

I have source code from one of my old windows RTS’s I was writing. Bah,
DirectX. Im never going there again, but if anyone wants it for sample code
Ill glady zip it up and send it.

6

Well this is the only way to allow faster computers get higher
framerates while retaining the same game speeds. Its pretty much what every
other game in existance does.

At 07:58 PM 9/5/99 +0200, you wrote:

You’re completely rigth. That’s the second good method. It increases
performance, but the CPU has no time to handle other processes. Of
course that’s not too bad, cause a game isn’t usually run in the
background. The other disadvantage is that this method is harder to
implement(eg. you can’t call your collision once per frame…).

Karl.

Garrett Banuk wrote:

With that your going to set yourself to one specific framerate, so no
matter how fast someones comp is, they will always get that same framerate
(or slower). What you should do is get the time for the beginning of the
current frame and compare it with the time from the beginning of the
previous frame. Then find the difference of the two values and use that to
calculate animation speeds and movement amounts, lets see, an example would
be.

int UnitMovementRate = 30; //Unit moves 30 pixels per second
int PreviousFrame; //time of beggining of previous frame
int CurrentFrame; //time of beginning of current frame

Now if the difference CurrentFrame-PreviousFrame is less than 1000
milliseconds, you have to move the unit less than 30 pixels. So you would
move the unit

((CurrentFrame-PreviousFrame) / 1000) * UnitMovementRate

I have source code from one of my old windows RTS’s I was writing. Bah,
DirectX. Im never going there again, but if anyone wants it for sample code
Ill glady zip it up and send it.

-Mongoose WPI student majoring in Computer Science
This messge sent from Windoze… ugh.

7

Couldn’t find an archive of the list (is there one?), so I’ll ask my
questions anyhoo.

  1. How do I make sure I’m running at a sane rate on any machine? Say I’ve
    written a game and the max frame rate I want is the refresh the
    monitor/gfx-subsystem can handle - how in SDL can I do this? Could SDL support
    a WaitForVerticalBlank() function across all supported formats - or does
    the cross platform/environment nature of SDL make it meaningless?

Maybe UpdateRect effectively does this anyway - in all cases?

I realise I could have a high res timer (is SDL_GetTicks() good for this?)
and delay the process to keep to a specific frame rate. But is this the
best way to do it?

  1. Timer events - I’d like it if you could schedule a timer event to come
    into the event loop as a one off or repeated event. This way you could
    add a ‘heartbeat’ to your event loop, or set a trigger for an event after
    a certain delay. I realise that timer events in any event loop are not
    amazingly accurate, but they can be useful.

ie, You’ve got a user interface based on mouse motion and button events
and want an animation going on as well - would you rather poll events
and handle all the timing yourself, or have a normal waiting event loop
that has a repeated timed event every 1/20th second to trigger the next
frame of the anim.

I guess I could have a thread that pushes an event onto the event queue

  • but there aren’t functions for pushing your own events in.

Or, could SDL_WaitEvent() gain a high res timeout?

Anyway, I’m going to play with these things and see what happens, but I
wondered if anyone had any advice.

ttfn,
John

8

ie, You’ve got a user interface based on mouse motion and button events
and want an animation going on as well - would you rather poll events
and handle all the timing yourself, or have a normal waiting event loop
that has a repeated timed event every 1/20th second to trigger the next
frame of the anim.

I usually set up a scanevents routine that polls all the SDL events and
does stuff with the information (as in map keys with shift/control, do
autorepeat, set up the mouse position, etc). I just want that called often
enough–I call it and it does nothing but process all the events inthe
input queue. In my main loop I just use SDL_GetTicks() to tell me what the
current time is, and I keep a number that I always increment by a fixed
amount depending on how frequenty I want to go through the main loop

for(;;)
{
	while(nexttime>SDL_GetTicks()) SDL_Delay(1);
	nexttime+=10;
	scanevents();
	if(checkdown(0x1b)) break;
	...
}

In this case the loop is supposed to run at 100/second.

Really SDL has it all there, I don’t see why people are coming up with
brilliant little additions. I would think that until you’re absolutely
certain what you want to do is impossible with the SDL mechanics as they
stand, don’t consider trying to modify/add to SDL. Work within the system,
it is really quite good.
-Dave

9

Yeah, sorry, you’re right. After sending that message I attacked the code
and it turned out to be far simpler than when I thought it through beforehand.

That’ll teach me to try and compile code in my head.

ttfn,
JohnOn Wed, Oct 13, 1999 at 09:23:22AM -0700, Dave Ashley wrote:

Really SDL has it all there, I don’t see why people are coming up with
brilliant little additions. I would think that until you’re absolutely
certain what you want to do is impossible with the SDL mechanics as they
stand, don’t consider trying to modify/add to SDL. Work within the system,
it is really quite good.