I think I understand what you are saying, if I go with the
fixed-time-steps method: I remove all 'delta's from my math, and I
save alot of headaches. I instead call the physics update() more or
less depending on the framerate?
I need some clarification on the pseudo code:
I put a couple of questions in the code:
# (1) Is this the right way to implement the const-time-step? / what's wrong?
# (2) Does this location of .time_left matter? ( ie: right after
.draw() vs. right before first call of .update() vs right after
Clock.tick() ? )
# (3) On howto make up time:
Thanks for any fixes:
# pseudo.py
class Game():
"""pseudo-code, my attempt at constant-time-steps updates"""
# ...
def needToDoAnotherUpdate(self):
"""My guess on what I need to calculate"""
# .time_left = time since last draw()
# .time_adjusted = time_left - number_of_updates *
PHYSICS_TIME_STEP
# PHYSICS_TIME_STEP = time in MS of constant time between calls
to .update()
if self.time_adjusted > self.PHYSICS_TIME_STEP:
self.time_adjusted -= self.PHYSICS_TIME_STEP
return True
else:
return False
def update(self):
while not self.bDone:
# events
self.handle_events()
self.time_adjusted = self.time_left
# (1) Is this the right way to implement? / what's
wrong?
while self.needToDoAnotherUpdate():
# calculate all physics
self.update()
# else draw:
# draws everything
self.draw()
# (2) Does this location of .time_left matter?
#not sure If I should be getting time now, or right
before
# the first call to .update(), OR after
clock.tick() ?
self.time_left = pygame.time.get_ticks()
# Brian F said: make up for the time lost by extra
simulation
updates by doing fewer draws.
# (3) Not sure how else: So I did this: cap FPS
self.clock.tick(30) # pygame.time.Clock.tick(fps)
-- thanks,
jake
On Sat, May 10, 2008 at 1:30 PM, Brian Fisher <[EMAIL PROTECTED]> wrote:
> My high-level advice is that the approach you are trying to use to achieving
> frame-rate independence is a math heavy and complex path to getting right,
> and the issue you are seeing here is just the first of many like it (and
> some worse). There is a much simpler approach, where all your simulation
> update code doesn't care at all about frame rate or time elapsed, but
> instead you call your simulation update routine the right amount of times
> for how much time has elapsed, and make up for the time lost by extra
> simulation updates by doing fewer draws.
