Delta time?

Leo_M_Cabrera · October 12, 2007, 10:35pm

Hello people of SDL!

I’ve been capping the framerate in my games the last few times, but I
want to give delta time a try… Here’s the code I have modified to work
with DT:-----------------------
oldTime = SDL_GetTicks();

while (1)
{
	newTime = SDL_GetTicks();
	delta = newTime - oldTime;
	
	/* Update control status */
	handleControls(controls);
	
	/* TODO: Pause, not exit */
	if (controls[K_PAUSE]) exit(0);

	/* Process game logic */
	doLogic(delta);

	/* Render our scene */
	renderBackground();
	render(0);
	
	/* So we don't use 100% CPU */
	SDL_Delay(1);
	
	oldTime = newTime;
}

In doLogic(), what I had done while capping FPS was add 0.05f to the
ball’s speed (acceleration) and multiply by 0.99f (deceleration).

But how would I modify those values to work with my delta?

Thanks!

Justin_Coleman · October 12, 2007, 11:31pm

Multiply your framerate (60/sec?) by each of those numbers to get the
total change per second, then multiply the per-second value by however
much (fractional seconds) time between frames. The 1% deceleration may
need to be tweaked, since it’s dependent on the current speed and not
a fixed value.On 10/12/07, L-28C wrote:

Hello people of SDL!

I’ve been capping the framerate in my games the last few times, but I
want to give delta time a try… Here’s the code I have modified to work
with DT:
    oldTime = SDL_GetTicks();

    while (1)
    {
            newTime = SDL_GetTicks();
            delta = newTime - oldTime;

            /* Update control status */
            handleControls(controls);

            /* TODO: Pause, not exit */
            if (controls[K_PAUSE]) exit(0);

            /* Process game logic */
            doLogic(delta);

            /* Render our scene */
            renderBackground();
            render(0);

            /* So we don't use 100% CPU */
            SDL_Delay(1);

            oldTime = newTime;
    }
In doLogic(), what I had done while capping FPS was add 0.05f to the
ball’s speed (acceleration) and multiply by 0.99f (deceleration).

But how would I modify those values to work with my delta?

Thanks!

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Leo_M_Cabrera · October 13, 2007, 12:01am

Yep, I can’t seem to figure out a way to “tweak” the slowdown…

Justin Coleman wrote:> Multiply your framerate (60/sec?) by each of those numbers to get the

total change per second, then multiply the per-second value by however
much (fractional seconds) time between frames. The 1% deceleration may
need to be tweaked, since it’s dependent on the current speed and not
a fixed value.

On 10/12/07, L-28C <@Leo_M_Cabrera> wrote:
Hello people of SDL!

I’ve been capping the framerate in my games the last few times, but I
want to give delta time a try… Here’s the code I have modified to work
with DT:
    oldTime = SDL_GetTicks();

    while (1)
    {
            newTime = SDL_GetTicks();
            delta = newTime - oldTime;

            /* Update control status */
            handleControls(controls);

            /* TODO: Pause, not exit */
            if (controls[K_PAUSE]) exit(0);

            /* Process game logic */
            doLogic(delta);

            /* Render our scene */
            renderBackground();
            render(0);

            /* So we don't use 100% CPU */
            SDL_Delay(1);

            oldTime = newTime;
    }
In doLogic(), what I had done while capping FPS was add 0.05f to the
ball’s speed (acceleration) and multiply by 0.99f (deceleration).

But how would I modify those values to work with my delta?

Thanks!

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

David_Olofson · October 13, 2007, 12:01am

[…]

In doLogic(), what I had done while capping FPS was add 0.05f to the
ball’s speed (acceleration) and multiply by 0.99f (deceleration).

But how would I modify those values to work with my delta?

It’s easy (well, almost) as long as things are moving at constant
speeds (just scale the velocities), but acceleration and jerk (or
jolt, or “change in acceleration”) require more maths for correct
results. For speed and acceleration, you need this to update your
position each frame:
position += velocity * delta +
acceleration * delta*delta / 2;

That’s the easy part! The real problem is events, such as collisions
and various game logic events that affect object motion. Collisions
and time based events can nominally occur at any time - usually
somewhere in between the points in logic time where you perform the
updates. At very low frame rates, you may even fail to detect
collisions, and responses may be totally off, unless you deal with
this somehow.

Indeed, in most cases you’ll be fine with good approximations
(Runge-Kutta, for example), but if you want it deterministic to the
point where you can record a demo, control/decision input only, and
play it back correctly at any other frame rate, you may be in for
some serious math exercises.

So, what do you do? For most applications, whether you want to keep
your game logic nice and simple, or you want totally deterministic
behavior, or both, I believe the most sensible solution is to use a
fixed “virtual” logic frame rate along with interpolation, sometimes
referred to as “tweening”.

I’ve posted on this before (search the archive for “fixed logic frame
rate” and stuff like that), Kobo Deluxe uses it (to keep the original
XKobo logic running at the fixed rate it was designed for), and Fixed
Rate Pig over at olofson.net is a small but playable game that is
perhaps somewhat easier to read and understand.

Someone posted a link to a very nice paper on this, but I can’t seem
to find it now…

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'On Saturday 13 October 2007, L-28C wrote:

Torsten_Giebl · October 13, 2007, 12:12am

Hello !

Someone posted a link to a very nice paper on this, but I can’t seem
to find it now…

Is this the paper you mean ?

http://www.gaffer.org/game-physics/fix-your-timestep/

CU

David_Olofson · October 13, 2007, 12:16am

[…]

Is this the paper you mean ?

gaffer.org is for sale

Yup, that’s the one. Thanks!

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'On Saturday 13 October 2007, Torsten Giebl wrote:

Justin_Coleman · October 13, 2007, 12:40am

Quick and dirty way might be to determine how many frames your
timestep is equivalent to, and use that as the % slowdown.On 10/12/07, L-28C wrote:

Yep, I can’t seem to figure out a way to “tweak” the slowdown…

Justin Coleman wrote:
Multiply your framerate (60/sec?) by each of those numbers to get the
total change per second, then multiply the per-second value by however
much (fractional seconds) time between frames. The 1% deceleration may
need to be tweaked, since it’s dependent on the current speed and not
a fixed value.

On 10/12/07, L-28C wrote:
Hello people of SDL!

I’ve been capping the framerate in my games the last few times, but I
want to give delta time a try… Here’s the code I have modified to work
with DT:
    oldTime = SDL_GetTicks();

    while (1)
    {
            newTime = SDL_GetTicks();
            delta = newTime - oldTime;

            /* Update control status */
            handleControls(controls);

            /* TODO: Pause, not exit */
            if (controls[K_PAUSE]) exit(0);

            /* Process game logic */
            doLogic(delta);

            /* Render our scene */
            renderBackground();
            render(0);

            /* So we don't use 100% CPU */
            SDL_Delay(1);

            oldTime = newTime;
    }
In doLogic(), what I had done while capping FPS was add 0.05f to the
ball’s speed (acceleration) and multiply by 0.99f (deceleration).

But how would I modify those values to work with my delta?

Thanks!

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

necron · October 13, 2007, 1:02am

Wow that paper is something. My opinion is that he easy answer is as follows>
td2=SDL_GetTicks(); dt=((float)(td2-td))0.1; td=td2;
//the function SDL_GetTicks() is not used in any other part of the game.
//the product variable sdlgt tells how many milliseconds the game has been played
// (w/o being paused)
if(!paused){sdlgt+=dt10;}
// Move object up at rate that compensates
if(keys[SDLK_UP]){ship.yadd((int)(-2*dt));}
//does this make sense or have I complicated it?

---- David Olofson wrote:> On Saturday 13 October 2007, Torsten Giebl wrote:

[…]

Is this the paper you mean ?

gaffer.org is for sale

Yup, that’s the one. Thanks!

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
‘-- http://www.reologica.se - Rheology instrumentation --’

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

David_Olofson · October 13, 2007, 1:55am

[…the usual delta time solution…]

I think you’re completely missing the point, actually.

In the simple case of your example, there is indeed no difference.
However, any real game will have collision detection, time
driven “AI” and other stuff that is not directly related to user
input or video frame rate.

For example, collision detection: As soon as an object is moving more
than one pixel per frame, collisions will frequently happen between
frames. That is, first there is no collision, and next, the collision
already happened some “random” (frame rate dependent) time ago - and
you might even fail to detect it at all, if you’re relying on
na?ve “Do we have an intersection right now?” tests.

Another example; time driven “AI”: We have this enemy firing ten
bullets a second at the player. Ideally, this would produce a nice
spiral of evenly spaced bullets as the player circles around the
enemy - but unless the rendering frame rate happens to be exactly N *
10 fps, the spiral will have a sawtooth like distortion to it, caused
by interference between the nominal firing rate and the rendering
frame rate. And if the rendering frame rate should ever drop below
the firing rate, the firing rate will drop with it!

Considering all math and logic needed to deal with these problems
properly (and this without really getting it right anyway!), I
strongly suggest that it’s easier and safer to just run the game
logic at a fixed frame rate. This way, you can safely use simple
iterative methods (ie vx+=ax; vy+=ay; x+=vx; y+=vy; if(collision)
die(); if(!count–) ax=-ax; etc) like it was often done back in the
days of constant frame rates throughout the games. You don’t have to
test the game logic at various rendering frame rates, as the logic
behaves exactly the same way everywhere, every time, whether the
frame rate is 10 or 1000 fps.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'On Saturday 13 October 2007, necronology at cox.net wrote:

Wow that paper is something. My opinion is that he easy answer is as
follows>

atrix2 · October 13, 2007, 7:08am

To add to the good fight I’m tossing in my 2 cents here…

I did a game based on delta time and had nothing but problems at both low
and high fps… at low fps you could go through walls and at high fps, due
to precision issues you couldn’t even walk across the ground.

It sucked

I’m now working on a game that has a game loop that doesn’t rely on delta
time at all, but just does “1 iteration” of game logic, and that main loop
is called once every 30 miliseconds and if more time has elapsed between
frames, we could run the main loop more than once to do “frame skipping” and
try to catch up (but we don’t do this, we just let the game run slower)

It works wonderfully

" You don’t have to test the game logic at various rendering frame rates, as
the logic behaves exactly the same way everywhere, every time, whether the

frame rate is 10 or 1000 fps."

Wise words there, heed them or make the same mistakes we have!!! (said in a
ghostly haunting voice)> ----- Original Message -----

From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of David Olofson
Sent: Friday, October 12, 2007 6:56 PM
To: necronology at cox.net
Cc: A list for developers using the SDL library. (includes SDL-announce)
Subject: Re: [SDL] Delta time?

On Saturday 13 October 2007, necronology at cox.net wrote:

Wow that paper is something. My opinion is that he easy answer is as
follows>
[…the usual delta time solution…]

I think you’re completely missing the point, actually.

In the simple case of your example, there is indeed no difference.
However, any real game will have collision detection, time
driven “AI” and other stuff that is not directly related to user
input or video frame rate.

For example, collision detection: As soon as an object is moving more
than one pixel per frame, collisions will frequently happen between
frames. That is, first there is no collision, and next, the collision
already happened some “random” (frame rate dependent) time ago - and
you might even fail to detect it at all, if you’re relying on
na?ve “Do we have an intersection right now?” tests.

Another example; time driven “AI”: We have this enemy firing ten
bullets a second at the player. Ideally, this would produce a nice
spiral of evenly spaced bullets as the player circles around the
enemy - but unless the rendering frame rate happens to be exactly N *
10 fps, the spiral will have a sawtooth like distortion to it, caused
by interference between the nominal firing rate and the rendering
frame rate. And if the rendering frame rate should ever drop below
the firing rate, the firing rate will drop with it!

Considering all math and logic needed to deal with these problems
properly (and this without really getting it right anyway!), I
strongly suggest that it’s easier and safer to just run the game
logic at a fixed frame rate. This way, you can safely use simple
iterative methods (ie vx+=ax; vy+=ay; x+=vx; y+=vy; if(collision)
die(); if(!count–) ax=-ax; etc) like it was often done back in the
days of constant frame rates throughout the games. You don’t have to
test the game logic at various rendering frame rates, as the logic
behaves exactly the same way everywhere, every time, whether the
frame rate is 10 or 1000 fps.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
‘-- http://www.reologica.se - Rheology instrumentation --’

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Paul_Lowe · October 13, 2007, 4:37pm

Hey everyone, I’d strongly encourage y’all to listen to what David has
to say here since based on my knowledge and experience working with him
– he is the fixed logic / framerate “pimp”.

Cheers,

~Paul Lowe

David Olofson wrote:> On Saturday 13 October 2007, necronology at cox.net wrote:

Wow that paper is something. My opinion is that he easy answer is as
follows>

[…the usual delta time solution…]

I think you’re completely missing the point, actually.

In the simple case of your example, there is indeed no difference.
However, any real game will have collision detection, time
driven “AI” and other stuff that is not directly related to user
input or video frame rate.

For example, collision detection: As soon as an object is moving more
than one pixel per frame, collisions will frequently happen between
frames. That is, first there is no collision, and next, the collision
already happened some “random” (frame rate dependent) time ago - and
you might even fail to detect it at all, if you’re relying on
na?ve “Do we have an intersection right now?” tests.

Another example; time driven “AI”: We have this enemy firing ten
bullets a second at the player. Ideally, this would produce a nice
spiral of evenly spaced bullets as the player circles around the
enemy - but unless the rendering frame rate happens to be exactly N *
10 fps, the spiral will have a sawtooth like distortion to it, caused
by interference between the nominal firing rate and the rendering
frame rate. And if the rendering frame rate should ever drop below
the firing rate, the firing rate will drop with it!

Considering all math and logic needed to deal with these problems
properly (and this without really getting it right anyway!), I
strongly suggest that it’s easier and safer to just run the game
logic at a fixed frame rate. This way, you can safely use simple
iterative methods (ie vx+=ax; vy+=ay; x+=vx; y+=vy; if(collision)
die(); if(!count–) ax=-ax; etc) like it was often done back in the
days of constant frame rates throughout the games. You don’t have to
test the game logic at various rendering frame rates, as the logic
behaves exactly the same way everywhere, every time, whether the
frame rate is 10 or 1000 fps.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
‘-- http://www.reologica.se - Rheology instrumentation --’

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

necron · October 13, 2007, 4:44pm

LoL, I was just answering a question. In reality game logic seems to work best when frame rate independant. Things like advanced motion planning and interpolated ray casting are the the children of the answer I gave. Making a game is a vast enterprise. I don’t think you can put any concept in a box and say it’s wrong. I say make it simple and get it done. After that you can get into advanced stuff and have a good chance of success

---- Alan Wolfe wrote:> To add to the good fight I’m tossing in my 2 cents here…

I did a game based on delta time and had nothing but problems at both low
and high fps… at low fps you could go through walls and at high fps, due
to precision issues you couldn’t even walk across the ground.

It sucked

I’m now working on a game that has a game loop that doesn’t rely on delta
time at all, but just does “1 iteration” of game logic, and that main loop
is called once every 30 miliseconds and if more time has elapsed between
frames, we could run the main loop more than once to do “frame skipping” and
try to catch up (but we don’t do this, we just let the game run slower)

It works wonderfully

" You don’t have to test the game logic at various rendering frame rates, as
the logic behaves exactly the same way everywhere, every time, whether the

frame rate is 10 or 1000 fps."

Wise words there, heed them or make the same mistakes we have!!! (said in a
ghostly haunting voice)

-----Original Message-----
From: sdl-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of David Olofson
Sent: Friday, October 12, 2007 6:56 PM
To: @necron
Cc: A list for developers using the SDL library. (includes SDL-announce)
Subject: Re: [SDL] Delta time?

On Saturday 13 October 2007, @necron wrote:

Wow that paper is something. My opinion is that he easy answer is as
follows>
[…the usual delta time solution…]

I think you’re completely missing the point, actually.

In the simple case of your example, there is indeed no difference.
However, any real game will have collision detection, time
driven “AI” and other stuff that is not directly related to user
input or video frame rate.

For example, collision detection: As soon as an object is moving more
than one pixel per frame, collisions will frequently happen between
frames. That is, first there is no collision, and next, the collision
already happened some “random” (frame rate dependent) time ago - and
you might even fail to detect it at all, if you’re relying on
na?ve “Do we have an intersection right now?” tests.

Another example; time driven “AI”: We have this enemy firing ten
bullets a second at the player. Ideally, this would produce a nice
spiral of evenly spaced bullets as the player circles around the
enemy - but unless the rendering frame rate happens to be exactly N *
10 fps, the spiral will have a sawtooth like distortion to it, caused
by interference between the nominal firing rate and the rendering
frame rate. And if the rendering frame rate should ever drop below
the firing rate, the firing rate will drop with it!

Considering all math and logic needed to deal with these problems
properly (and this without really getting it right anyway!), I
strongly suggest that it’s easier and safer to just run the game
logic at a fixed frame rate. This way, you can safely use simple
iterative methods (ie vx+=ax; vy+=ay; x+=vx; y+=vy; if(collision)
die(); if(!count–) ax=-ax; etc) like it was often done back in the
days of constant frame rates throughout the games. You don’t have to
test the game logic at various rendering frame rates, as the logic
behaves exactly the same way everywhere, every time, whether the
frame rate is 10 or 1000 fps.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
‘-- http://www.reologica.se - Rheology instrumentation --’

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Mike_Powell · October 13, 2007, 11:21pm

I think David is completely correct. However, I want to emphasis one point:

“it’s easier and safer to just run the game logic at a fixed frame rate.”

Notice the “game logic” point. You don’t have to RENDER at a fixed frame rate, so long as the game logic is at a fixed rate.

The way I typically do it is with something like:

for (int i = 0; i < deltaTime; i++) {
updateGameLogic();
}

Thus, the game logic gets called once per millisecond (assuming deltaTime is in milliseconds), regardless of what frame rate you’re rendering at. Of course, you can adjust this easily to run once every 3 milliseconds, or 10 milliseconds, or whatever value you like, to speed things up, though as the increments get larger the results will get less precise.

David Olofson wrote:> On Saturday 13 October 2007, necronology at cox.net wrote:> Wow that paper is something. My opinion is that he easy answer is as> follows>[…the usual delta time solution…]

I think you’re completely missing the point, actually.

In the simple case of your example, there is indeed no difference. However, any real game
will have collision detection, time driven “AI” and other stuff that is not directly
related to user input or video frame rate.

For example, collision detection: As soon as an object is moving more than one pixel per
frame, collisions will frequently happen between frames. That is, first there is no
collision, and next, the collision already happened some “random” (frame rate dependent)
time ago - and you might even fail to detect it at all, if you’re relying on na?ve “Do we
have an intersection right now?” tests.

Another example; time driven “AI”: We have this enemy firing ten bullets a second at the
player. Ideally, this would produce a nice spiral of evenly spaced bullets as the player
circles around the enemy - but unless the rendering frame rate happens to be exactly N * 10
fps, the spiral will have a sawtooth like distortion to it, caused by interference between
the nominal firing rate and the rendering frame rate. And if the rendering frame rate should
ever drop below the firing rate, the firing rate will drop with it!

Considering all math and logic needed to deal with these problems properly (and this without
really getting it right anyway!), I strongly suggest that it’s easier and safer to just
run the game logic at a fixed frame rate. This way, you can safely use simple iterative
methods (ie vx+=ax; vy+=ay; x+=vx; y+=vy; if(collision) die(); if(!count–) ax=-ax; etc)
like it was often done back in the days of constant frame rates throughout the games. You
don’t have to test the game logic at various rendering frame rates, as the logic behaves
exactly the same way everywhere, every time, whether the frame rate is 10 or 1000 fps.

Mike_Powell · October 13, 2007, 11:28pm

Okay, is there a reason that the mailing list keeps stripping out half the newlines and making messages nearly unreadable?

Mike Powell wrote:

I think David is completely correct. However, I want to emphasis one point:
“it’s easier and safer to just run the game logic at a fixed frame rate.”
Notice the “game logic” point. You don’t have to RENDER at a fixed frame rate, so long as the game logic is at a fixed rate.
The way I typically do it is with something like:
for (int i = 0; i < deltaTime; i++) { updateGameLogic();}
Thus, the game logic gets called once per millisecond (assuming deltaTime is in milliseconds), regardless of what frame rate you’re rendering at. Of course, you can adjust this easily to run once every 3 milliseconds, or 10 milliseconds, or whatever value you like, to speed things up, though as the increments get larger the results will get less precise.
David Olofson wrote:> On Saturday 13 October 2007, necronology at cox.net wrote:> Wow that paper is something. My opinion is that he easy answer is as> follows>[…the usual delta time solution…]> I think you’re completely missing the point, actually.>> In the simple case of your example, there is indeed no difference. However, any real game> will have collision detection, time driven “AI” and other stuff that is not directly> related to user input or video frame rate.>> For example, collision detection: As soon as an object is moving more than one pixel per> frame, collisions will frequently happen between frames. That is, first there is no> collision, and next, the collision already happened some “random” (frame rate dependent)> time ago - and you might even fail to detect it at all, if you’re relying on na?ve “Do we> have an intersection right now?” tests.>> Another example; time driven “AI”: We have this enemy firing ten bullets a second at the> player. Ideally, this
would produce a nice spiral of evenly spaced bullets as the player> circles around the enemy - but unless the rendering frame rate happens to be exactly N * 10> fps, the spiral will have a sawtooth like distortion to it, caused by interference between> the nominal firing rate and the rendering frame rate. And if the rendering frame rate should> ever drop below the firing rate, the firing rate will drop with it!>> Considering all math and logic needed to deal with these problems properly (and this without> really getting it right anyway!), I strongly suggest that it’s easier and safer to just> run the game logic at a fixed frame rate. This way, you can safely use simple iterative> methods (ie vx+=ax; vy+=ay; x+=vx; y+=vy; if(collision) die(); if(!count–) ax=-ax; etc)> like it was often done back in the days of constant frame rates throughout the games. You> don’t have to test the game logic at various rendering frame rates, as the logic behaves> exactly the same way ever
ywhere, every time, whether the frame rate is 10 or 1000 fps._______________________________________________SDL mailing listSDL at lists.libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>

David_Olofson · October 14, 2007, 12:27am

I think David is completely correct. However, I want to emphasis one
point:

“it’s easier and safer to just run the game logic at a fixed frame
rate.”

Notice the “game logic” point. You don’t have to RENDER at a fixed
frame rate, so long as the game logic is at a fixed rate.

Good point! This may not be all that obvious - and there are indeed
some games that are simply locked at a fixed logic and rendering
frame rate.

The way I typically do it is with something like:

for (int i = 0; i < deltaTime; i++) {
updateGameLogic();
}

Thus, the game logic gets called once per millisecond (assuming
deltaTime is in milliseconds), regardless of what frame rate you’re
rendering at. Of course, you can adjust this easily to run once
every 3 milliseconds, or 10 milliseconds, or whatever value you
like, to speed things up, though as the increments get larger the
results will get less precise.

This loss of precision (and the resulting unsmooth movement) can be
fixed by means of interpolation.

What I do in Kobo Deluxe and Fixed Rate Pig is basically what you do
above, but I also keep the resulting object (and map, in the case of
Kobo) coordinates from previous logic frame.

When rendering, I interpolate as needed to “morph” the scene into a
state corresponding to the logic time of the frame to render. (Well,
minus one logic frame, actually, as future game logic states are not
available, obviously. Use a higher logic frame rate to reduce
latency, or perhaps try extrapolation/prediction.)

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'On Sunday 14 October 2007, Mike Powell wrote:

Ulrich_Eckhardt · October 14, 2007, 10:34am

It doesn’t, your mails arrive fine here. The only issue I might have is that
you don’t break your lines at e.g. 75 characters, but to be honest I consider
that habit a bit outdated anyway.

That said, your reply to David Olofson had the quoting of what necronology
wrote messed up, it was all on one line including the quote markers (‘>’) and
was TOFU, which I hereby frown upon because it is inefficient.

So, I guess it’s your client…

UliOn Sunday 14 October 2007 01:28:04 Mike Powell wrote:

Okay, is there a reason that the mailing list keeps stripping out half the
newlines and making messages nearly unreadable?

Mike_Powell · October 14, 2007, 7:09pm

Ulrich Eckhardt wrote:> On Sunday 14 October 2007 01:28:04 Mike Powell wrote:

Okay, is there a reason that the mailing list keeps stripping out half the
newlines and making messages nearly unreadable?

It doesn’t, your mails arrive fine here. The only issue I might have is that
you don’t break your lines at e.g. 75 characters, but to be honest I consider
that habit a bit outdated anyway.

That said, your reply to David Olofson had the quoting of what necronology
wrote messed up, it was all on one line including the quote markers (‘>’) and
was TOFU, which I hereby frown upon because it is inefficient.

So, I guess it’s your client…

What you’re describing is precisely what I was talking about. Every instance where I used a newline, one fewer newline came in the result. If I used one newline, the message I got back had none. If I used two newlines, the message I got back had one. Thus, all the places where you see newline are places where I had double newlines, and my quoted paragraphs got munged because they were full of single newlines.

I just went back to find the other recent examples of this in other people’s messages, and noticed that every one of them is a reply to necrology’s original Delta Time message. David Olofson’s first reply looks a little messed up, then Paul Lowe’s, necrology’s and my replies to David all came out munged. I have no idea what could possibly have been in necrology’s message to cause replies to it to have this problem. I’m assuming this message will come out fine.

My client is Thunderbird, which I believe is pretty heavily used. It may be partially Thunderbird’s fault, but it was interacting with something funky in that message or on this list, because this doesn’t typically happen.

Jon_Dowland · October 15, 2007, 9:25am

Necrology’s message was base64-encoded, and most of the replies were
too. The ones that are not broken have been posted text/plain. I guess
the original was base64-encoded to handle some non-ascii char in the
message. “quoted-printable” is preferable to base64 for this purpose
imho.On Sun, Oct 14, 2007 at 12:09:38PM -0700, Mike Powell wrote:

My client is Thunderbird, which I believe is pretty heavily used. It
may be partially Thunderbird’s fault, but it was interacting with
something funky in that message or on this list, because this doesn’t
typically happen.

–
Jon Dowland