I'm thinking here timing in game engine. Basically the operation of game loop is the following:
1. Calculate what happens between frames.
2. Draw it.
The problem is, however, that depending on the complexity of the scene the calculation takes different amounts of time. In other words the time between frames is not constant. As frame rate in games is usually as fast as possible it can't be set in constant value.
So how can the places of moving objects be calculated if the time is not known?
Game engine basics
Usually a game loop looks like the following, where you measure the amount of time that has elapsed.
This is a loop that's based on a variable time-step. Inside the Update method, you multiply all time based values by deltaTime (e.g. position += speed * deltaTime).
Or if using a fixed-time-step (this can be important for accurate physics), the main loop might look something like this:
Further reading:
http://gameprogrammingpatterns.com/game-loop.html
http://gafferongames.com/game-physics/fix-your-timestep/
This is a loop that's based on a variable time-step. Inside the Update method, you multiply all time based values by deltaTime (e.g. position += speed * deltaTime).
time = GetTime();
while(!quit)
{
newTime = GetTime();
deltaTime = newTime - time;
time = newTime;
Update(deltaTime);
Draw();
}Or if using a fixed-time-step (this can be important for accurate physics), the main loop might look something like this:
accumulator = 0;
stepSize = 1/60.0; // 'virtual' framerate
time = GetTime();
while(!quit)
{
newTime = GetTime();
deltaTime = newTime - time;
time = newTime;
accumulator += deltaTime;
while(accumulator >= stepSize)
{
accumulator -= stepSize;
Update(stepSize);
}
Draw();
}Further reading:
http://gameprogrammingpatterns.com/game-loop.html
http://gafferongames.com/game-physics/fix-your-timestep/
Hi JKAVS
Game loops are actually a pretty complex topic, there are a few ways to do what you want, though my knowledge on this topic is a little limited so hopefully others can give you more detailed answers.
1. You can record the current time in ms just before you update the state. Next time you are about to update the state, you take the time again and find the difference. So if we have an object that moves at 100pixels per second, and our last frame took 25ms to update and render, we know that object needs to move at 2.5 pixels in the next update.
timeTaken/1000 * velocity
milliseconds/1000 * pixels per second
25/1000*velocity
2. A cheap option that I do not encourage but can be useful for prototyping things, is to use a constant rate. Say you want your game to run at 40 fps, that is 25ms per frame. If you make the assumption that your hardware will always be faster than that, you can just do sleep(desired frame time - actual frame time)
Again I do not recommend this, but for personal projects that only you will use it is okay
I realise I haven't explained this well, please reply if you need clarification. Was a bit rushed in this post as I'm at work supposed to be playing with javascript, the horror..
As said you need to control the frame rate this may help, http://gameprogrammingpatterns.com/game-loop.html
Also, to elaborate that because it's not possible to measure how long the current frame is going to take *while* actually performing that frame's work, all the game loops based on delta-time measurement are actually using last frame's time duration. Usually this is fine, but in some cases (for example GPU command buffer becoming full and the GPU driver stalling on you) there may be a long frame followed by a short frame, or vice versa, even if the game's logic load remains constant. In this case using simply the last frame's time duration may result in visibly "jerky" motion. To some degree this can be alleviated by lowpass-filtering (smoothing) the timestep, but there's no magic "best" values for such smoothing; you'll have to experiment.
also note that ET based updates may not degrade gracefully when ET goes long, IE when et becomes an unexpectedly large value due to momentary graphics slowdowns when scene complexity suddenly rises - like when the action gets hot and heavy with lots of stuff going on on the screen. in fact it can "not degrade gracefully" to the point of unplayability in extreme cases. but workarounds are possible.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement