Sign in to follow this  
ajm113

Collision + Lag = Delay Reaction. (C++, Win32)

Recommended Posts

How can I make sure the collision is checked at the right time and not lagged by when for example the application starts up or for example if I'm running Fraps on my game and it lags the game and if I get a fps of 1-15 for a second the collision messes up and I can walk through a wall and get stuck. I only have it check the x and y axis when the player is moving when the move keys are pressed and it seems Fraps/lag can also effect the key checking to slow down so the player keeps moving even when I unpressed a move key when I get lag. So what I want to know is make a anti-lag system for collision and key checking with Win32, C++? Thank you, Andrew. Project Details: VS2008 C++ Win32 OpenGL

Share this post


Link to post
Share on other sites
Well you can't do anything in general about your application being interrupted...it's just something you have to live with when your platform is a multi-tasking operating system.

Anyway your real problem here is that when you're integrating your collision simulation, you'll get different results if your time step varies. If your time step is about 16ms then everything might be fine and you'll collide with the wall, but if it's 33ms then you might go right through it.

To solve this, you can use a fixed value for your timestep. So every time you update your collision simulation you always use 16.6ms, or some other value. This keeps your simulation stable, but you'll have problems if your game loop isn't actually running at that rate. If you're integrating with a timestep of 16.6ms (60fps) and you're actually rendering/updating at 33ms (30fps), then it will appear like everything's running in slow motion. It's similar to effect you see in old console games where when the framerate dips, the game actually runs slower. Or of course you'll get the opposite effect if you're running quicker than 60fps.

So to get around that problem, you can do multiple integrations per frame to "catch up" when your game is running slowly, or wait to do integrations if it's running quickly. When you're doing this you don't get apparent slowdowns or speedups , but you get another problem: when your game loop isn't running at the rate specified by your fixed time step, your game will appear "jerky". This is because on frame there might be only one integration, but then the next there could be two.

So again we need a solution, and this time it's to blend between the results of two different states of our physics simulation based on the amount of "real time" that's actually elapsed. So for instance say we have a fixed timestep of 16.6ms, and it took 24ms to render and do other processing. What we would do is do two integrations at 16.6 ms, and then set the state of our situation so that it's about halfway between the two integrations. So if an object was at X = 10 after the first integration and then at X = 20 after the second, we'd position it at X = 15.

There's a good explanation of what I'm talking about here.

Share this post


Link to post
Share on other sites
Probably a dumb question but is that superior to doing one integration at 16.6ms and then a second at 7.4ms? Does it matter if the timestep you use is smaller than your chosen rate?

Share this post


Link to post
Share on other sites
Quote:
Original post by Somnia
Probably a dumb question but is that superior to doing one integration at 16.6ms and then a second at 7.4ms? Does it matter if the timestep you use is smaller than your chosen rate?


Well if you do that you get the problem we first started out with: varying your timesteps will cause the results of your simulation to change depending on the performance of your app. Ideally you want your simulation to produce the same results every time, regardless of whether the app is running at 5fps or 500fps.

Share this post


Link to post
Share on other sites
You need to check the collision system you're using. With ODE, for instance, it is highly recommended that you do not vary the timesteps. In this case, follow MJP's recommendations and use only single or multiples of a fixed timestep for the system. As noted, you'll need to properly sync the graphics with the simulation.

Share this post


Link to post
Share on other sites
don't use timestamps. if you detect a collision with your collision mesh (AABB, sphere, whatever), just trace a ray from your last position to your destination position and find out if and where it collides. spatial acceleration structures could help so that you have to test fewer polygons.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this