Time based movement

SDL Development
1

Hello.
I’m wondering what the best way to do a time based movement is.

I have read two diffrent approches.
The first:
Update a variable that is used like this (well, something like this):
myObject.x += steps * timeScale; // I’m sure you know what I mean

The second:
Use a sleep method in the main loop.
(This method calculates how long the application should sleep ofcourse)

I do use the first method, but the second one seams much simplier IMO.

Is there any negative effects in the second one (or the first one)?

// Alexander Bussman

2

Hi there,

I changed my BomberClone game from the first to the second one, because
if you can finish your game loop in time and you write on a network game
your game gets out of snyc. that means one player is faster as the other
one. (oky only if you use a kind of network protocol where every host
calculates his own stuff.) And i can say i am happy with the change you
can get your game running on even slower systems. But i still have a
kind of sleep still included so if i have too much time left i just let
the game sleep for a while so the game don’t take too much cpu usage.

I hope i could help you a little bit.
bye bye,
Steffen–

Steffen Pohle (@Steffen_Pohle)| _ x
http://stpohle.bei.t-online.de | /#/ BomberClone - The Clone of
JabberID: stpohle at amessage.de ||###| DynaBlaster and Bomberman
ICQ: 370965 Yahoo: stpohle | #/ http://www.bomberclone.de
MSN: stpohle at hotmail.com |

3

Alexander Bussman wrote:

Hello.

Hi.

I have read two diffrent approches.
The first:
Update a variable that is used like this (well, something like this):
myObject.x += steps * timeScale; // I’m sure you know what I mean

The second:
Use a sleep method in the main loop.
(This method calculates how long the application should sleep ofcourse)

I do use the first method, but the second one seams much simplier IMO.

I’d always multiply by timeScale on everything you do. That is the most
accurate method. Actually, all my gameplay related functions always take
an argument called “frametime” which is the number of milliseconds that
passed in the last frame.

Is there any negative effects in the second one (or the first one)?

The second one makes you lose accuracy, because SDL_Delay() is not
entirely accurate. You can do it in addition to the first method if you
don’t want to use all the CPU time (which only makes sense for some
games; most of times, you shouldn’t care about that).

What exactly do you think is complicated about method one? I find it
much easier to define my variables on a per-millisecond base rather than
a per-frame base.

Sebastian

4

The first option works flawlessly, if the scale is large enough. In my
programs I use something like this:

int g_lastticks;
int g_lastframetime;

The first one is the amount of milliseconds the program is running, used
for timing events. The second one is the amount of milliseconds the last
frame (of the game) took to finish (AI/sound/video). I then use the
g_lastframetime variable to for example move objects around in my world,
depending on the framerate. This works just fine in most cases. Though
when the framerate is very high, the g_lastframetime becomes very low
and thus less precise.
That’s why I started this mail with “if the scale is large enough”. For
high framerates, timing should be done in microseconds or even in
nanoseconds.

My guess is that your second option is harder to implement. How could
you know how long to sleep? And why would you do it in that way, if the
first option works just fine? :slight_smile:

Just my two cents…

Marc

Alexander Bussman wrote:> Hello.

I’m wondering what the best way to do a time based movement is.

I have read two diffrent approches.
The first:
Update a variable that is used like this (well, something like this):
myObject.x += steps * timeScale; // I’m sure you know what I mean

The second:
Use a sleep method in the main loop.
(This method calculates how long the application should sleep ofcourse)

I do use the first method, but the second one seams much simplier IMO.

Is there any negative effects in the second one (or the first one)?

// Alexander Bussman

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

5

Hello.
I’m wondering what the best way to do a time based movement is.

I have read two diffrent approches.
The first:
Update a variable that is used like this (well, something like this):
myObject.x += steps * timeScale; // I’m sure you know what I mean

The second:
Use a sleep method in the main loop.
(This method calculates how long the application should sleep ofcourse)

I do use the first method, but the second one seams much simplier IMO.

Is there any negative effects in the second one (or the first one)?

The second is simpler. The first one works. You just can’t count on your
program running at the same frame rate on multiple computers. You can’t
count on it running at the same frame rate on even one computer.

I like a combination of the two. I use a pause to keep the program from
grabbing every available CPU cycle, but I use the actual time between
frames to update position.

		Bob PendletonOn Mon, 2004-01-19 at 12:33, Alexander Bussman wrote:

// Alexander Bussman

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±--------------------------------------+

6

You meant that doing sleep at the end of loop is better? Was it you said ?> ----- Original Message -----

From: sdl-admin@libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of
Steffen Pohle
Sent: segunda-feira, 19 de janeiro de 2004 16:48
To: sdl at libsdl.org
Subject: Re: [SDL] Time based movement

Hi there,

I changed my BomberClone game from the first to the second one, because
if you can finish your game loop in time and you write on a network game
your game gets out of snyc. that means one player is faster as the other
one. (oky only if you use a kind of network protocol where every host
calculates his own stuff.) And i can say i am happy with the change you
can get your game running on even slower systems. But i still have a
kind of sleep still included so if i have too much time left i just let
the game sleep for a while so the game don’t take too much cpu usage.

I hope i could help you a little bit.
bye bye,
Steffen

–

Steffen Pohle (stpohle at gmx.net)| _ x
http://stpohle.bei.t-online.de | /#/ BomberClone - The Clone of
JabberID: stpohle at amessage.de ||###| DynaBlaster and Bomberman
ICQ: 370965 Yahoo: stpohle | #/ http://www.bomberclone.de
MSN: stpohle at hotmail.com |

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

7

Bob Pendleton wrote:

The second is simpler. The first one works. You just can’t count on your
program running at the same frame rate on multiple computers. You can’t
count on it running at the same frame rate on even one computer.

I like a combination of the two. I use a pause to keep the program from
grabbing every available CPU cycle, but I use the actual time between
frames to update position.

  	Bob Pendleton

@Everyone: Thanks for all your answers, now I understand this better.

@Bob Pendleton, I liked the idea to use both.
How long pause do you usually use?
I tested with 10ms and it seams to work good.

8

Hello.
I’m wondering what the best way to do a time based movement is.

Well, I’d say “not at all”, but that’s not quite accurate. What I mean
is that I prefer to run the game logic at a fixed, hardwired
"virtual" frame rate, to make sure long frames don’t cause collision
detection to fail and stuff like that.

Indeed, this method causes interference between the logic frame rate
and the rendering frame rate (you need to resample all “cordinate
streams” from the logic frame rate to the rendering frame rate), but
some simple interpolation deals with that very nicely.

Of course, the most accurate method is to always use the delta time in
logic calculations, but that means you have to explicitly deal with
long frames and stuff, so you don’t have players running through
walls and stuff when the rendering frame rate drops too low.

Also note that if you store recorded demos as just player control
data, relying on the game logic to replay demos accurately, the
"accurate" method becomes virtually impossible to implement reliably.
Rounding errors and deviations caused by approximations (such as not
reporting the exact time of every collision event) easilly build up
cause demos to play differently on different machines, or even from
time to time.

With a fixed logic frame rate, this is not a problem, as the game
logic will be doing the exact same calculations every time you play
the demo.

The second:
Use a sleep method in the main loop.
(This method calculates how long the application should sleep
ofcourse)

(Then mine would be the third method, or something.)

Anyway, I don’t like this approach at all, since it’s heavily
dependent on the OS scheduler, and generally doesn’t provide much
accuracy.

Besides, it requires that you have thread safe communication between
the logic thread and the rendering thread. …unless you actually
throttle the frame rate of the whole game. Do not do that!

A fixed logic frame rate with coordinate interpolation lets you do
everything in one thread, and ensures that there is always one
properly calculated set of data for each rendered frame. Works
anywhere, and it’s simple and totally accurate within the limits of
the chosen logic frame rate. (Could be 10 Hz or 1 kHz; lower rates
just mean higher control latency and lower “maximum event rate”.)

I’m using this method in Kobo Deluxe, BTW. Seemed natural, given that
the original game was hardwired to 30 ms/frame, and I wanted to make
use of the maximum possible rendering frame rate, without entirely
rewriting the game logic.

It’s not exactly a simple example to look at, though. Maybe I should
hack a small SDL example?

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 19 January 2004 19.33, Alexander Bussman wrote:

9

[…]

I like a combination of the two. I use a pause to keep the program
from grabbing every available CPU cycle, but I use the actual time
between frames to update position.

IMHO, the only proper way is to block on the pageflipping, to keep the
game in sync with the refresh rate. Best results, and with a proper
driver, it keep the scheduler from seeing your game as a total CPU
hog.

But then we have (the majority of) Linux video drivers… :-/

Anyway, I threw in a “limit frame rate” option in Kobo Deluxe, after
someone complained about it keeping his laptop running at full speed
constantly while running the game. The default is still to assume
that SDL_Flip() does the right thing.

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 19 January 2004 20.08, Bob Pendleton wrote:

10

Alexander Bussman wrote:

@Bob Pendleton, I liked the idea to use both.
How long pause do you usually use?
I tested with 10ms and it seams to work good.

On an Athlon64 or an 386-SX 16? You have to measure that amount
by e.g., using SDL_GetTicks().–
Christian
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040119/97e18374/attachment.pgp

11

Christian Biere wrote:

On an Athlon64 or an 386-SX 16? You have to measure that amount
by e.g., using SDL_GetTicks().

Oh, yeah… now I see. Thanks for correcting me.

12

David Olofson wrote:

I’m using this method in Kobo Deluxe, BTW. Seemed natural, given that
the original game was hardwired to 30 ms/frame, and I wanted to make
use of the maximum possible rendering frame rate, without entirely
rewriting the game logic.

It’s not exactly a simple example to look at, though. Maybe I should
hack a small SDL example?

A small SDL example would be nice to look at.
If you feel like creating one I would be glad to look at it.>//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

13

David Olofson wrote:

I’m using this method in Kobo Deluxe, BTW. Seemed natural, given that
the original game was hardwired to 30 ms/frame, and I wanted to make
use of the maximum possible rendering frame rate,

Why? What’s the benefit of having more than 30 fps? If someone thinks
more than 30 are better doesn’t he just confuse controller latency
with frame latency? If you check the controller input only once per
frame, he will, of course, notice a difference when he hammers the
fire button like mad. But throwing more than 30 frames to the
screen itself doesn’t seem to be sensible IMHO.–
Christian
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040119/9f6bbbcd/attachment.pgp

14

How to maintain SDL in sync iff using OpenGL too ?

I tried swapping buffer with SDL_FLip() and in window mode, app turns to be
sloooower.

If I use SDL_GL_SwapBuffers it keeps my app in sync? Do I have to still use
one of this methods ?

[]s
Bruce> ----- Original Message -----

From: sdl-admin@libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of
Christian Biere
Sent: segunda-feira, 19 de janeiro de 2004 17:53
To: sdl at libsdl.org
Subject: Re: [SDL] Time based movement

Alexander Bussman wrote:

@Bob Pendleton, I liked the idea to use both.
How long pause do you usually use?
I tested with 10ms and it seams to work good.

On an Athlon64 or an 386-SX 16? You have to measure that amount
by e.g., using SDL_GetTicks().

–
Christian

15

Bob Pendleton wrote:

The second is simpler. The first one works. You just can’t count on your
program running at the same frame rate on multiple computers. You can’t
count on it running at the same frame rate on even one computer.

I like a combination of the two. I use a pause to keep the program from
grabbing every available CPU cycle, but I use the actual time between
frames to update position.

  Bob Pendleton

@Everyone: Thanks for all your answers, now I understand this better.

@Bob Pendleton, I liked the idea to use both.
How long pause do you usually use?
I tested with 10ms and it seams to work good.

keep track of the total time between frames and if it is less that 10
milliseconds I call SDL_Delay(5) which averages to a 5 millisecond
delay. Tends to keep the frame rate near 100 frames/second for fast
machines and lets the program run as fast as it can on slower machines.

		Bob PendletonOn Mon, 2004-01-19 at 13:39, Alexander Bussman wrote:

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±--------------------------------------+

16

People can actually see and feel the difference between 30 fps and 60
fps. It has to do with the total feedback time. Thirty fps is fine for
video where you don’t interact with it, but for interactive work you can
see a long lag time between when you hit a button and something happens
on the screen. If you hit a button at the start of a frame there is a 33
millisecond lag before the program reacts to it and as much as another
30 milliseconds before the screen changes in response to it. That is
long enough to make the program feel “sloppy” to a user. At 60 fps that
lag is only half as long.

For highly interactive programs you the lag time from when you push a
button to when you see a response to be as short as possible. Sixty fps
is pretty good, 100 fps is better. I haven’t seen any evidence that
anything faster than 100 fps is worthwhile. But, for highly interactive
programs you definitely want to be faster than 30 fps.

	Bob PendletonOn Mon, 2004-01-19 at 14:10, Christian Biere wrote:

David Olofson wrote:

I’m using this method in Kobo Deluxe, BTW. Seemed natural, given that
the original game was hardwired to 30 ms/frame, and I wanted to make
use of the maximum possible rendering frame rate,

Why? What’s the benefit of having more than 30 fps? If someone thinks
more than 30 are better doesn’t he just confuse controller latency
with frame latency? If you check the controller input only once per
frame, he will, of course, notice a difference when he hammers the
fire button like mad. But throwing more than 30 frames to the
screen itself doesn’t seem to be sensible IMHO.

–
±--------------------------------------+

17

How to maintain SDL in sync iff using OpenGL too ?

I tried swapping buffer with SDL_FLip() and in window mode, app turns to be
sloooower.

If I use SDL_GL_SwapBuffers it keeps my app in sync? Do I have to still use
one of this methods ?

Maybe yes, maybe no. depends on the driver. Take a look at my series on
animation with SDL at: http://www.oreillynet.com/pub/au/1205 they cover
this topic in depth.

	Bob PendletonOn Mon, 2004-01-19 at 14:27, Bruce @ OpenGL wrote:

[]s
Bruce

-----Original Message-----
From: sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of
Christian Biere
Sent: segunda-feira, 19 de janeiro de 2004 17:53
To: sdl at libsdl.org
Subject: Re: [SDL] Time based movement

Alexander Bussman wrote:

@Bob Pendleton, I liked the idea to use both.
How long pause do you usually use?
I tested with 10ms and it seams to work good.

On an Athlon64 or an 386-SX 16? You have to measure that amount
by e.g., using SDL_GetTicks().

–
Christian

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±--------------------------------------+

18

David Olofson wrote:

I’m using this method in Kobo Deluxe, BTW. Seemed natural, given
that the original game was hardwired to 30 ms/frame, and I wanted
to make use of the maximum possible rendering frame rate,

Why? What’s the benefit of having more than 30 fps?

You avoid getting a headache after playing for a while. Personally, I
have trouble percepting objects that are “flashed” at the same
position more than once as really moving, but most people are
probably less sensitive.

If someone
thinks more than 30 are better doesn’t he just confuse controller
latency with frame latency?

That’s a different matter, but actually, the frame rate does affect
controller latency, sort of. You can hardly see the effect of input
before the next frame has been rendered, can you?

If you check the controller input only
once per frame, he will, of course, notice a difference when he
hammers the fire button like mad.

Yep, but that’s yet another issue.

But throwing more than 30 frames
to the screen itself doesn’t seem to be sensible IMHO.

My eyes tell me it’s very sensible to stick with the monitor refresh
rate whenever possible. Usually means means 70…100 Hz range these
days (50 or 60 on consoles), but don’t worry about that; just sync
the rendering with the retrace sync if you can. If you can’t sync,
just render as fast as you can. Any other tricks will result in less
smooth animation.

Anyway, the real point is not about the frame rate. It’s that there’s
a big difference between rendering one frame per CRT refresh, and
anything below that. If you “flash” an object more than once, you get
ghosting effects when the object moves, and some people (like me)
will have much less of an “object in motion” experience.

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 19 January 2004 21.10, Christian Biere wrote:

19

How to maintain SDL in sync iff using OpenGL too ?

(Hmm… You can only use SDL or OpenGL for rendering to the screen,
so I assume you mean using SDL with OpenGL for rendering.)

Anyway, it doesn’t make much of a difference. You still have some game
logic that needs to keep track of time somehow, without depending on,
and preferably without restricting, the rendering frame rate.

I tried swapping buffer with SDL_FLip() and in window mode, app
turns to be sloooower.

Probably because SDL_Flip() has to blit your back buffer into the
window, as windowing systems in general do not support pageflipping.
(Without special h/w support, it would have to be desktop wide, which
means every application must be in on it, or the system must do some
seriously hairy stuff for apps that assume windows are single
buffered.)

If I use SDL_GL_SwapBuffers it keeps my app in sync?

Doesn’t matter whether you use SDL_Flip() or SDL_GL_SwapBuffers().
They do essentially the same thing, except that the latter is for
OpenGL, whereas the former is for all 2D backends. Whether the call
syncs with the retrace depends on the OS, driver and system
configuration.

Make sure you get a double buffered display surface for the 2D
backends, though, or there’s no chance of getting retrace sync on any
target, AFAIK.

Do I have to
still use one of this methods ?

One of the timing methods? Well, yes, you have to do something to
bind logic time to real time. Even if you have a (more or less) fixed
rendering frame rate thanks to retrace sync and very fast rendering,
that frame rate can be anything. You still need to use
SDL_GetTicks() or something to keep track of real time.

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 19 January 2004 21.27, bruce at opengl.com.br wrote:

20

You meant that doing sleep at the end of loop is better? Was it you
said ?

hmm no i said that i use the movement += (speed * timediff)… but at the
end of the loop i still wait some time so that i can come down with the
cpu usage… because in my game i don’t need 150fps… i just want to have
50 nice frames per second thats enough. So if i have at the end of the
loop some time left i sleep.

bye bye
SteffenOn Mon, 19 Jan 2004 17:18:26 -0200 “Bruce @ OpenGL” wrote:

–

Steffen Pohle (@Steffen_Pohle)| _ x
http://stpohle.bei.t-online.de | /#/ BomberClone - The Clone of
JabberID: stpohle at amessage.de ||###| DynaBlaster and Bomberman
ICQ: 370965 Yahoo: stpohle | #/ http://www.bomberclone.de
MSN: stpohle at hotmail.com |