TargetElapsedTime
Introduction
The TargetElapsedTime member allows you to control the update frame rate of your game. This value controls how often the Update method is called. It does not control how frequently your game is rendered to the screen.. In other words, if your game is rendering at 60 frames per second, but you modify this value so that your game runs at 120 frames per second, that will result in the Game's Update call being executed 120 frames per second, but your game will still render at 60 frames per second. In short, your game's Update and Draw methods can run at different rates.
Code Example
The following code will tell the game logic to run at 10 frames per second:
Fixing collision tunneling with higher frame rate
As explained in this article, tunneling occurs when the speed of a moving object is large relative to objects it is colliding against. More accurately, tunneling occurs when the amount of distance an object travels in one frame is large relative to the objects it is colliding against. By increasing the frame rate of your game, you can reduce the distance covered by an object per-frame. The following example presents a situation where a lot of tunneling is occurring, then shows how increasing the frame rate can solve this problem:
Add the following using statements:
Add the following at class scope:
Add the following to Initialize after initializing FlatRedBall:
Add the following to Update:
With the frame rate adjustment code commented (not used): With the frame rate adjustment code used:
TargetElapsedTime and performance
While adjusting this value may seem like an effective way to solve tunneling, doing so can be dangerous. The reason for this is because reducing the TargetElapsedTime makes the game attempt to run at a higher frame rate. This means your entire update logic (all live Screens and Entities and FlatRedBall objects) will be run more frequently.
The default value for TargetElapsedTime is approximately 16 milliseconds (60 frames per second). Reducing it to 2 as we do above essentially makes your game require 8X as much processing power per frame. Or another way to look at it is that your game is 1/8 as efficient per draw call (excluding the draw calls themselves). As you can probably imagine, this is a very expensive approach to solving tunneling. But we present it here as it may be a requirement if your game needs a high degree of accuracy in its physics.
Last updated