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
On Wed, Feb 3, 2010 at 6:30 PM, R. Alan Monroe amon...@columbus.rr.comwrote:
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
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
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
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
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
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
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
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
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
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.comwrote:
On Fri,
On Fri, Aug 27, 2010 at 9:10 AM, Christopher Night
cosmologi...@gmail.comwrote:
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
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
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
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
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:
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
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
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
On Wed, Feb 3, 2010 at 7:06 PM, DR0ID dr...@bluewin.ch 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
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
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
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
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
On Wed, Feb 3, 2010 at 3:30 PM, R. Alan Monroe amon...@columbus.rr.comwrote:
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
...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
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.
On Sun, Jan 31, 2010 at 1:44 PM, Yanom Mobis ya...@rocketmail.com 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
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.
code
# dt is
29 matches
Mail list logo
