Time based movement

atrix2 · January 19, 2004, 2:08pm

i do the same method, however my fps seems to be capped at 66 which sounds
alot like the refresh rate of my monitor or maybe from vsync.

anyone know why its capped at 66 and how to get around that at all?> ----- Original Message -----

From: stpohle@gmx.net (Steffen Pohle)
To:
Sent: Monday, January 19, 2004 1:54 PM
Subject: Re: [SDL] Time based movement

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

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
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

Mikkel_Gjol · January 19, 2004, 3:46pm

David Olofson wrote:

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

That would be nice. I’ve been kind of wondering (ie. too involved in
other stuff to take the time) how to do this exactly

Regards

Chris_Herborth · January 19, 2004, 6:34pm

Alexander Bussman wrote:

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

I think you need to provide more details before anyone can give you good
advice… it depends on what you’re trying to do.

A third approach, for a system where you need to be drawing all the time
(OpenGL for example) could do something like this…

Decide how often your world gets updated. This is entirely decoupled
from receiving input, or rendering, etc. I’ll call this the update delta.

t1 = current time
while playing:
render the world
check inputs

if current time - t1 >= update delta:
   update the world
   t1 = current time
end if

end while–
Chris Herborth
Otaku no sensei

David_Olofson · January 19, 2004, 7:16pm

i do the same method, however my fps seems to be capped at 66 which
sounds alot like the refresh rate of my monitor or maybe from
vsync.

Normally, “vsync” and the monitor refresh rate would be very, very
closely related.

anyone know why its capped at 66 and how to get around that at all?

Sounds like your video drivers are doing the right thing and blocking
in the “page flip” call. That is, when there are no more vide buffers
that aren’t visible or enqueued, the flip call blocks, waiting for
the RAMDAC DMA to get off the buffer that is currently being
displayed.

This is exactly what you want for smooth animation at the maximum
frame rate, without tearing or wasted CPU and/or GPU cycles.

I would very strongly recommend against trying to get around it, for
any other purposes than benchmarking.

Now, to see how fast your code actually is, just remove any retrace
sync calls, flags or whatever your API is using. In SDL, you can do
it by asking for a single buffered display surface - that is, no
SDL_DOUBLEBUF flag to SDL_SetVideoMode(). Obviously, you’ll also have
to remove any timer throttling code, unless of course, the purpose of
the excercise is to test that code.

//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 23.07, Alan Wolfe wrote:

David_Olofson · January 19, 2004, 7:26pm

Ok, then I’ll try to get it done one of these days. It’s mostly a
copy-paste job - but of course, there’s always the risk of
accidentally hacking away…

//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 Tuesday 20 January 2004 00.46, Mikkel Gj?l wrote:

David Olofson wrote:

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

That would be nice. I’ve been kind of wondering (ie. too involved
in other stuff to take the time) how to do this exactly

Florian_Hufsky · January 23, 2004, 8:09am

David Olofson wrote:

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

that would be great!
i’m still thinking about how to imlpement time based movement in jnrdev
(http://jnrdev.weed-crew.net).

i thougth about using the first method (pos += vel * faktor), but i
would have to rewrite the collision detection or split a too long frame
in “sub-frames” for collision detection, etc.

David_Olofson · January 23, 2004, 9:34am

David Olofson wrote:

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

that would be great!
i’m still thinking about how to imlpement time based movement in
jnrdev (http://jnrdev.weed-crew.net).

Ok, I need a break from GC, reference counting, code generation,
upvalues, stack based vs register based VMs, register allocation and
stuff…

i thougth about using the first method (pos += vel * faktor), but i
would have to rewrite the collision detection or split a too long
frame in “sub-frames” for collision detection, etc.

Yeah, that’s exactly the kind of stuff I want to avoid with this
method. Things were so much easier back in the days of hardwired
PAL/NTSC games! (Not really, but that’s another story.)

//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 Friday 23 January 2004 17.08, Florian Hufsky wrote:

Florian_Hufsky · January 23, 2004, 1:36pm

Yeah, that’s exactly the kind of stuff I want to avoid with this
method. Things were so much easier back in the days of hardwired
PAL/NTSC games! (Not really, but that’s another story.)

it always depends on what aspect you mean.

i think sprite / background limitations were a big pain.
but hardwired fps are sooo much easier to use…

David_Olofson · January 23, 2004, 3:02pm

That’s what I meant; the requirement for optimization of pretty much
everything (including simple shooter game logic on the old 8 bit
machines) pretty much made hardwiring the frame rate a requirement,
not just a shortcut to make life easier.

Imagine doing linear interpolation of the coordinates for all sprites
on a C64. (Note that the 6502 doesn’t even have a slow MUL
instruction; it doesn’t have one at all. A delta x fraction -> offset
table might work, though.)

Anyway, back to hacking. Or rather image processing; I photographed
some toys and stuff from various angles. Remains to see what this
thing turns into…

//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 Friday 23 January 2004 22.35, Florian Hufsky wrote:

Yeah, that’s exactly the kind of stuff I want to avoid with this
method. Things were so much easier back in the days of hardwired
PAL/NTSC games! (Not really, but that’s another story.)

it always depends on what aspect you mean.

i think sprite / background limitations were a big pain.
but hardwired fps are sooo much easier to use…

slouken · January 23, 2004, 10:05pm

Imagine doing linear interpolation of the coordinates for all sprites
on a C64.

Let’s imagine this off the list.
This thread is getting a bit off topic, can you take it to private e-mail?

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

David_Olofson · January 23, 2004, 11:01pm

It’s probably more on topic over at gameprogrammer. (Interpolation and
fixed logic frame rates at least - dunno if insane ideas about what
one could do with collector’s items from the 8 bit era would be on
topic there either.

Anyway, while I’m at it; there are a bunch of projects over at
olofson.net, and more to come, so I figured a list for announcements,
bug reports, support, discussions etc would be handy:

http://www.freelists.org/cgi-bin/list?list_id=3776

"Discussion and announcements regarding David Olofson's
 various software projects, such as glSDL, Audiality,
 EEL, Kobo Deluxe, Project Spitfire and the SDL
 programming examples on the olofson.net site. This is
 to be considered the official announcement and support
 mailing list for the olofson.net site."

I’m not expecting much traffic, so it’ll serve as an all-in-one list
for now.

//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 Saturday 24 January 2004 06.52, Sam Lantinga wrote:

Imagine doing linear interpolation of the coordinates for all
sprites on a C64.

Let’s imagine this off the list.
This thread is getting a bit off topic, can you take it to private
e-mail?

Florian_Hufsky · January 24, 2004, 2:39am

no mul?
omg - i’m happy i missed that time

David Olofson wrote:>On Friday 23 January 2004 22.35, Florian Hufsky wrote:

Yeah, that’s exactly the kind of stuff I want to avoid with this
method. Things were so much easier back in the days of hardwired
PAL/NTSC games! (Not really, but that’s another story.)

it always depends on what aspect you mean.

i think sprite / background limitations were a big pain.
but hardwired fps are sooo much easier to use…

That’s what I meant; the requirement for optimization of pretty much
everything (including simple shooter game logic on the old 8 bit
machines) pretty much made hardwiring the frame rate a requirement,
not just a shortcut to make life easier.

Imagine doing linear interpolation of the coordinates for all sprites
on a C64. (Note that the 6502 doesn’t even have a slow MUL
instruction; it doesn’t have one at all. A delta x fraction -> offset
table might work, though.)

Anyway, back to hacking. Or rather image processing; I photographed
some toys and stuff from various angles. Remains to see what this
thing turns into…

//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

Florian_Hufsky · January 24, 2004, 2:52am

sorry, i read your message after sending my last one.

Sam Lantinga wrote:>>Imagine doing linear interpolation of the coordinates for all sprites

on a C64.

Let’s imagine this off the list.
This thread is getting a bit off topic, can you take it to private e-mail?

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

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

Rainer_Deyke · May 11, 2004, 6:48pm

Alexander Bussman wrote:

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)

Both are broken, the first being worse than the second. If you use the
first method, your game will misbehave for extremely large, extremely
small, or highly fluctuating values of ‘timeScale’. If you use the second
method, the game will only fail on slow computers.

The only reliable method is to update the game logic at a constant
framerate, independent of the frame rate at which the graphics are
displayed.–
Rainer Deyke - rainerd at eldwood.com - http://eldwood.com