Tell me more ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 5 down vote favorite
2

From the MSDN page:

Update and Draw are called at different rates depending on whether IsFixedTimeStep is true or false. If IsFixedTimeStep is false, Update and Draw will be called sequentially as often as possible. If IsFixedTimeStep is true, Update will be called at the interval specified in TargetElapsedTime, while Draw will continue to be called as often as possible.

What is the point of calling Draw potentially more often than Update? Why is Draw not upper-limited to the number of Update calls?

share|improve this question

2 Answers

up vote 4 down vote

Here Shawn Hargreaves talks about GameTime in XNA. This posts was the best explanation of this problem I was able to find when looking into this concept for myself.

share|improve this answer
It is very interesting that Shawn essentially contradicts the text quoted from MSDN when he says, "we call Update, then call Draw, then look at the clock, notice we have some time left over, so wait around twiddling our thumbs until it is time to call Update again". His explanation makes more sense to me, unless XNA can perform interpolation between states, in which case more Draws than Updates might work. – Kylotan Feb 21 at 12:25
1  
You can write your own interpolation in the draw method. Also Shawn does not contradict MSDN, as the default option for XNA is to have IsFixedTimeStep=true :) – Roy T. Feb 21 at 13:53
@RoyT., I'm talking about what Shawn is saying for the IsFixedTimeStep=true case. It's the 3rd or 4th paragraph down in that section. – Kylotan Feb 21 at 16:24
@Kylotan, you're right. I must've misread that. The behavior described on MSDN is true for XNA1,2 and maybe even 3, but in 4 they fixed it as Shawn says on his blog. Maybe they forgot to update MSDN? – Roy T. Feb 21 at 21:00
up vote 2 down vote

After reading the article floAr linked, I also wondered why the author of that article seemed to contradict the MSDN page in places, and I started experimenting on the XNA shooter tutorial a little with the following findings:

  • Draw is called as often as Update if possible, but not more often, contrary to the MSDN statement about fixed time stamp

  • If IsFixedTimeStep == false, then TargetElapsedTime gets ignored as expected, but Update, and therefore Draw, are still capped at the monitor refresh rate and not unlimited as the MSDN page suggests. To get more Update FPS than the monitor refresh rate, you have to disable monitor refresh rate synching or use a fixed time stamp and set the value lower than the default 16.6 milliseconds.

  • By using a StopWatch-controlled empty while-loop, I simulated a very expensive Update method.

    • When IsFixedTimeStep == true and the delay would approach but not surpass TargetElapsedTime (for example delay = 16.1, target = 16.6), the Drawing FPS would rapidly fall behind Update FPS. If the delay was even slightly above the target (e.g. 17.0 and 16.6), the update FPS were as expected by the set delay, but the drawing FPS would go way below that. So not only drawing was slow, there was a disconnect between updating and drawing, which makes for severely lagging gameplay.
    • When IsFixedTimeStep == false, there is no disconnect, because even for large values of delay, the drawing FPS was the same as the update FPS. Both are slow, but they are equally slow.

So in essence, without completely breaking the XNA game loop by calling Draw whenever you feel like it, you can only influence the number of calls per second to Update, and Draw will be called at most once per Update under any circumstances.

share|improve this answer
1  
You also need to disable SynchronizeWithVerticalRetrace on the graphics device manager or you will still be capped at the monitor refresh rate. – dadoo Games Feb 21 at 14:28
1  
The behaviour you describe is set up to work against lagging gameplay. Because Update still triggers with 60 fps your game logic will be stable. As well as draw not beeing called so often your game will get the 'is running slow' flag set. So you can tune down your effects or graphic stuff so your Draw calls can catch up – floAr Feb 21 at 14:42
@dadooGames Thanks, I missed that one. – Hackworth Feb 21 at 14:56
However, even with fixed time stamp and update less than 60 FPS, Draw is still not called more often than Update, contrary to the MSDN statement. Also, why does the monitor refresh rate affect the Update FPS? With synched graphics and no fixed time stamp, update gets called at only 60 FPS. – Hackworth Feb 21 at 14:58
I updated my answer, but most of my findings still stand. – Hackworth Feb 21 at 15:10
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.