Xna when is draw called

Sign up using Facebook. Sign up using Email and Password. Post as a guest Name. Email Required, but never shown.

The Overflow Blog. Does ES6 make JavaScript frameworks obsolete? Podcast Do polyglots have an edge when it comes to mastering programming Featured on Meta. Now live: A fully responsive profile. Related 3. Hot Network Questions. Question feed. Stack Overflow works best with JavaScript enabled. Accept all cookies Customize settings. If you noticed, the parameter to the Update method is the GameTime. The GameTime object has three properties that you can use.

First, it has the ElapsedGameTime, which is the amount of time that has passed since the last call to Update. It also includes TotalGameTime, which is the amount of time that has passed since the game has started.

Finally, it includes IsRunningSlowly, which is only important in fixed time step mode. During variable time step mode, the amount of time recorded in ElapsedGameTime passed to update can change depending on how long the frame actually takes hence, the name "variable" time step. Fixed time step is different. Every call to Update has the same elapsed time hence, it is "fixed". It is also different from variable time step in the potential order of Update and Draw calls.

While in variable time step, you get one update for every draw call; in fixed time step, you potentially get numerous Update calls in between each Draw. Update is called as many times as necessary to catch up to the current time. For example, if your TargetElapsedTime is Draw is then called. At the end of any Draw, if it is not time for an Update to occur, the framework waits until it is time for the next Update before continuing.

If at any time, the runtime detects things are going too slow for example, you need to call Update multiple times to catch up , it sets the IsRunningSlowly property to true.

This gives the game the opportunity to do things to run faster such as rendering less or doing fewer calculations. When this happens, it assumes it cannot catch up, resets the elapsed time, and starts executing as normal again. If you paused in the debugger, things should just start working normally.

You can also reset the elapsed time yourself if you know you are going to run a long operation, such as loading a level or what have you.

Notice that in Windows Phone 7 projects, the new project instead sets the TargetElapsedTime to 30 frames per second, rather than the 60 used on Windows and Xbox This is done to save battery power, among other reasons. Ideally, update would run faster as it would allow for AI, physics and controller processing to be run at the highest possible speeds.

If your system is set to run with Draw having a faster update then it needs some changes I suggest you go have a word with the guys writing Forza 2, they will talk about Updating physics and AI calculations at over frames a second whilst Drawing the screen at 60 frames per second.

I'm sorry Mitch but to correct you, you would never. Deis wrote: Why on earth would you want to update your physics and AI that much per second? The average human can see changes at 30 to 40 frames per second.

There is absolutely no reason to update logic beyond 60 times per second. And there is no issue with efficiency when drawing more than 60 frames per second. I suggest you chat to the simulation people, i. AI and physics isn't just related to what you can see. As in the real world, there are plenty of things happening between the changes you see.

You think a digital clock only processes events when the seconds change? People get too tied up in a change meaning something different appearing on screen, that's not the case in game physics and AI. There are cumulative events that generate a final outcome that is then displayed for the player to see.

If you tie your physics and AI into the update rate of the Draw function, then you have to make sure that your AI and physics can complete their task within the time it takes between Draw functions.

Peter Mackay wrote: While this is often the case, some people actually prefer to tween the frames drawn between the last 2 updated frames, giving smooth rendering regardless of update rate, and smooth updates regardless of rendering rate. And how would they calculate the tweens between Draws if they didn't use an Update to calculate the tweened positions? Peter Mackay wrote: I suspect this is one of those religious issues which people will never agree on, but I just wanted to make the case for separate update and draw rates.

You mean like my line that says LeeC22 wrote: If you tie your physics and AI into the update rate of the Draw function, then you have to make sure that your AI and physics can complete their task within the time it takes between Draw functions. That made sense when I thought it but after I posted it didn't appear as I thought it I would have edited the post but You should setup all the starting points in a method called from OnStart method.

It is easily solved by putting a boolean flag in the Draw that starts false and then gets set to True in the update. Horses for courses as they say I guess as they say, the other stuff is another story and best left for another, more relevant thread. It would be extremely helpful if someone said the described behavior is intended or not preferably pointed to a documentation or a post somewhere.

Please keep in mind you're not obligated to answer and that I'm simply throwing this out there to see if there's someone who really does know. The vast majority of my findings come from development of a small game that I did together with a friend. What is amusing, doing backend web development professionally yields both positive and negative practices when developing MonoGame and XNA applications.

Some practices should be avoided, others are welcome. I will elaborate on these all topics when discussing the particular issues. Please share in the comments down below your own findings!

One important thing to understand is that it is necessary to profile before applying any optimization. Profile your code and find the culprit. One unfortunate fact that comes from some optimizations is less readable code. Regrettably, writing clean nice code often works against achieving good performance. My approach towards this problem is: optimize only where necessary. I prefer to have a cleaner code than to get a fraction of second where it is not necessary.

When discussing each possibility, I will provide information when and if it should be used. So, without further ado, this first post will concern Draw calls. The second post will touch Update calls, and the last one some common good practices as well as lower level optimizations. In vast majority of XNA and MonoGame tutorials, you will notice that the parameters for drawing are set by using strings. As a result such code is quite common:.

While this code works perfectly well and it is suitable for tutorials, it is not a good practice to pass the drawing parameters by string. This has a significant penalty on CPU performance. Therefore, this code shall be refactored:.