Re: [pygame] frame independant movement

[B W]

This is for folks who may have a continuing interest in the topic.

While trying to use GameClock I discovered a bug. While I was in there
a-squashing, I added a couple methods. Then I decided to take the prediction
demo to the next level and solve the screen-edge rebound problem, with
plenty of here's-why-and-how notes.

These are available at
game_clock.pyand
pygame.org/wiki/ConstantGameSpeed
.

Gumm

Re: [pygame] frame independant movement

[B W]

Alan,

With the GameClock recipe it'd just be a matter of decreasing
ticks_per_second (e.g. clock.ticks_per_second /= 5). Though if you're using
interpolation/prediction to smooth out your frames you may really notice
things like collision artifacts, as a wider separation of ticks versus
frames results in more predictive calculations between ticks.

This may be fine for continuous motion, but if the physics dictate a change
in speed or direction then the object visibly overshoots the point where it
should have changed. When the physics catch up during the next tick the
object jerks back onto the right path. Without a good predictive algorithm,
this is more noticeable when frame rate is much higher than gametick rate.

You can easily see this cosmetic problem in the GameClock demo by adding a
line "(TICKS_PER_SECOND/5, 0)," to SETTINGS.

I have noticed this in Internet games where the common design smooths out
network latency by using a prediction algorithm in the game client. There
may be ways to improve the cosmetics. But I have noticed that Internet games
usually seem to just not deal with the issue because it is adequate to rely
on the player's brain to compensate.

I first noticed this in Everquest: when other players' avatars inch forward
for a closer look at a mob of enemies they run out "too far" as displayed by
my client, and then suddenly they snap back to where the game server reports
they really are. At first I had many alarming moments, but eventually my
brain became adept at edited out the discrepencies and I did not notice them
unless I purposely looked for them.

On a nostalgic note... You EQ players, remember DC (disconnect) death? Lose
your server connection and wake up dead because the server assumed no
network packets meant keep going--which, if you were running, usually meant
you were on course for a cliff, ocean, lava, or gathering a train of hungry
critters. Rush out to buy a lottery ticket if you were saved by a wall or
snagged on a tree! Ah, the fun of that particular peril. :) A good
prediction here could have included keep-alive packets from the client,
and noticing their absence.

Gumm

On Fri, Aug 27, 2010 at 10:42 PM, R. Alan Monroe wrote:

>
> > In other words, use a small enough time step that the difference
> > is not big enough to be a problem. But if you're doing that, you
> > might as well pick one sufficiently small time step and use a
> > variable number of them per frame, so that the physics is
> > always predictable whatever the frame rate.
>
> While we're on the time topic, is there an easy way to do slo-mo, a la
> Peggle Extreme Fever or a Burnout multi-car pileup?
>
> Alan
>
>

Re: [pygame] frame independant movement

[Jake b]

On Wed, Feb 3, 2010 at 6:30 PM, R. Alan Monroe wrote:

> > The nice thing about limiting the framerate versus having calculations be
> > done based on time passed is that it is much more consistent. With dt
> > calculations you will often get huge jumps on slower computers and extra
> > slow movement in cases on fast machines, just do to inaccuracies and
> error
> > in the calculation.  On a slower machine, no matter which timing method
> you
> > use it will be unpleasant.
>
> What kind of innacuracies, specifically?



For gravity, it's a huge difference. Create 1 planet and 1 asteroid.
Draw lines tracing it's movement.

With a fixed (physics) timestep: body orbits planet correct.
With dynamic physics timestep, the body escapes the gravity well.

Details on here: http://gafferongames.com/game-physics/fix-your-timestep/

> One method for having a smooth variable framerate, without the issues of
> > variable time calculations, is to have a fixed time step. Each frame, you
> > may process more than one timestep, if you need to in order to keep up.
> The
> > timestep has a fixed amount of time it is supposed to similate, say, .02,
> > which would be 60 times per second. If the user is able to run at 60 fps,
> > they get very smooth animation, as only one step is occuring on each
> frame.
> > If the user can only run at 30 fps, they will get two steps each frame,
> so
> > it will be jerkier, but still accurate. If they can only run at 10 fps,
> you
> > would set a limit on it (maybe the max is two timesteps in a frame), so
> > things would be slower for them but maybe still playable.
>
>
> [code snipped]
>
> Is anyone aware of any websites that describe this time/frame business
> pictorially? I have read about it repeatedly and browsed a lot of
> pseudocod over the years, but without a proper diagram it's not really
> sinking in for a visual thinker like myself.
>
>
> Alan


Try the http://gafferongames.com/game-physics/fix-your-timestep/ link.

That can have the effect of in your loop That you have multiple physics *
update()* calls per 1 *draw()* call.
def game_update():
# ...draw() and physics_update() are called here


example debug output of func call order:
at: game_update
at: physics_tick()
at: physics_tick()
at: physics_tick()
at: draw()


-- 
Jake

Re: [pygame] frame independant movement

[Kris Schnee]

On 2010.8.28 1:42 AM, R. Alan Monroe wrote:



In other words, use a small enough time step that the difference
is not big enough to be a problem. But if you're doing that, you
might as well pick one sufficiently small time step and use a
variable number of them per frame, so that the physics is
always predictable whatever the frame rate.


While we're on the time topic, is there an easy way to do slo-mo, a la
Peggle Extreme Fever or a Burnout multi-car pileup?


Hmm. If your standard physics time-step is small enough that you can 
avoid problems like collision, making the time-step smaller than that 
doesn't seem like it'd hurt anything. (Though I might misunderstand some 
of the argument earlier.) And if it did, maybe it's enough that you 
don't need to care. Or if you were _really_ concerned, you could even 
back up the world objects' status at time 0, simulate times .1, .2, .3 
&c instead of your usual 1, 2, 3, &c, and when you were done showing 
off, revert to time 0 and do a 1-unit time-step to eliminate any 
deviation from your usual physics.

Re: [pygame] frame independant movement

[R. Alan Monroe]

> In other words, use a small enough time step that the difference
> is not big enough to be a problem. But if you're doing that, you
> might as well pick one sufficiently small time step and use a
> variable number of them per frame, so that the physics is
> always predictable whatever the frame rate.

While we're on the time topic, is there an easy way to do slo-mo, a la
Peggle Extreme Fever or a Burnout multi-car pileup?

Alan

Re: [pygame] frame independant movement

[Greg Ewing]

Christopher Night wrote:
But of course, it's extremely easy to do constant-acceleration 
motion as well:


x += vx * dt + 0.5 * g * dt ** 2
vx += g * dt


Yes, you can do this kind of thing if the differential equations
governing your physics have an exact closed-form solution. But
that's not always the case -- simulating an object orbiting a
planet is one example.


dt = max(clock.tick() * 0.001, 0.1)
for j in range(5):
for sprite in sprites:
sprite.think(dt/5.)


In other words, use a small enough time step that the difference
is not big enough to be a problem. But if you're doing that, you
might as well pick one sufficiently small time step and use a
variable number of them per frame, so that the physics is
always predictable whatever the frame rate.

Although... you probably *do* want the physics to slow down if
the frame rate gets too low, otherwise the game becomes unplayable
due to the player not getting enough feedback.

Anyway, it's fine to have a library to do this, but there are some 
simple things that have always worked for me.


Even in the simple cases, there is benefit in having a library
that you can rely on to do it all right, instead of having to
think about whether the assumptions behind the particular shortcuts
you're using are valid in the circumstances.

--
Greg

Re: [pygame] frame independant movement

[Casey Duncan]

On Aug 27, 2010, at 9:06 AM, James Paige wrote:

> On Fri, Aug 27, 2010 at 08:43:59AM -0700, Brian Fisher wrote:
>>   So you asked "what else do you need?" well the answer is if you want
>>   consistent non-linear physics (like say you want the players to jump the
>>   same all the time), then the "else" you need is fixed size timesteps for
>>   your physical simulation.
> 
> I seem to remember that one of the Quake games (or was it all of them?) 
> did this /wrong/. The distance your character could jump was affected by 
> your frame rate, making certain hard jumps impossible at certain frame 
> rates.

This page explains that issue nicely:

http://www.niksula.cs.hut.fi/~hkankaan/Homepages/gravity.html

-Casey

Re: [pygame] frame independant movement

[Christopher Night]

Yes, a high-quality physics engine would aim for consistency. However, you
can do drag with variable timesteps pretty easily as well, if not exactly
correct, then good to second order in dt. Complicated things like orbital
motion are difficult, and I can definitely see using a fixed timestep when
you need good simulations.

On the other hand, despite having programmed plenty of physics simulations,
I've never needed to use it in a game. Of course it depends on the type of
game, but I certainly would not jump to a fixed timestep as my first
solution.

I also find it very annoying when a game prohibits me from running it faster
than 20fps, no matter how fast my computer is capable of running it. Just my
opinion, though.

-Christopher

On Fri, Aug 27, 2010 at 12:22 PM, Brian Fisher wrote:

> On Fri, Aug 27, 2010 at 9:10 AM, Christopher Night  > wrote:
>
>> Sure. But of course, it's extremely easy to do constant-acceleration
>> motion as well:
>>
>> y += vy * dt + 0.5 * g * dt ** 2
>> vy += g * dt
>>
>> Sure, that explicit integration technique works fine if you can write an
> explicit integration function - I've used that same technique even with
> fixed time-steps because it's more accurate. But now how about if you have
> acceleration and friction for a car driving on a surface - can you write a
> single dt based function for that? now how about something that is
> accelerating away with a spring on it? or maybe something falling while
> accelerating off axis with a spring attached? It very quickly gets beyond
> your ability to write such functions if you try and do really interesting
> stuff.
>
> While consistent timesteps on the other hand, make it so the thing is
> always consistent and repeatable, even with simple update functions. Don't
> you want your game to behave the same regardless of frame rate? If you do,
> then fixed timestep simulation loops is a simple elegant widely used
> solution.
>

Re: [pygame] frame independant movement

[Brian Fisher]

On Fri, Aug 27, 2010 at 9:10 AM, Christopher Night
wrote:

> Sure. But of course, it's extremely easy to do constant-acceleration motion
> as well:
>
> y += vy * dt + 0.5 * g * dt ** 2
> vy += g * dt
>
> Sure, that explicit integration technique works fine if you can write an
explicit integration function - I've used that same technique even with
fixed time-steps because it's more accurate. But now how about if you have
acceleration and friction for a car driving on a surface - can you write a
single dt based function for that? now how about something that is
accelerating away with a spring on it? or maybe something falling while
accelerating off axis with a spring attached? It very quickly gets beyond
your ability to write such functions if you try and do really interesting
stuff.

While consistent timesteps on the other hand, make it so the thing is always
consistent and repeatable, even with simple update functions. Don't you want
your game to behave the same regardless of frame rate? If you do, then fixed
timestep simulation loops is a simple elegant widely used solution.

Re: [pygame] frame independant movement

[Christopher Night]

Here's what I always do:

dt = clock.tick() * 0.001
x += vx * dt
y += vy * dt

And all the sprites have a think(dt) method that updates them as if dt
seconds have passed. What else do you need?

-Christopher

On Fri, Aug 27, 2010 at 11:19 AM, James Paige wrote:

> On Fri, Aug 27, 2010 at 10:59:09AM -0400, Kris Schnee wrote:
> > On 2010.8.27 10:36 AM, B W wrote:
> >> Howdy,
> >>
> >> Reviving this old thread. The comments by Patrick and Brian really
> >> intrigued me, so I pursued the topic. Found a few interesting articles
> >> and one great article. My study has resulted in a recipe for those of us
> >> continually nagged by the question, "how can I get constant game speed
> >> independent of frame rate?". The demo requires Pygame, but the clock
> >> module only requires Python.
> >
> > Isn't it simply a matter of creating a Pygame Clock object and calling
> > clock.tick() to delay until the appropriate time to maintain some max
> > framerate?
>
> That only caps a max framerate. What Gumm is talking about is when your
> framerate and your game simulation rate can be adjusted independantly
>
> ---
> James Paige
>

Re: [pygame] frame independant movement

[Christopher Night]

Sure. But of course, it's extremely easy to do constant-acceleration motion
as well:

x += vx * dt + 0.5 * g * dt ** 2
vx += g * dt

These results will be exactly correct. I did run into the issue with
collision detection at one point. In my case, I needed at least, say, 10fps
for the collision detection to work, and I decided that if the computer
couldn't handle that, I would accept some slowdown so that the game at least
worked. All I had to do was:

dt = max(clock.tick() * 0.001, 0.1)

In another case, I  needed higher framerate for collision detection (say
50fps), and I was render-limited, not physics-limited. In that case I did:

dt = max(clock.tick() * 0.001, 0.1)
for j in range(5):
for sprite in sprites:
sprite.think(dt/5.)

So I only got slowdown when the framerate dropped below 10.

Anyway, it's fine to have a library to do this, but there are some simple
things that have always worked for me.

-Christopher

On Fri, Aug 27, 2010 at 11:43 AM, Brian Fisher wrote:

> That approach is perfectly fine with linear movement - because the linear
> calculations aren't affected significantly by how large dt is (or put
> another way: x += vx*2 is nearly identical to x += vx*1, x += vx*1 on your
> computer)
>
> However, with any nonlinear physics (like say, gravity's relationship to
> position, or an accelerating object)  or with discrete actions that happen
> once per frame (like say the artificial intelligence for an enemy that
> decides what to do once every frame), then your game behavior can change
> quite significantly depending on what values of dt you get.
>
> ---
> For example, lets say you do gravity like this:
> vy = vy + gravity*dt
> y = y + vy*dt
>
> with a dt of 2, from vy = 0, y = 0, the result is:
> vy = vy + gravity*2 = gravity*2
> y = y + (gravity*2)*2 = gravity*4
>
> however if you get a dt of 1 twice, from the same starting point, the
> result is:
> vy = vy + gravity*1 = gravity
> y = y + (gravity)*1 = gravity
> ...
> vy = vy + gravity*1 = gravity + gravity = gravity*2
> y = y + (gravity*2)*1 = gravity + gravity*2 = gravity*3
> ---
>
> so you've only moved 3/4 of the distance (3 vs. 4 gravitys) down with a
> frame rate that is twice as fast, even though you are parameterizing
> everything on dt. Note the acceleration component (which is linear with
> time) is consistent and accurate with both timestep sizes.
>
> So you asked "what else do you need?" well the answer is if you want
> consistent non-linear physics (like say you want the players to jump the
> same all the time), then the "else" you need is fixed size timesteps for
> your physical simulation.
>
>
>
> On Fri, Aug 27, 2010 at 8:27 AM, Christopher Night  > wrote:
>
>> Here's what I always do:
>>
>> dt = clock.tick() * 0.001
>> x += vx * dt
>> y += vy * dt
>>
>> And all the sprites have a think(dt) method that updates them as if dt
>> seconds have passed. What else do you need?
>>
>> -Christopher
>>
>>
>> On Fri, Aug 27, 2010 at 11:19 AM, James Paige 
>> wrote:
>>
>>> On Fri, Aug 27, 2010 at 10:59:09AM -0400, Kris Schnee wrote:
>>> > On 2010.8.27 10:36 AM, B W wrote:
>>> >> Howdy,
>>> >>
>>> >> Reviving this old thread. The comments by Patrick and Brian really
>>> >> intrigued me, so I pursued the topic. Found a few interesting articles
>>> >> and one great article. My study has resulted in a recipe for those of
>>> us
>>> >> continually nagged by the question, "how can I get constant game speed
>>> >> independent of frame rate?". The demo requires Pygame, but the clock
>>> >> module only requires Python.
>>> >
>>> > Isn't it simply a matter of creating a Pygame Clock object and calling
>>> > clock.tick() to delay until the appropriate time to maintain some max
>>> > framerate?
>>>
>>> That only caps a max framerate. What Gumm is talking about is when your
>>> framerate and your game simulation rate can be adjusted independantly
>>>
>>> ---
>>> James Paige
>>>
>>
>>
>

Re: [pygame] frame independant movement

[Kris Schnee]

On 2010.8.27 11:43 AM, Brian Fisher wrote:

That approach is perfectly fine with linear movement - because the
linear calculations aren't affected significantly by how large dt is (or
put another way: x += vx*2 is nearly identical to x += vx*1, x += vx*1
on your computer)

However, with any nonlinear physics (like say, gravity's relationship to
position, or an accelerating object)  or with discrete actions that
happen once per frame (like say the artificial intelligence for an enemy
that decides what to do once every frame), then your game behavior can
change quite significantly depending on what values of dt you get.




So you asked "what else do you need?" well the answer is if you want
consistent non-linear physics (like say you want the players to jump the
same all the time), then the "else" you need is fixed size timesteps for
your physical simulation.


Makes sense. Another example would be collision detection. If you've got 
a platform .1 unit thick and your 1-unit-tall character falls 2 units in 
one frame due to low framerate, then they'll fall through the platform.

Re: [pygame] frame independant movement

[James Paige]

On Fri, Aug 27, 2010 at 08:43:59AM -0700, Brian Fisher wrote:
>So you asked "what else do you need?" well the answer is if you want
>consistent non-linear physics (like say you want the players to jump the
>same all the time), then the "else" you need is fixed size timesteps for
>your physical simulation.

I seem to remember that one of the Quake games (or was it all of them?) 
did this /wrong/. The distance your character could jump was affected by 
your frame rate, making certain hard jumps impossible at certain frame 
rates.

---
James Paige

Re: [pygame] frame independant movement

[Brian Fisher]

That approach is perfectly fine with linear movement - because the linear
calculations aren't affected significantly by how large dt is (or put
another way: x += vx*2 is nearly identical to x += vx*1, x += vx*1 on your
computer)

However, with any nonlinear physics (like say, gravity's relationship to
position, or an accelerating object)  or with discrete actions that happen
once per frame (like say the artificial intelligence for an enemy that
decides what to do once every frame), then your game behavior can change
quite significantly depending on what values of dt you get.

---
For example, lets say you do gravity like this:
vy = vy + gravity*dt
y = y + vy*dt

with a dt of 2, from vy = 0, y = 0, the result is:
vy = vy + gravity*2 = gravity*2
y = y + (gravity*2)*2 = gravity*4

however if you get a dt of 1 twice, from the same starting point, the result
is:
vy = vy + gravity*1 = gravity
y = y + (gravity)*1 = gravity
...
vy = vy + gravity*1 = gravity + gravity = gravity*2
y = y + (gravity*2)*1 = gravity + gravity*2 = gravity*3
---

so you've only moved 3/4 of the distance (3 vs. 4 gravitys) down with a
frame rate that is twice as fast, even though you are parameterizing
everything on dt. Note the acceleration component (which is linear with
time) is consistent and accurate with both timestep sizes.

So you asked "what else do you need?" well the answer is if you want
consistent non-linear physics (like say you want the players to jump the
same all the time), then the "else" you need is fixed size timesteps for
your physical simulation.


On Fri, Aug 27, 2010 at 8:27 AM, Christopher Night
wrote:

> Here's what I always do:
>
> dt = clock.tick() * 0.001
> x += vx * dt
> y += vy * dt
>
> And all the sprites have a think(dt) method that updates them as if dt
> seconds have passed. What else do you need?
>
> -Christopher
>
>
> On Fri, Aug 27, 2010 at 11:19 AM, James Paige wrote:
>
>> On Fri, Aug 27, 2010 at 10:59:09AM -0400, Kris Schnee wrote:
>> > On 2010.8.27 10:36 AM, B W wrote:
>> >> Howdy,
>> >>
>> >> Reviving this old thread. The comments by Patrick and Brian really
>> >> intrigued me, so I pursued the topic. Found a few interesting articles
>> >> and one great article. My study has resulted in a recipe for those of
>> us
>> >> continually nagged by the question, "how can I get constant game speed
>> >> independent of frame rate?". The demo requires Pygame, but the clock
>> >> module only requires Python.
>> >
>> > Isn't it simply a matter of creating a Pygame Clock object and calling
>> > clock.tick() to delay until the appropriate time to maintain some max
>> > framerate?
>>
>> That only caps a max framerate. What Gumm is talking about is when your
>> framerate and your game simulation rate can be adjusted independantly
>>
>> ---
>> James Paige
>>
>
>

Re: [pygame] frame independant movement

[James Paige]

On Fri, Aug 27, 2010 at 10:59:09AM -0400, Kris Schnee wrote:
> On 2010.8.27 10:36 AM, B W wrote:
>> Howdy,
>>
>> Reviving this old thread. The comments by Patrick and Brian really
>> intrigued me, so I pursued the topic. Found a few interesting articles
>> and one great article. My study has resulted in a recipe for those of us
>> continually nagged by the question, "how can I get constant game speed
>> independent of frame rate?". The demo requires Pygame, but the clock
>> module only requires Python.
>
> Isn't it simply a matter of creating a Pygame Clock object and calling  
> clock.tick() to delay until the appropriate time to maintain some max  
> framerate?

That only caps a max framerate. What Gumm is talking about is when your 
framerate and your game simulation rate can be adjusted independantly

---
James Paige

Re: [pygame] frame independant movement

[Kris Schnee]

On 2010.8.27 10:36 AM, B W wrote:

Howdy,

Reviving this old thread. The comments by Patrick and Brian really
intrigued me, so I pursued the topic. Found a few interesting articles
and one great article. My study has resulted in a recipe for those of us
continually nagged by the question, "how can I get constant game speed
independent of frame rate?". The demo requires Pygame, but the clock
module only requires Python.


Isn't it simply a matter of creating a Pygame Clock object and calling 
clock.tick() to delay until the appropriate time to maintain some max 
framerate?

Re: [pygame] frame independant movement

[B W]

Howdy,

Reviving this old thread. The comments by Patrick and Brian really intrigued
me, so I pursued the topic. Found a few interesting articles and one great
article. My study has resulted in a recipe for those of us continually
nagged by the question, "how can I get constant game speed independent of
frame rate?". The demo requires Pygame, but the clock module only requires
Python.

GameClock (http://www.pygame.org/wiki/ConstantGameSpeed) derived from
"deWiTTERS Game Loop" (http://www.koonsolo.com/news/dewitters-gameloop/).

Cheers,

Gumm

Re: [pygame] frame independant movement

[Horst JENS]

> Is anyone aware of any websites that describe this time/frame business
> pictorially? I have read about it repeatedly and browsed a lot of
> pseudocod over the years, but without a proper diagram it's not really
> sinking in for a visual thinker like myself.
> 
> 
> Alan
> 

It's till in developement:
http://www.spielend-programmieren.at/pythongamebook/doku.php?id=en:part2:step006

-Horst



-- 
Horst JENS
horst.j...@spielend-programmieren.at
http://www.spielend-programmieren.at


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [pygame] frame independant movement

[B W]

This is kind of a caveman method that might waste a few precious FPS, but I
used it successfully (I think--I mean, nobody complained my game runs like
crap. :))

Run a frame-flipping benchmark for a second or two as part of your program's
startup, in which you blit the whole screen each frame and record the
average FPS (or minimum FPS if you're a glass-half-full guy). Then pick some
arbitrary percentage of computational overhead you want to reserve for
worst-case game computations, say 10% or 15%, and shave that off the top:
max_fps = bench_fps * 0.15. Then clock.tick(max_fps) to throttle your frame
rate.

Hypothetically you can get near-max FPS on any system. You could then code
your game speed factor in the manner described by the others in this thread.

Not all computers are created equally, though. One may excel or not in any
area depending on the parts and how well they are intergrated. There may be
some systems on which this kind of fudging doesn't work so you could also
provide a means for the user to manually cap FPS if consistent frame rate is
important.

Gumm

Re: [pygame] frame independant movement

[Ian Mallett]

...except that because you know the way gravity works (-9.8m/s*s) and, if
you set a constant dt, you can compensate accordingly.

For example, a projectile traverses a parabolic arc.  If your character were
to jump along this arc, naturally, trying to numerically approximate this
will give an error.  If you use the integrated function (the parabola)
instead, you'll get a correct result.

Re: [pygame] frame independant movement

[Brian Fisher]

On Wed, Feb 3, 2010 at 3:30 PM, R. Alan Monroe wrote:

> > The nice thing about limiting the framerate versus having calculations be
> > done based on time passed is that it is much more consistent. With dt
> > calculations you will often get huge jumps on slower computers and extra
> > slow movement in cases on fast machines, just do to inaccuracies and
> error
> > in the calculation.  On a slower machine, no matter which timing method
> you
> > use it will be unpleasant.
>
> What kind of innacuracies, specifically?
>
> Any time-step based integration of non-linear functions will have errors
and inaccuracies, which are larger the larger the time-step is.

...and pretty much all interesting real world physics are non-linear
functions.

So gravity for instance - if acceleration = time*gravity and position =
time*acceleration, the relationship between position and gravity over time
is nonlinear, specifically it changes with the square of time elapsed
(position = time*time*gravity). Doing that calculation as the sum of
repeated linear calculations, will have error. The magnitude of that error
will change with your time-step size.

The way that's a problem with a game, is when a level is dsigned so that gap
is exactly the right distance to be able to jump across it - but then some
slower computer uses a different larger time-step than your level designer -
so on that fast computer, you can't make the jump, cause the error on the
gravity effect is higher, so it pulls the player down sooner.

Some other examples of non-linear places with error are springs, friction,
application of the force of explosions that aren't instantaneous, etc. etc.
All those things and more will behave differently based on your time-step.

Re: [pygame] frame independant movement

[Casey Duncan]

On Feb 3, 2010, at 4:30 PM, R. Alan Monroe wrote:

>> The nice thing about limiting the framerate versus having calculations be
>> done based on time passed is that it is much more consistent. With dt
>> calculations you will often get huge jumps on slower computers and extra
>> slow movement in cases on fast machines, just do to inaccuracies and error
>> in the calculation.  On a slower machine, no matter which timing method you
>> use it will be unpleasant.
> 
> What kind of innacuracies, specifically?

Typical incremental algorithms used in games to simulate "physics" (or even 
just basic non-linear movement) give different answers over time with different 
time step intervals. Simple algorithms, such as Euler's method in particular, 
are especially bad in this regard. This is true even if the time step does not 
vary over time, but can become especially acute if it does. If for example, 
time steps have been coming at a steady 30/sec and all of a sudden a few steps 
are at a rate more like 5/sec, things can not only become inaccurate, but also 
unstable if you aren't careful.

Think about it this way, if you have many bodies in motion in a game, the more 
they move each frame, the harder it is for you to accurately simulate how they 
interact. When things move too far each step, things can penetrate or pass 
through things, generate ridiculously large collision response forces or start 
resonating and shatter into a million pieces. 

Also at long time step intervals any code that polls the player's controls or 
AI code gets called much less frequently, changing the whole behavior of the 
game in undesirable ways.

>> One method for having a smooth variable framerate, without the issues of
>> variable time calculations, is to have a fixed time step. Each frame, you
>> may process more than one timestep, if you need to in order to keep up. The
>> timestep has a fixed amount of time it is supposed to similate, say, .02,
>> which would be 60 times per second. If the user is able to run at 60 fps,
>> they get very smooth animation, as only one step is occuring on each frame.
>> If the user can only run at 30 fps, they will get two steps each frame, so
>> it will be jerkier, but still accurate. If they can only run at 10 fps, you
>> would set a limit on it (maybe the max is two timesteps in a frame), so
>> things would be slower for them but maybe still playable.
> 
>> [code snipped]
> 
> Is anyone aware of any websites that describe this time/frame business
> pictorially? I have read about it repeatedly and browsed a lot of
> pseudocod over the years, but without a proper diagram it's not really
> sinking in for a visual thinker like myself.

It's tough to generalize this visually, but here's an example of how Euler's 
method diverges from an exact simulation over time:

http://www.boomer.org/c/p3/c10/c1002.html

-Casey

Re: [pygame] frame independant movement

[R. Alan Monroe]

> The nice thing about limiting the framerate versus having calculations be
> done based on time passed is that it is much more consistent. With dt
> calculations you will often get huge jumps on slower computers and extra
> slow movement in cases on fast machines, just do to inaccuracies and error
> in the calculation.  On a slower machine, no matter which timing method you
> use it will be unpleasant.

What kind of innacuracies, specifically?



> One method for having a smooth variable framerate, without the issues of
> variable time calculations, is to have a fixed time step. Each frame, you
> may process more than one timestep, if you need to in order to keep up. The
> timestep has a fixed amount of time it is supposed to similate, say, .02,
> which would be 60 times per second. If the user is able to run at 60 fps,
> they get very smooth animation, as only one step is occuring on each frame.
> If the user can only run at 30 fps, they will get two steps each frame, so
> it will be jerkier, but still accurate. If they can only run at 10 fps, you
> would set a limit on it (maybe the max is two timesteps in a frame), so
> things would be slower for them but maybe still playable.

> [code snipped]

Is anyone aware of any websites that describe this time/frame business
pictorially? I have read about it repeatedly and browsed a lot of
pseudocod over the years, but without a proper diagram it's not really
sinking in for a visual thinker like myself.


Alan

Re: [pygame] frame independant movement

[Brian Fisher]

The way Patrick describes is *by far* the most common way the main loop is
done in professional games. As he said, it provides consistent game behavior
but allows the actual frame rate to vary based on what the platform can
actually provide. The system actually works very very well, as long as
drawing takes longer than updating (which it still usually does, partially
cause of vsync to the screens refresh rate). However, if updating takes
significantly longer than drawing, then doing n updates for each draw ends
up making a less playable game versus just slowing down game play and having
one update per draw (but if that's your case, the gameplay suffers no matter
what your main loop does, so maybe it doesn't matter)

...and .02 is 50 fps, not 60 :)  GAMESPEED = 1/60.0 would be a better way to
do that.

.. and for max, I personally think 4 works really well, cause 15fps with a
60 cycle per second simulation is usually quite playable, but if your fps
drops below 15, it's usually more playable to also slow the game down.


On Wed, Feb 3, 2010 at 11:59 AM, Patrick Mullen wrote:

> One method for having a smooth variable framerate, without the issues of
> variable time calculations, is to have a fixed time step. Each frame, you
> may process more than one timestep, if you need to in order to keep up. The
> timestep has a fixed amount of time it is supposed to similate, say, .02,
> which would be 60 times per second. If the user is able to run at 60 fps,
> they get very smooth animation, as only one step is occuring on each frame.
> If the user can only run at 30 fps, they will get two steps each frame, so
> it will be jerkier, but still accurate. If they can only run at 10 fps, you
> would set a limit on it (maybe the max is two timesteps in a frame), so
> things would be slower for them but maybe still playable.
>
> def dostuff(dt):
>man.x += speed*dt
>
> GAMESPEED = .02
>
> while 1:
>dt = clock.tick()
>max=2
>while dt>0 and max:
>   dt -= GAMESPEED
>   max -= 1
>   dostuff(GAMESPEED)
>
> There might be other problems with this, I've never done it this way, only
> seen it referred to. I know in some engines, like doom3, the physics of
> everything, game logic etc, happens at a fixed 30hz rate; whereas animation
> of the scene is much smoother.
>
> I am usually lazy and just do clock.tick(30) lol.
>
>

Re: [pygame] frame independant movement

[Patrick Mullen]

The nice thing about limiting the framerate versus having calculations be
done based on time passed is that it is much more consistent. With dt
calculations you will often get huge jumps on slower computers and extra
slow movement in cases on fast machines, just do to inaccuracies and error
in the calculation.  On a slower machine, no matter which timing method you
use it will be unpleasant.

One method for having a smooth variable framerate, without the issues of
variable time calculations, is to have a fixed time step. Each frame, you
may process more than one timestep, if you need to in order to keep up. The
timestep has a fixed amount of time it is supposed to similate, say, .02,
which would be 60 times per second. If the user is able to run at 60 fps,
they get very smooth animation, as only one step is occuring on each frame.
If the user can only run at 30 fps, they will get two steps each frame, so
it will be jerkier, but still accurate. If they can only run at 10 fps, you
would set a limit on it (maybe the max is two timesteps in a frame), so
things would be slower for them but maybe still playable.

def dostuff(dt):
   man.x += speed*dt

GAMESPEED = .02

while 1:
   dt = clock.tick()
   max=2
   while dt>0 and max:
  dt -= GAMESPEED
  max -= 1
  dostuff(GAMESPEED)

There might be other problems with this, I've never done it this way, only
seen it referred to. I know in some engines, like doom3, the physics of
everything, game logic etc, happens at a fixed 30hz rate; whereas animation
of the scene is much smoother.

I am usually lazy and just do clock.tick(30) lol.

Timing gets even more interesting when you do multiplayer, then you are
dealing with different time rates for each player. Fun stuff :)

On Wed, Feb 3, 2010 at 3:38 AM, René Dudfield  wrote:

> On Wed, Feb 3, 2010 at 7:06 PM, DR0ID  wrote:
> > On 03.02.2010 11:25, inigo delgado wrote:
> >>
> >> "Another thing you can do is just use Clock to limit the FPS to 60 or
> >> something, but then your game will run slower if you're not getting 60
> fps."
> >>
> >> Well, true, but you MUST determine the framerate that  you want for your
> >> game, otherway you will get a 60 FPS in your PC, 70 in another and 120
> in
> >> another one that is much more faster/newer than yours and in witch your
> game
> >> will turn unusable at this framerate
> >>
> >> I do this:
> >>
> >> while(true): #principal loop
> >># get current time
> >>t = time.time()
> >>
> >>doAll()
> >>
> >>#At the end i get the time needed to do the calculatons & flip
> >>T = t - time.time()
> >>delta = T - 1/desiredFrameRate
> >>if (delta > 0): # if the cycle has been done too fast
> >>time.wait(delta)
> >>This way you have your desired framerate or the maximum possible.
> >> Additionally you can do this:
> >>else:
> >>GLOBAL_T = GLOBAL_STANDAR_T - delta # delta is <= 0, - and - is +
> >>
> >> Being GLOBAL_T the t that you use for your position calculations and
> >> global_standar_t the value of global_t if delta is 0.
> >
> > Hi
> >
> > You will get different framerates only if you don't limit the fps. Using
> > http://www.pygame.org/docs/ref/time.html#Clock.tick you will have always
> the
> > specified framerate except if the cpu can not keep up (then it will run
> > slower), but on faster machines tick will wait, similar to what you do
> (tick
> > might be more accurate).
> >
> > ~DR0ID
> >
>
>
> Just another note... use Clock.tick_busy_loop if you don't mind
> burning a bit of cpu to get far more accurate sleeping.  The OS sleep
> is often a bit random - and not really meant for accurate sleeping.
>
>
> cu,
>

Re: [pygame] frame independant movement

[René Dudfield]

On Wed, Feb 3, 2010 at 7:06 PM, DR0ID  wrote:
> On 03.02.2010 11:25, inigo delgado wrote:
>>
>> "Another thing you can do is just use Clock to limit the FPS to 60 or
>> something, but then your game will run slower if you're not getting 60 fps."
>>
>> Well, true, but you MUST determine the framerate that  you want for your
>> game, otherway you will get a 60 FPS in your PC, 70 in another and 120 in
>> another one that is much more faster/newer than yours and in witch your game
>> will turn unusable at this framerate
>>
>> I do this:
>>
>> while(true): #principal loop
>>    # get current time
>>    t = time.time()
>>    
>>    doAll()
>>    
>>    #At the end i get the time needed to do the calculatons & flip
>>    T = t - time.time()
>>    delta = T - 1/desiredFrameRate
>>    if (delta > 0): # if the cycle has been done too fast
>>        time.wait(delta)
>>    This way you have your desired framerate or the maximum possible.
>> Additionally you can do this:
>>    else:
>>        GLOBAL_T = GLOBAL_STANDAR_T - delta # delta is <= 0, - and - is +
>>
>> Being GLOBAL_T the t that you use for your position calculations and
>> global_standar_t the value of global_t if delta is 0.
>
> Hi
>
> You will get different framerates only if you don't limit the fps. Using
> http://www.pygame.org/docs/ref/time.html#Clock.tick you will have always the
> specified framerate except if the cpu can not keep up (then it will run
> slower), but on faster machines tick will wait, similar to what you do (tick
> might be more accurate).
>
> ~DR0ID
>


Just another note... use Clock.tick_busy_loop if you don't mind
burning a bit of cpu to get far more accurate sleeping.  The OS sleep
is often a bit random - and not really meant for accurate sleeping.


cu,

Re: [pygame] frame independant movement

[DR0ID]

On 03.02.2010 11:25, inigo delgado wrote:
"Another thing you can do is just use Clock to limit the FPS to 60 or 
something, but then your game will run slower if you're not getting 60 
fps."


Well, true, but you MUST determine the framerate that  you want for 
your game, otherway you will get a 60 FPS in your PC, 70 in another 
and 120 in another one that is much more faster/newer than yours and 
in witch your game will turn unusable at this framerate


I do this:

while(true): #principal loop
# get current time
t = time.time()

doAll()

#At the end i get the time needed to do the calculatons & flip
T = t - time.time()
delta = T - 1/desiredFrameRate
if (delta > 0): # if the cycle has been done too fast
time.wait(delta)
This way you have your desired framerate or the maximum 
possible. Additionally you can do this:

else:
GLOBAL_T = GLOBAL_STANDAR_T - delta # delta is <= 0, - and - is +

Being GLOBAL_T the t that you use for your position calculations and 
global_standar_t the value of global_t if delta is 0.


Hi

You will get different framerates only if you don't limit the fps. Using 
http://www.pygame.org/docs/ref/time.html#Clock.tick you will have always 
the specified framerate except if the cpu can not keep up (then it will 
run slower), but on faster machines tick will wait, similar to what you 
do (tick might be more accurate).


~DR0ID

Re: [pygame] frame independant movement

[inigo delgado]

Luke, you said:

"Another thing you can do is just use Clock to limit the FPS to 60 or
something, but then your game will run slower if you're not getting 60 fps."

Well, true, but you MUST determine the framerate that  you want for your
game, otherway you will get a 60 FPS in your PC, 70 in another and 120 in
another one that is much more faster/newer than yours and in witch your game
will turn unusable at this framerate

I do this:

while(true): #principal loop
# get current time
t = time.time()

doAll()

#At the end i get the time needed to do the calculatons & flip
T = t - time.time()
delta = T - 1/desiredFrameRate
if (delta > 0): # if the cycle has been done too fast
time.wait(delta)
This way you have your desired framerate or the maximum possible.
Additionally you can do this:
else:
GLOBAL_T = GLOBAL_STANDAR_T - delta # delta is <= 0, - and - is +

Being GLOBAL_T the t that you use for your position calculations and
global_standar_t the value of global_t if delta is 0.

Pseudocode, sure


2010/1/31 DR0ID 

>  On 31.01.2010 20:44, Yanom Mobis wrote:
>
>   How do you make things happen ingame at a constant speed regardless of
> frames-per-second? For example, i want my game object to move one square per
> second, even if the game is running 30, 45, 60, or 90 fps.
>
>
> Hi
>
> make it time dependent.
>
> 
> # dt is the time passed since the last frame
> # use a dt = min(100, dt) to make sure the longest possible frame is 100 ms
> long
> # this prevents 'jumps' when a frame took long (as moving the window on
> windows)
>
> def update(self, dt):
> self.position += self.velocity * dt
> 
>
> This solution may have other side effects.
>
> ~DR0ID
>



-- 
Nota: Tildes omitidas para evitar incompatibilidades.

:wq

Re: [pygame] frame independant movement

[DR0ID]

On 31.01.2010 20:44, Yanom Mobis wrote:
How do you make things happen ingame at a constant speed regardless of 
frames-per-second? For example, i want my game object to move one 
square per second, even if the game is running 30, 45, 60, or 90 fps.





Hi

make it time dependent.


# dt is the time passed since the last frame
# use a dt = min(100, dt) to make sure the longest possible frame is 100 
ms long
# this prevents 'jumps' when a frame took long (as moving the window on 
windows)


def update(self, dt):
self.position += self.velocity * dt


This solution may have other side effects.

~DR0ID

Re: [pygame] frame independant movement

[Luke Paireepinart]

On Sun, Jan 31, 2010 at 1:44 PM, Yanom Mobis  wrote:

>  How do you make things happen ingame at a constant speed regardless of
> frames-per-second? For example, i want my game object to move one square per
> second, even if the game is running 30, 45, 60, or 90 fps.
>
>
One way to do this is to use a time delta.
I.E.

prev_time = get_time()
while frames_updating:

update_display()
delta = get_time() - prev_time
move_distance = delta * 64 #(would move 64 pixels per second because
delta is a fraction of a second)
prev_time = get_time()

this is pseudocode, depending on your platform you'll have to figure out
what is best to use for get_time() function.  For example on some platforms
time.time will give you microsecond resolution and on some other platforms
only 1-second resolution.  Pygame has a function you can use for this in the
Clock() module.

Another thing you can do is just use Clock to limit the FPS to 60 or
something, but then your game will run slower if you're not getting 60 fps.