Understanding GameTime

re: Understanding GameTime

JLarkin — Thu, 26 Jul 2007 04:23:02 GMT

I saw that there was an "IsRunningSlowly" property, but could never really figure out its use. Now I know!

Also, on MotoGP, how would running the physics system twice work? Did you update positions/speeds and then do the same again just so that the deltas were smaller? Was it something like what follows?

physSim.Update();

I'm curious to see how something like that would work... Nice post, btw, thanks.

re: Understanding GameTime

Björn — Thu, 26 Jul 2007 06:37:14 GMT

The default 60Hz-because-of-TV-refresh makes me wonder: does this change to 50Hz when the XBox is connected to a PAL TV? Or - from a not too serious POV - is this just another default chosen in the spirit of "We are Americans and deal with i18n issues in v.Next"? :]

re: Understanding GameTime

bohemanja — Thu, 26 Jul 2007 08:20:06 GMT

Shawn.. You're awesome..

Thanks for your article.

This is exactly what I am looking in the past few days. This is by far the best and most comprehensive I can find regarding game timing.. :)

re: Understanding GameTime

Rim — Thu, 26 Jul 2007 18:15:07 GMT

Hmmm... In our DBP entry we opted for a fixed timestep at some 33 updates per second to keep CPU load low *and* enabled VSyncing to prevent tearing. Fraps indicated a steady 75 FPS, while examining the gameTime.ElapsedTime in the Update method shows it is called at the fixed timestep (33 FPS). So it would seem Draw can be called more often than Update.

I don't know if I'm misreading your post, but the scenarios you described only seem to mention "x calls to Update + one call to Draw()" (i.e. Draw is always limited by Update frequency), so I thought I'd point this out.

Please drop a line if this is horrible abuse of the fixed timestep :)

re: Understanding GameTime

ShawnHargreaves — Thu, 26 Jul 2007 18:28:45 GMT

> I don't know if I'm misreading your post, but > the scenarios you described only seem to

> mention "x calls to Update + one call to Draw

> ()" (i.e. Draw is always limited by Update

> frequency), so I thought I'd point this out.

At the moment we sometimes call draw more often than we really should (there's not really any point calling it twice if we didn't do an update in between, since it will just be drawing the same thing again!). This is likely to change in future versions.

GameTime outside America

Shawn Hargreaves Blog — Thu, 26 Jul 2007 21:05:46 GMT

Björn comments on my previous post : The default 60Hz-because-of-TV-refresh makes me wonder: does this

re: Understanding GameTime

PaulCunningham — Fri, 27 Jul 2007 00:56:15 GMT

Shawn says...

> If a particular frame happens to take unusually

> long, we automatically call Update some extra

> times to catch up, after which everything carries

> on as normal. The player may notice a slight

> glitch, but we automatically correct for this

> to minimize the impact.

Does this mean you keep a list of the last x frame times and pass us the average?

Currently I'm setting Game.IsFixedTimeStep = false and handling the fixed physics myself. I have to do some interpolation between last state and current state in Draw to get smooth animation. It all works but I'm not sure if it's overkill. It does isolate me from monitor frequencies, syncing to refresh, etc though.

re: Understanding GameTime

Rim — Fri, 27 Jul 2007 07:32:34 GMT

> At the moment we sometimes call draw more

> often than we really should (there's not

> really any point calling it twice if we

> didn't do an update in between, since it will

> just be drawing the same thing again!). This

> is likely to change in future versions.

Well, there actually is, if you consider VSyncing to prevent tearing a good reason. I always thought this was an exaggerated problem, but VSync does seem to make a difference in quality on my crappy Dell monitor.

Regardless, in my not-so-humble opinion I don't think it would be a good idea to change this behavior. As the need for your post indicates, the time handling is complicated enough as is. If the actual drawing frequency would be limited by the update interval, this might lead to more confusion (VSync already spawned countless topics of "I can't get my FPS above 60") and it would effectively render DX VSync useless in most fixed timestep scenarios.

Not drawing if nothing changed might be the smart thing to do, but it should make little difference as long as you can maintain your target rendering framerate anyway. If I can afford to draw at 75 FPS, why would I want to be limited by a fixed timestep that I typically only want to apply to the simulation/update?

Just my 2 cents though :)

re: Understanding GameTime

ShawnHargreaves — Fri, 27 Jul 2007 18:54:33 GMT

> Not drawing if nothing changed might be the

> smart thing to do, but it should make little

> difference as long as you can maintain your

> target rendering framerate anyway. If I can

> afford to draw at 75 FPS, why would I want to

> be limited by a fixed timestep that I typically

> only want to apply to the simulation/update?

Little difference, yes (the implementation in the framework today works fine in practice) but even a little difference is still a difference, and if it is possible to make even a little improvement, surely that's worth doing? :-)

Think of it this way: if an Update + Draw cycle completes within the alloted timespan, you have the choice of calling Draw again, or waiting doing nothing for the timespan to expire. What difference does this choice make to anything?

On the surface, nothing. Calling Draw twice without an Update in between should (if the game is programmed correctly) render exactly the same thing again, so the user will see no visible difference at all (the only time this could render something different is if the game was doing some kind of clever interpolation in their Draw method, but in that case they really ought to be using variable timestep mode in the first place).

There are in fact exactly two ways in which calling Draw again can make a difference:

1: This may affect the figures reported by framerate measuring programs. I think this is kind of a bogus argument, though, because giving yourself a fake FPS boost by calling Draw without Update is really cheating! If people are trying to measure their game performance using these FPS counters, they have other problems because FPS isn't really a suitable way to measure such things in the first place (that's a whole other topic :-)

2: Waiting is interruptible, but Draw is not. This is the biggie. Consider a game that runs just over 60 fps. Update + Draw completes, and there are a few milliseconds left over, so we call Draw again. Now the timespan expires, but the game is in the middle of Draw, so we have to wait for Draw to complete before we can go back to Update. This could put us significantly behind where we want to be (although always less than an entire frame). The error will be corrected over the next couple of frames as we call Update + Draw in sequence, using the leftover time to make up for what we lost by the extra Draw. There is no actual dropped frame here (we never have to call Update twice in a row without a Draw) but there is a lack of smoothness in our Update calls: we have a biggish gap between two of them, followed by a sequence closer together, then another biggish gap, etc. This is why it would be better to just wait: that way Update can be called at exactly the right time, and will always be perfectly evenly spaced.

Does this actually make a noticeable difference? Probably not. But I'm a perfectionist.

re: Understanding GameTime

zygote — Sat, 28 Jul 2007 15:56:29 GMT

Awesome work as usual Shawn :)

re: Understanding GameTime

X-Tatic — Sat, 28 Jul 2007 17:28:17 GMT

Some good points covered here Shawn. Keep 'em coming, good stuff.

re: Understanding GameTime

Ultrahead — Sat, 28 Jul 2007 21:58:57 GMT

"Running some parts of your update logic less often than others is a great way to make games more efficient. For instance pathfinding and AI often only need to be updated a couple of times a second. Once you have found a good path or made the decision to attack, you can follow that decision without having to repeat the entire original calculation on each update."

Great advice.

re: Understanding GameTime

Zingam — Sun, 29 Jul 2007 00:09:39 GMT

It would be great if you write also about proper performance counters like FPS counter, frame time counter etc... in the context of the above text.

Thank you!

re: Understanding GameTime

Rim — Mon, 30 Jul 2007 10:12:24 GMT

Allow me to respond :)

> 1: This may affect the figures reported by

> framerate measuring programs. I think this is

> kind of a bogus argument, though, because

> giving yourself a fake FPS boost by calling

> Draw without Update is really cheating!

I beg to differ. This may hold true if you knowingly rig your update scheme to do this, but who in their right minds is going to cheat themselves to get a fictive performance boost? The main reasons I like this behavior is:

1. It's predictable

2. It helps budget your draw performance

During development we disable VSync so the drawing runs at max speed and we can get a better idea of how the performance of the rendering code is holding up. By chaining the drawing together with the updating, it seems to me it gets harder to get a straightforward idea of the performance. Yes, yes, you might argue we should profile (and not use the hyperbolically distrubted framerate anyway), but I think a profiler is no excuse for introducing needlessly complex behavior.

> 2: Waiting is interruptible, but Draw is not.

> This is the biggie. Consider a game that runs

> just over 60 fps. Update + Draw completes,

> and there are a few milliseconds left over,

> so we call Draw again. Now the timespan

> expires, but the game is in the middle of

> Draw, so we have to wait for Draw to complete

> before we can go back to Update. This could

> put us significantly behind

True, but isn't this already an unfortunate side-effect of the current smart update/draw scheme? I appreciate the efforts put into XNA to keep the game running smoothly, but at some point you'll have to draw the line and give up on trying to fix unperformant code. It might be a better idea to confront XNA coders straight up when their performance is going down the drain instead of keeping them in the dark with smart tricks until they hit a wall.

> Does this actually make a noticeable

> difference? Probably not. But I'm a

> perfectionist.

Commendable, but why sacrifice transparency and predictability for the sake of unnoticable perfection? :)