> You shouldn't depend on clock.tick to be constant.
> It's variable so it can keep the fps constant as the workload of your
> program as well as other programs on your system fluctuate.
> It's pretty surprising that it's constant at all.
> that's why you calculate dt, so you know the change. If clock.tick were
> constant the value wouldn't be necessary,
> you'd just divide 1000 ms by the FPS limit and you'd get your ms/frame.
OK. It was curiosity.
Imagine a monster position at x=10000*t, and t+=clock.tick().
The monster seems to skip 4 frames per second, even at 60FPS.
That was confusing me.
You´re right, the only way to get smooth movement is t+=1/60,
or a variable 1/60+-small error to adjust.
I didnt expect a really constant dt, but 2*dt every 0.25 seconds?
But now I see it works as expected:
From pyglet/clock.py
if sleeptime < -2 * self.period_limit:
# Missed the time by a long shot, let's reset the clock
# print >> sys.stderr, 'Step %f' % -sleeptime
self.next_ts = ts + 2 * self.period_limit
else:
# Otherwise keep the clock steady
self.next_ts = self.next_ts + self.period_limit
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
