Jump to content

  • Log In with Google      Sign In   
  • Create Account


Update vs Draw 1 to 1?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 NEXUSKill   Members   -  Reputation: 453

Like
0Likes
Like

Posted 18 January 2011 - 10:48 AM

As far as I've read the book, it says that draw will be called immediately after update, which suggests a relationship of 1 to 1 between update and draw calls.

However simple testing has proven this to be false, if you place a trace line in both update and draw calls in the platformer demo, you will find that in a fast computer, this relationship tends to be between 3 and 2 to 1.

Of course a trace instruction run on every update and draw is on itself dropping down performance, since text print operations tend to be very time consuming, but the point is proven just the same, there is not a direct relationship between update and draw calls.

My question comes to the GameTime values, what time interval is it really being measured? is it time between updates? what relevance is in the game time parameter received in the draw call?

Would it be possible to track update intervals and draw intervals separately? to for instance update the progression of strictly graphic animations (animations that have no impact on logic) only on draw calls reducing the cost of update and leaving it for other more critical tasks?

What are the specific changes of IsFixedTimeStep and SynchronizeWithVerticalRetrace separately and in combination?


Game making is godlike

LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272



Sponsor:

#2 JWalsh   Moderators   -  Reputation: 462

Like
1Likes
Like

Posted 18 January 2011 - 12:33 PM

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!
Jeromy Walsh
Sr. Tools & Engine Programmer | Software Engineer
Microsoft Windows Phone Team
GameDevelopedia.com - Blog & Tutorials
GDNet Mentoring: XNA Workshop | C# Workshop | C++ Workshop
"The question is not how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?" - Il Duche, Boondock Saints

#3 NEXUSKill   Members   -  Reputation: 453

Like
0Likes
Like

Posted 18 January 2011 - 01:18 PM

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"


Game making is godlike

LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272



#4 JSelf   Members   -  Reputation: 102

Like
0Likes
Like

Posted 18 January 2011 - 11:55 PM

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!

#5 JWalsh   Moderators   -  Reputation: 462

Like
1Likes
Like

Posted 19 January 2011 - 11:52 AM

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!
Jeromy Walsh
Sr. Tools & Engine Programmer | Software Engineer
Microsoft Windows Phone Team
GameDevelopedia.com - Blog & Tutorials
GDNet Mentoring: XNA Workshop | C# Workshop | C++ Workshop
"The question is not how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?" - Il Duche, Boondock Saints

#6 JWalsh   Moderators   -  Reputation: 462

Like
0Likes
Like

Posted 19 January 2011 - 11:56 AM

...

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.
Jeromy Walsh
Sr. Tools & Engine Programmer | Software Engineer
Microsoft Windows Phone Team
GameDevelopedia.com - Blog & Tutorials
GDNet Mentoring: XNA Workshop | C# Workshop | C++ Workshop
"The question is not how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?" - Il Duche, Boondock Saints

#7 NEXUSKill   Members   -  Reputation: 453

Like
0Likes
Like

Posted 21 January 2011 - 09:15 AM

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?


Game making is godlike

LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272



#8 JWalsh   Moderators   -  Reputation: 462

Like
0Likes
Like

Posted 23 January 2011 - 05:43 PM

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.
Jeromy Walsh
Sr. Tools & Engine Programmer | Software Engineer
Microsoft Windows Phone Team
GameDevelopedia.com - Blog & Tutorials
GDNet Mentoring: XNA Workshop | C# Workshop | C++ Workshop
"The question is not how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?" - Il Duche, Boondock Saints

#9 NEXUSKill   Members   -  Reputation: 453

Like
0Likes
Like

Posted 24 January 2011 - 08:31 AM

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.


Game making is godlike

LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272



#10 JWalsh   Moderators   -  Reputation: 462

Like
1Likes
Like

Posted 24 January 2011 - 09:40 AM

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.
Jeromy Walsh
Sr. Tools & Engine Programmer | Software Engineer
Microsoft Windows Phone Team
GameDevelopedia.com - Blog & Tutorials
GDNet Mentoring: XNA Workshop | C# Workshop | C++ Workshop
"The question is not how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?" - Il Duche, Boondock Saints

#11 superkent   Members   -  Reputation: 158

Like
0Likes
Like

Posted 24 January 2011 - 10:35 AM

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?

#12 pothb   Members   -  Reputation: 100

Like
0Likes
Like

Posted 24 January 2011 - 11:05 AM

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?

#13 NEXUSKill   Members   -  Reputation: 453

Like
0Likes
Like

Posted 28 January 2011 - 01:03 PM

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.


Game making is godlike

LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS