   Varying framerate causes jerky animation
  I have a collision system that is composed of two stages: broad phase and narrow phase. Sometimes the narrow phase isn't executed so the fpsis high but sometimes it is and the fps drops. Sometimes some entities are checked for collision and sometimes they are not. All this time the fps is varying. I've implemented a framerate independent animation system using the delta time approach. But because of the fact that the framerate is changing constantly i experience objects moving slowly then fast again, based on the time from the last update until to the point i update the entity the current frame. I read about framerate independent animation somewhere here on gamedev and it seems this approach is nondeterministic. I saw that there are two other approaches to frame independent animation namely: the fixed time approach and the event based approach. I could not understand them fully. How do you choose the fixed amount of time to update when implementing the fixed time approach method?One method i tried was to update by an amount of time calculated as follows: t = 1.0f / GetFPS(), but the fps still varies by a big amount and this too causes slodowns in animation.What solutions do i have to experience smooth animation?   
  Your best option is to reduce the big variations in frame rate. What range of frame rates are you getting? Here's some possible solutions from easy to hard:- Cap the maximum frame rate (either by turning on vsync, or using a timer).- Optimize that narrow phase collision (you are testing this in release mode right?).- Use a ready made physics library, there are some free ones available.- Do the physics update on another thread.I'd also expect that this problem will solve itself to some extent as you add more complexity to the game.   ;Quote:What range of frame rates are you getting?Well i get very high framerates because the game is nothing than a breakout remake. I'm getting anything from 1500FPS to 2500 fps(fps is higher and higher as the bricks dissapear)Quote:- Cap the maximum frame rate (either by turning on vsync, or using a timer).Yeah, could do that.Quote:- Optimize that narrow phase collision (you are testing this in release mode right?).Well, i don't think i know how to optimize more than it is, it's as fast as it needs to be, i guess.Quote:- Use a ready made physics library, there are some free ones available.Could try this too. Needs to be cross platform though.Quote:- Do the physics update on another thread.I'm not sure how this would help on a single core CPU.[Edited by - Deliverance on August 12, 2008 6:48:00 AM];  Try and have a look at this article Fix Your Timestep!.It should explain the idea of separating rendering and updating and also how to update with a constant time interval (like 30 or 60 updates per second).   ;Quote:Original post by nife87Try and have a look at this article Fix Your Timestep!.It should explain the idea of separating rendering and updating and also how to update with a constant time interval (like 30 or 60 updates per second).Hey thanks that article is great!Though i have a question: how to you choose the fixed time step. I choosed it to be 1/200 becuase this looks good for what i'm wanting to simulate. But what will happen on systems that cannot have a 200 FPS or higher?   ;  You simply separate rendering and updating, so that rendering will only take place once all update steps up to the current update time has been performed (this should only be 0 or 1 step in most cases, since rendering should be able to be performed several times between each update).Most physics implementations AFAIK use a fixed time step of 1/60 (PC) or 1/30 (console) of a second.Of course, if each update step takes longer than the update interval to perform (which it should not on the minimum required system, a thing you have to ensure), then you will not see any rendering at all, since the system will be busy updating all the time. But this problem is to be expected anyhow if you are running a game on a system slower than required. To solve this issue, you could make a quick check in the loop to see whether there has been any rendering the last X seconds and possibly display an error message/image if this is indeed the case to make the user aware of the problem (a blank screen does not inform anyone about anything very well).I hope you get my point, but otherwise I will try a more visual approach :)Oh yeah, I do not know if the article mentions it, but you also have to save the last 2 (and possibly more) update datasets (like positions and such volatile data) and then interpolate these data with a delta time at each rendering step to avoid jerkiness.   ;Quote:Original post by DeliveranceQuote:Original post by nife87Try and have a look at this article Fix Your Timestep!.It should explain the idea of separating rendering and updating and also how to update with a constant time interval (like 30 or 60 updates per second).Hey thanks that article is great!Though i have a question: how to you choose the fixed time step. I choosed it to be 1/200 becuase this looks good for what i'm wanting to simulate. But what will happen on systems that cannot have a 200 FPS or higher?The way the loop is setup if the computer isn't fast enough to do a physics update every 200 FPS it will do multiple updates every frame until its caught up.  Its why the accumulator is getting subtracted by the fixed timestep interval.If you wanted to have your physics run at 200 FPS then dt = 0.005.  Say that the computer can only run at 60 FPS so deltaTime = 0.016.  Going throuh the while loop the first time the accumulator is bigger then dt.  Physics get updated and then the accumulator is subtracted by your fixed timestep so then the accumulator = 0.011 which is still bigger then your dt so the loop will get run again.  Using my example times your physics will get called four times for every game frame.  Which should produce results that would be very close to a computer that was faster and doing more updates per second.   ;Quote:Original post by stupid_programmerQuote:Original post by DeliveranceQuote:Original post by nife87Try and have a look at this article Fix Your Timestep!.It should explain the idea of separating rendering and updating and also how to update with a constant time interval (like 30 or 60 updates per second).Hey thanks that article is great!Though i have a question: how to you choose the fixed time step. I choosed it to be 1/200 becuase this looks good for what i'm wanting to simulate. But what will happen on systems that cannot have a 200 FPS or higher?The way the loop is setup if the computer isn't fast enough to do a physics update every 200 FPS it will do multiple updates every frame until its caught up.  Its why the accumulator is getting subtracted by the fixed timestep interval.If you wanted to have your physics run at 200 FPS then dt = 0.005.  Say that the computer can only run at 60 FPS so deltaTime = 0.016.  Going throuh the while loop the first time the accumulator is bigger then dt.  Physics get updated and then the accumulator is subtracted by your fixed timestep so then the accumulator = 0.011 which is still bigger then your dt so the loop will get run again.  Using my example times your physics will get called four times for every game frame.  Which should produce results that would be very close to a computer that was faster and doing more updates per second.Yeah i understood that, so there won't be any ununiform animation going on this way? Like objects moving "in frames".   ;  As nife87 said you will have to store previous positions of objects so you can interpolate between each frame so there is no jerkiness.  But yes it should be like using the high res timer to make things run at the same speed on every computer.Honestly I just use Bullet for physics which is cross platform and can take care of interpolation for you.  You can use it so you just pass it your delta time for the frame and it will do multiple physics steps if needed.   