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 <ren...@gmail.com> wrote:
> 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 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,
>
