Re: [pygame] Framerate Normalizer

["Jake b" <ninmonkeys@xxxxxxxxx>]

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 <brian@xxxxxxxxxxxxxxxxxxx> 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.