Update vs Draw 1 to 1?

Hi Andres, thanks for posting your question. Here's the answer....

XNA's Game API can run in either of two modes - Fixed Step and Variable Step. In a Fixed Step Game (Game.IsFixedStep = true) you're guaranteed to maintain a consistent update rate. This means that if you're running your game on a super fast computer, it will actually wait until a target elapsed time (Game.TargetElapsedTime) has passed before calling update. On the other hand, if your computer is running slowly (less than the target elapsed time between updates) your XNA game will actually call Update multiple times (while skipping the draw calls) in order to "catch up" with the clock. So in a fixed step game it's possible to have multiple Update calls between draw calls.

One of the caveats of this is that if it's your Update call, not your Draw call which is causing your game to run slowly, then trying to call Update multiple times in between Draw calls will actually make the performance worse! That's why the Game class also has a nifty function called ResetElapsedTime(). This tells your Game to essentially ignore the fact that it had been running slowly, and to not try and catch up with the lost Updates. This is useful after a loading screen or particularly long Update when you actually don't want to pick up those lost frames.

The other caveat to this is if you run your game in windows mode and take the focus away from the game, it will actually sleep a bit in order to yield CPU power over to other applications. If you're running in FixedStepMode this can sometimes cause your game to run at less than the target elapsed time, thus forcing multiple Update calls in between Draw calls.

In a Variable Step game your Game class makes no attempt to maintain the frame rate. There is a one-to-one ratio between Update calls and Draw calls. With that said I want to point out one thing - While Update is only called from the Game's internal Tick() method, Draw is called both during the end of Tick() and also in response to Windows Paint messages. Paint messages can be invoked on your window for a number of different reasons, so depending on your situation you may see multiple Draw calls for a single Update. This doesn't mean your main game loop is calling Draw multiple times, it means your main game loop is calling Draw once, and then Windows is invoking it again.

If you're seeing behavior other than what I descried above feel free to provide a link to your source code and we can check it out.

In response to SynchronizeWithVerticalRetrace, this little flag tells your driver not to push data to the GPU until the next vertical retrace. Historically, the vertical retrace referred to your CRT monitor's cathode ray, which took a bit of time to get from the bottom right corner of the screen back to the top left. If you pushed data to the frame buffer while your ray was half-way down the screen then you could actually have different images appearing on the top and bottom half of the screen. This was called tearing, because it looked like your screen was being torn in half. So by synchronizing the driver with your monitor's refresh rate you could avoid this problem, as data would be copied to the frame buffer while the ray was moving from the bottom to the top of the screen. On the other hand, it also meant you could never have more frames per second than your display device's refresh rate - usually between 60 and 80 cycles per second.

With the invention of LCD monitors, double buffering, the separation of video memory from the frame buffer, and better drivers this problem seems to have largely been eradicated. Even if your game is running faster than your monitor's refresh rate there is still rarely tearing seen on the PC. On other platforms (like the PS3) this can still be a problem. By convention we typically leave synch with vertical retrace enabled because we do not know what type of signal or display device the user will have, or whether their video card or drivers will properly handle data being pushed to the frame buffer during a draw cycle. But, in order to determine your maximum "possible" frames per second, you'll need to disable vertical retrace as it still clamps your frame rate to your display device's refresh rate.

Cheers!

Most of what you just said I already knew, besides of the nifty little trick of the reset elapsed time.

However, the doubt that was a thorn in my mind was more centered on the values of GameTime, what its values represent when received on update and what they represent when received on draw.

As for large loading I would expect to do that asynchronous and have the main thread updating some animation, so that wouldn't technically be "running slow"

In a Variable Step game your Game class makes no attempt to maintain the frame rate. There is a one-to-one ratio between Update calls and Draw calls. With that said I want to point out one thing - While Update is only called from the Game's internal Tick() method, Draw is called both during the end of Tick() and also in response to Windows Paint messages. Paint messages can be invoked on your window for a number of different reasons, so depending on your situation you may see multiple Draw calls for a single Update. This doesn't mean your main game loop is calling Draw multiple times, it means your main game loop is calling Draw once, and then Windows is invoking it again.

Does this pertain to fullscreen mode as well?

Paint messages can be invoked on your window for a number of different reasons, so depending on your situation you may see multiple Draw calls for a single Update.

Would you mind giving a couple of examples?

Thanks!

Most of what you just said I already knew, besides of the nifty little trick of the reset elapsed time.

However, the doubt that was a thorn in my mind was more centered on the values of GameTime, what its values represent when received on update and what they represent when received on draw.

As for large loading I would expect to do that asynchronous and have the main thread updating some animation, so that wouldn't technically be "running slow"

Hi NEXUS,

In response to the values of GameTime, it again depends on whether you're in fixed step or variable step mode.

If you're in FixedStep, the ElapsedGameTime in Update is always equal to the TargetElapsedTime, and TotalGameTime is always a multiple of TargetElapsedTime, depending on how many update cycles your game has ran for. In other words, it's UpdateCount * TargetElapsedTime.

In FixedStep, the ElapsedGameTime in Draw is equal to the TargetElapsedTime multiplied by the number of Updates were called since the last Draw. Generally speaking there will only be one update per Draw unless your game is performing poorly, in which case the ElapsedGameTime is the same for both Update and Draw. On the other hand TotalGameTime in Draw is always TargetElapsedTime greater than the most recent Update. Perhaps it's best to show an example:


Processing Update; Elapsed Game Time:00:00:00.0166667; Total Game Time:00:00:00
Processing Draw; Elapsed Game Time:00:00:00.0166667; Total Game Time:00:00:00.0166667
Processing Update; Elapsed Game Time:00:00:00.0166667; Total Game Time:00:00:00.0166667
Processing Draw; Elapsed Game Time:00:00:00.0166667; Total Game Time:00:00:00.0333334
Processing Update; Elapsed Game Time:00:00:00.0166667; Total Game Time:00:00:00.0333334
Processing Draw; Elapsed Game Time:00:00:00.0166667; Total Game Time:00:00:00.0500001
Processing Update; Elapsed Game Time:00:00:00.0166667; Total Game Time:00:00:00.0500001
Processing Update; Elapsed Game Time:00:00:00.0166667; Total Game Time:00:00:00.0666668
Processing Draw; Elapsed Game Time:00:00:00.0333334; Total Game Time:00:00:00.0833335

Notice in the previous example in the first Update cycle the ElapsedGameTime is coded to always receive the TargetElapsedTime, but TotalGameTime receives the correct value of 0, as no GameTime has elapsed, since the stop watch was just triggered at the beginning of this Update. Notice also that Draw's ElapsedGameTime receives the same coded value, however Draw's TotalGameTime receives .016667 because the TotalGameTime += TargetElapsedTime * NumUpdates is executed after all Updates are called but before the Draw call. This carries over to the next Update where the TotalGameTime of Update is the same as the previous Draw.

Notice how the previous description of the timing behavior is the same in the following example of the variable time-step game, with the exception that values are now no longer coded to always be the TargetElapsedTime:


Processing Update; Elapsed Game Time:00:00:00.0129736; Total Game Time:00:00:00
Processing Draw; Elapsed Game Time:00:00:00.0129736; Total Game Time:00:00:00.0129736
Processing Update; Elapsed Game Time:00:00:00.0091097; Total Game Time:00:00:00.0129736
Processing Draw; Elapsed Game Time:00:00:00.0091097; Total Game Time:00:00:00.0220833

As with before, Update's TotalGameTime is always one update behind, and Draw's ElapsedGameTime is always the same as Update's.

Cheers!

...

Does this pertain to fullscreen mode as well?
...

Would you mind giving a couple of examples?

Thanks!

Hi JSelf, in Fullscreen the timing system is still the same, however the game does not receive additional Paint messages from the OS. This is because, as you asked in your second question, the OS sends a Window's Paint message whenever a window is either maximized, restored, or when part of the window becomes invalidated and needs to be re-drawn. This most frequently happens when you resize the window or if it's covered by part of another window and then revealed again. As none of these can happen in full-screen mode, this is no longer a problem.

One more question, as for this 1 to 1 relationship, is it something to aim to? wouldn't a game feel better in an N to 1 relationship with N > 1 and as high as possible while keeping draw in sync with the monitor refresh rate?

Wouldn't the best result be delivered by N upd to 1 drw to 1 screen refresh?

One more question, as for this 1 to 1 relationship, is it something to aim to? wouldn't a game feel better in an N to 1 relationship with N > 1 and as high as possible while keeping draw in sync with the monitor refresh rate?

Wouldn't the best result be delivered by N upd to 1 drw to 1 screen refresh?

The best scenario is as many updates and draw cycles as possible per second. It really doesn't provide any benefit to have multiple updates within a single draw cycle, except to make sure your game stays in sync. On the other hand, drawing the screen multiple times per update is unnecessary, as you're just drawing the same thing over and over again.

So yeah, the goal is to have a 1:1 relationship between update and draw, and to have as many of those as possible.

It really doesn't provide any benefit to have multiple updates within a single draw cycle

I was under the impression that while drawing faster than the refresh rate does not offer any improvements, updating as much as possible in some cases can help create a much more accurate simulation, like the sampling frequence of a discrete audio file like mp3, the more samles you have within the same time frame, the more "continuous" the simulation is.

I was under the impression that while drawing faster than the refresh rate does not offer any improvements, updating as much as possible in some cases can help create a much more accurate simulation, like the sampling frequence of a discrete audio file like mp3, the more samles you have within the same time frame, the more "continuous" the simulation is.

Hi Nexus,

When working with curve-fitting systems such as physics interpolation it can be beneficial to update more frequently than the refresh rate (with vsync enabled this can lead to a more accurate simulation), however the benefits are generally not significant, especially when one considers that such an implementation requires multi-threading or updating certain components multiple times within a single input/draw loop. Keep in mind also that all games are ultimately about three things - input, processing, and display. While having a more accurate simulation is great, it doesn't help a lot if the player can still only see the screen and respond 60 times per second. Stated differently - multiple, isolated updates is only beneficial to components that do not require player input.

Another important item to consider is that often times, as is the case with physics interpolation, consistent updates is more important than frequent updates. So even if you were performing your physics in a separate thread or multiple times within a draw loop, you'd still want to make sure it was happening at even intervals.

So in general, if you can get the input, processing, and draw loop to execute more times per second that's great. But any of the three by themselves operating faster than the rest will provide only marginal benefits. Assuming your simulation was fairly accurate to begin with, having multiple updates just means more samples along the curve without providing any additional opportunities for the player to see or respond to the changes.

Though I don't have any experience, I have read that updating physics systems too quickly can cause floating point errors and erratic behavior, is this true?

Though having more updates than draw isn't necessarily a bad thing, as far as I can tell... isn't it still best to have a 1:1 relationship? With N:1 it would mean that the graphics can't catch up, and with 1:N it would be drawing the same scene too many times.

How would it be marginally better if one is faster than the other unless the drawing can't catch up?

Though having more updates than draw isn't necessarily a bad thing, as far as I can tell... isn't it still best to have a 1:1 relationship? With N:1 it would mean that the graphics can't catch up, and with 1:N it would be drawing the same scene too many times.

How would it be marginally better if one is faster than the other unless the drawing can't catch up?

The idea behind wondering if N:1 would be better is that update is basically taking frozen samples to simulate something that should be continuous, therefore, the more samples you take, the more the result resembles the real values it is simulating. Think of it like an MP3 file, audio is a continuous wave, MP3 stores music by taking samples of the wave with a given frequency, to save space, the less samples it takes, the less quality the audio file will have, because it resembles less the original audio wave.


However I had not considered floating point error accumulation, that could be an issue, although I would expect a good physics engine to have some countermeasure to that built in.