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 <br...@hamsterrepublic.com>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 <cosmologi...@gmail.com
> > 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
>> <b...@hamsterrepublic.com>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
>>>
>>
>>
>
