Jump to content
  • Advertisement
Sign in to follow this  
ninmonkeys

how to decouple graphics and physics

This topic is 3672 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I thought my graphics and physics were decoupled properly. But they are not. I used the gaffer.org/fix-your-timestep tutorial as a base. I first used my own physics engine, and test acceleration at 30fps, 60fps, and 210fps. the accelerations are different based on framerate. Meaning if FPS=30, and I hold arrow_up it takes 5 secs to reach the side of the screen. If FPS=60, it takes 4 secs. if FPS=210 it takes 1sec. (1) I need to find a way to get movement to be de-coupled from visual FPS so I can write a game that works on more that one specific computer. My thought was that it was my physics code that had an error, so I re-wrote my code using the physics engine. The problem is still there. (2) Is there another tutorial that could help me? (3) Know of any code / projects that I should look at to help me fix this? source: PyODE engine accel problem.zip [ snippet below ] Here's my .integrate() code.
def __init__(self):
	self.dt = .01 # equals 100 physics fps
	self.world = ode.World()		
	self.ship = Ship(self)	
	# physics timers, etc.
	self.total_time = 0.
	self.timeCur = pygame.time.get_ticks()/1000.#convert to secs
	self.accumulator = 0.	
	# for physics FPS 
	self.physics_fps = 0.
	self.physics_timeLast = 0.
	self.physics_fps_avg =  self.dt*1000. #0. #1000. / self.dt # 0. or expcted fps?

def update(self):
	"""integrate / update physics. using fixed-timestep.
	based off of: http://www.gaffer.org/game-physics/fix-your-timestep"""
	# [ time and dt are measured in seconds ]
	self.timeNew = pygame.time.get_ticks() / 1000. # convert to secs
	self.timeDelta = self.timeNew - self.timeCur
	self.timeCur = self.timeNew
	
	# physicsFPS [ my code to calc physics FPS, could be wrong. ]
	if self.timeNew - self.physics_timeLast >= 1.:
		self.physics_timeLast = self.timeNew
		self.physics_fps_avg += self.physics_fps
		self.physics_fps_avg /= 2
		self.physics_fps = 0.
		
	self.accumulator += self.timeDelta
	
	while self.accumulator >= self.dt:
		self.integrate( self.dt )
		self.total_time += self.dt
		self.accumulator -= self.dt
		self.physics_fps+=1
		
def integrate(self, dt):
	"""physics update, integrate."""
	self.world.step( self.dt )
	self.total_time += self.dt
[note: at first I was going to append this to my other post, but the question changed, so I made a new one to not confuse ] thanks, -- monkey

Share this post


Link to post
Share on other sites
Advertisement
The OPAL (Open Physics Abstraction Layer) has a "Thruster Engine" in it that does what you want. You could look at the source for it, which, at the bottom, uses ODE. Basically, I think the idea is that you'd have to know the change in time since you last applied a force and then apply a force proportional to the change in time.

Share this post


Link to post
Share on other sites
Your main loop tracks the current game time. The update maintains the time of last update. Each pass through the main loop you call update as long as the current game time is greater than the last update time. Well, actually you want next update time, but it's largely an arbitrary choice.

That's a bit differant than how you cap the display rate. With the display there is no point to doing intermediate displays. Just draw what the user is currently suppose to see. So you can just track time since last display. With the physics if it's suppose to update 100 times a second then you have to call it 100 times each second. Even though the actual time may not have any role in the actual calculations you still have to track it.

An important point to remember is zero or more times, not one or more times. If it's one or more times, i.e. the function call is in the loop conditional, then you will update at the greater of the target rate and the loop rate. So you end up with everything is fine at 30 fps, 60 fps, but at 200 fps it running twice as fast as it's suppose to. That's what I assumed you meant in the other post. Here it's more clear the update rate is the display rate.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!