Sign in to follow this  
drazen

Ideal Gameloop Implementation

Recommended Posts

drazen    122
Hello,

I have been researching different methods on implementing a game loop. The most common I have found are:[list]
[*]FPS dependent on Constant Game Speed (Where you cap the FPS to some constant and sleep the remainder away)
[*]Game Speed dependent on Variable FPS (Where you subtract the new frame from the previous frame and use this to update the game)
[*]Constant Game Speed with Maximum FPS (Where you guarantee updating the game logic x amount of times per frame and then render the frame)
[/list]
I want a deterministic behavior for my game to help with networking and physics. It would seem that option 3 would be the best. I guess I am not 100 percent sure as to how to implement it.

Lets say that I want 60 frames per second. So, each frame should be 16.6666667 milliseconds long. I am not sure what my delta time should be or how often I should be updating my game logic before I render the frame.

I looked at these following resources.

[url="http://www.koonsolo.com/news/dewitters-gameloop/"]http://www.koonsolo....tters-gameloop/[/url]
[url="http://gafferongames.com/game-physics/fix-your-timestep/"]http://gafferongames...-your-timestep/[/url]

[url="http://gafferongames.com/game-physics/fix-your-timestep/"]T[/url]hank you

Share this post


Link to post
Share on other sites
SiddharthBhat    358
I personally prefer the 1st choice. It not only simplifies you work, lets you profile easily and lets you sets a target, it's also better in the sense that most physics engines require you to have a *[b][i]constact timestep[/i][/b]* if not, the physics starts to look all weird.

What I usually do is to update the game based on the current FPS, update the Physics engine with an absolute timestep which is at the framerate you cap (if your framerate cap is 60 FPS, then update the physics engine by 1.0/60.0 ). This provides both stable physics as well as a proper benchmark.

I know that many prefer to use the 2nd or 3rd method, but I personally prefer the 1st one :)

Bollu

Share this post


Link to post
Share on other sites
Cornstalks    7030
You forgot one: constant update rate and variable FPS. The idea is that you separate your rendering logic from your update logic, and you render as fast as you can and as many time as you can, while only updating your game at a specific rate. This makes physics engines happy and allows you to have better looking results (as you can interpolate your renderings).

I'm surprised you didn't mention this, as you linked to the Fix Your Time Step article.

AFAIK, this is what is normally done in most games.

Share this post


Link to post
Share on other sites
L. Spiro    25622
[quote name='Cornstalks' timestamp='1333084723' post='4926574']
You forgot one: constant update rate and variable FPS.
[/quote]
My understanding is that this is what was meant by “Constant Game Speed with Maximum FPS”, and yes it is the standard way to go.


L. Spiro

Share this post


Link to post
Share on other sites
Cornstalks    7030
[quote name='YogurtEmperor' timestamp='1333113080' post='4926665'] [quote name='Cornstalks' timestamp='1333084723' post='4926574'] You forgot one: constant update rate and variable FPS. [/quote] My understanding is that this is what was meant by “Constant Game Speed with Maximum FPS”, and yes it is the standard way to go.[/quote]
Now that you say it, that is probably what he intended by "Constant Game Speed with Maximum FPS." His description of it though is what made me think he was referring to something else (because there is no "guarantee updating the game logic x amount of times per frame" since the frame rate (and thus the frames) are totally independent of the game logic update frequency).

Share this post


Link to post
Share on other sites
L. Spiro    25622
[quote name='bollµ' timestamp='1333083150' post='4926567']
I personally prefer the 1st choice. It not only simplifies you work, lets you profile easily and lets you sets a target, it's also better in the sense that most physics engines require you to have a *[b][i]constact timestep[/i][/b]* if not, the physics starts to look all weird.

What I usually do is to update the game based on the current FPS, update the Physics engine with an absolute timestep which is at the framerate you cap (if your framerate cap is 60 FPS, then update the physics engine by 1.0/60.0 ). This provides both stable physics as well as a proper benchmark.

I know that many prefer to use the 2nd or 3rd method, but I personally prefer the 1st one :)

Bollu
[/quote]
I am just guessing that one of your peeves with #3 is that you consider there is no reason to draw multiple times the same frame over and over.
If logic causes position changes, and that only happens say 30 times per second, then rendering faster than that is useless since objects will still appear to move only 30 times per second, even if the actual FPS is 200.

But #3 is more complex than that, and also requires care in implementing. My next tutorial will be about this since this also just appeared in some code my ex-coworker had me debug.

#3 allows all of the stability required by physics engines and other systems but allows as-smooth-as-possible a framerate as players desire. Making players think their games are running smoothly is a very important aspect, and FPS is often used as a benchmark, so limiting your FPS as mentioned in #1 is never desirable. It also causes inconsistencies in most implementations because programmers who implement it tend to forget that timers, sleeping, and friends are not reliable. Most naive implementations set a timer or somehow force a certain FPS, but forget that no matter how you do this, timers, sleeping, and even while loops are subject to the thread scheduler which may (and will 99% of the time) decide to delay your execution for a few nanoseconds because another thread is busy.

In naive implementations, by forgetting the above, you will be passing a fixed delta each tick, because you assume hardware is reliable and each tick represents exactly that delta. This is wrong and will never ever happen in real life. Your ticks will never ever be the exact same amount apart no matter how hard you try. Method #3 handles this fact.


#3 relies on a bit of experience though. Implementing it incorrectly will actually heavily hinder your performance as my ex-coworker discovered.

I am not going to explain the nuances of that now because it will be more efficient to make a post about it on my site and then post that here. This is a problem that pokes out its head very frequently so I would rather not explain how to do it correctly multiple times.
Just wait about 12 hours.


L. Spiro

Share this post


Link to post
Share on other sites
Cornstalks    7030
[quote name='YogurtEmperor' timestamp='1333117929' post='4926695']
Just wait about 12 hours.
[/quote]
Waiting. While I get the idea of how this works, I've always wanted a good in depth article on it (and judging by your in depth article on your DXT compressor, it'll be a good one).

Share this post


Link to post
Share on other sites
rethan    149
Ultimately the "ideal" game loop depends on the game but my personal take:

I agree with bollµ that #1 is by far easier to code and gives good results (I do this myself as well). And sure, as L. Spiro points out you will realistically get around 29.99 fps or below if you lock at 30fps, but I don't believe this is such a huge problem in practice, and even then the fluctuations in real FPS should mostly be minor (IMO much less so than the fluctuations you will get if you allow rendering as fast as possible)

L. Spiro, you do point out some very good things to keep in mind when implementing this in your writeup (which I think got for any loop implementation), namely to make sure to get the current time only once per tick, storing time values in 64 bit ints, and making sure you always pass/use the same duration/time lapse for each tick to be consistent. (You may also want to talk about how to avoid wrap around timer issues by checking difference between times instead of checking absolute times too!)

I think the major problem with #3 is just getting it right. It is extremely, extremely easy to botch this, and if you go this route, you will need to decide which parts/objects that get drawn should be interpolated to take advantage of the extra fps (only fast moving objects, or all objects, what's the cutoff? other graphical variances like color changing etc?). And the other moral dilemma you will have to consider with this option is that what the user sees may not match the physics, aka hitboxes that don't correspond to what is shown visually which can be frustrating. That said, if this is done correctly, this does give awesome results and is pretty much required for networked games anyways which need prediction to visually smooth things out to begin with.

But hey, when in doubt, write both and compare yourself :)

Share this post


Link to post
Share on other sites
Krohm    5030
While we're at it, I have a question.
In the physics API I am using (Bullet, FYI) there's no chance to mess this up too much.
The physics will always tick at 30 fps, smaller timesteps will be interpolated.
By this point of view, there's nothing like an [i]updating timestep[/i] nor interpolation. From code point of view, nothing is changed.
[b]What kind of approach is that?[/b]
There's a very subtle difference between update by interpolation and update by simulation.

If that's not hijacking the thread, I also have another question.
I have scripts pretty much everywhere. I originally planned to give scripting logic 10 ticks per second. However, this caused some issues in many routines which were really supposed to run per-frame. For the time being, I'm ticking the scripts each frame. Any suggestions on separating those to run at a constant update rate?

Share this post


Link to post
Share on other sites
L. Spiro    25622
I have never used Bullet, Squirrel, PhysX, Box2D etc. I don’t know what they are doing, but from a conceptual standpoint it doesn’t seem reliable, specifically from the point I mentioned about not getting the real current time more than once per frame.

I am guessing they want to prevent that tragedy by getting the real current time themselves only “once per frame” and dealing with physics that way, in order to guarantee stability, but for competent developers that would actually decrease stability when they are already getting the current time only once per frame. The value passed to the physics simulation should be trusted, unless your goal is to target only beginner developers who might fall into one of the nuances I mentioned. In that case you would say to yourself, “The guy or girl using my physics engine is probably a newbie and doesn’t know all the nuances of timing. I should keep track of time myself to make sure.”
Hence I feel many physics engines are doing this, and as a result provide unstable results (even though the instabilities are extremely minor and probably only conceptual in practice).


But if you want to tick scripts in a similar manner, the concept for fixed time steps has not changed. It fully applies to ticking (updating) script as well. Scripts are only a subset of the whole engine. If the whole engine can wait 33.3 milliseconds until the next logical update, everything else can too. Except graphics.


L. Spiro

Share this post


Link to post
Share on other sites
Krohm    5030
I apologize for the late reply.
Bullet - I don't know other engines - work like this (at the simplest).
[code]world->stepSimulation(timeIncrement); // timeIncrement in seconds.[/code]
It is my understanding Bullet does not probe elapsed times internally - if not for profiling - and uses a constant tick internally. If the elapsed time since last tick is smaller than 1/30, results are produced by interpolation (extrapolation?) rather than simulation.
However, at an higher level of abstraction, this difference is not visible. As far as I understand, the time increment value is completely trusted. It is my understanding invariance is guaranteed.

From this, my original question: what kind of approach would that be?

[quote]But if you want to tick scripts in a similar manner, the concept for fixed time steps has not changed. It fully applies to ticking (updating) script as well. Scripts are only a subset of the whole engine. If the whole engine can wait 33.3 milliseconds until the next logical update, everything else can too. Except graphics.[/quote]Problem is figuring out what affects graphics. Thank you anyway, I suppose I will have my own thread about this at a proper time. Edited by Krohm

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