The IsFixedTimeStep property controls whether the game attempts to run at a fixed frame rate. If the game runs especially slow, then the frame rate may be reduced or frames may be dropped (this may vary from platform to platform). This property is true by default. If your game is capable of running at a frame rate faster than specified by the TargetElapedTime then the Game class will delay calling Update and Draw to attempt to match the TargetElapsedTime. If your game is not able to run as quickly, the Game class will reduce the number of Draw calls to attempt to allow the Update call to be called more frequently.
By default the XNA template attempts to run the game at a fixed frame rate. To accomplish this, it may reduce the number of times its Draw method is called so that it can keep its Update method called at a fixed frequency. You can turn this behavior off if you are interested in measuring the performance of your game without any artificial throttling. The following code will enable the game to run as fast as possible rather than being capped to 60 fps or the refresh rate of the monitor: Add the following to the Game Constructor
If you are going to change graphics.SynchronizeWithVerticalRetrace after FlatRedBall is initialized, then after changing the property you must call
If IsFixedTimeStep is false, then it is possible that your game may run at a very high frame rate. If your game's frame rate is sufficiently high, it may exceed the sampling rate of the mouse on the PC. In this situation, you may receive updates where multiple frames in a row report the same position values. This can be problematic if you are using any of the Cursor's Velocity values. You may have many frames where the reported velocity is 0 (due to the position being the same for mutliple frames) even if the user is moving the cursor. This is mostly problematic in situations where the Velocity of the Cursor can impact game behavior - such as with logic that performs kinetic scrolling.
IsMouseVisible can be set to true to display the mouse cursor. This value defaults to false which means the mouse will be invisible when it is over the game window.
The following code shows how to make the mouse cursor visible. It assumes the code is written in Game1.cs, so it uses "this":
If not in the Game1.cs, this can be accessed through FlatRedBallServices:
The IsActive property can tell you if the Game window has focus. This is useful if you are building applications or games which you do not want to receive input if the window is not in focus. For example, if a Game is behind another Window, but the game responds to mouse clicks, the game will receive the mouse clicks by default. To prevent this, an IsActive check can be made.
The follow code can prevent a particular method from running by performing an "early out" on the code.
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.
The following code will tell the game logic to run at 10 frames per second:
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:
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.
With the frame rate adjustment code commented (not used): With the frame rate adjustment code used:
Base class for class used in default XNA Template and FlatRedBall XNA Template.
The Game class holds many useful methods and properties which are often needed deep inside game logic code where the Game reference is not available. The FlatRedBallServices class provides a reference to the game class:
For example, to view the mouse cursor (as shown below) outside of the game class, you would use the following code:
Since FlatRedBallServices is static this can be used anywhere in code.
The resolution of FlatRedBall is controlled through the GraphicsOptions object. For more informatin, see the GraphicsOptions page.
FlatRedBall will attempt to react to the window changing as a result of the user grabbing and dragging the corners or edges. The following code can be called in the Game class to enable resizing:
FlatRedBall applications can run in full screen mode. The following code (which must be called after FlatRedBall is initialized) will set the FlatRedBall application to run at full screen.
When FlatRedBall is in fullscreen mode, it "owns" the graphics device. This means that nothing else will be drawing underneath the Window. This can improve performance, but also makes alt-tabbing slower, and now other Windows can be drawn on top of the Window. For this code to work, you must include a reference to the System.Windows.Forms library in your project's References folder. You can sacrifice performance for this convenience by simply maximizing the game as follows: Add the following using statement:
Add the following to Initialize after initializing FlatRedBall:
The Exit method ends the application. This can be called to exit the game as follows: If inside the Game class:
If the Game class is not in scope:
This can be called at any point and your game will exit properly.
For more information, see the IsFixedTimeStep page.
Game Window as a Control - FlatRedBallService's Owner property returns the game window as a Control which provides more functionality.
Did this article leave any questions unanswered? Post any question in our forums for a rapid response.