IT tutorials
 
Mobile
 

Windows Phone 7 : Getting Started with XNA - Other Graphics Options

2/25/2013 6:23:28 PM
- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire

We've now covered most of the fundamental options available for 2D rendering, but there are a few important details still left to look at, so let's run through these now.

1. Rendering in Full Screen Mode

All the examples so far have operated in so-called windowed mode, which in the context of Windows Phone simply means that the status bar is visible at the top of the screen. In many instances users may prefer to have this available because it gives them a window into the phone: they can see their battery level, their signal reception level, and so on. Some games may benefit from having the game run in full screen mode, however, with this bar hidden. It is usually polite to offer a configuration option so that this mode can be configured per user preference.

Setting full screen mode is easy; just add the line of code shown in Listing 1 to your Game class's constructor:

Example 1. Starting up in full screen mode
// Set the graphics device manager into full screen mode
        _graphics.IsFullScreen = true;

If you wish to change the full screen state of your game at a later time, the easiest way is to call the GraphicsDeviceManager's ToggleFullScreen method. You can check the current state at any time by reading back the IsFullScreen property value.

2. Supporting Portrait and Landscape Orientations

This is the orientation that the user is likely to be using for general-purpose interaction with the device, and if your game works well in this orientation it is a good idea to allow your game to run in this arrangement.

If your game would benefit from a landscape orientation, however, this is easy to implement. In fact, the default behavior of XNA is to present the game in landscape mode.

Windows Phone 7 devices have special hardware present to support orientation, which means that they cost absolutely no processing time whatsoever.

Let's look at the options for supporting different orientations within your games.

2.1. Using Portrait Orientation

To set a game to run in portrait mode, we can set the width and height of the back buffer in the game class constructor so that its height is greater than its width. We can set the width to 480 and the height to 800 to match the device resolution, as shown in Listing 2.

Example 2. Setting the back buffer for portrait orientation
// Display using portrait orientation
        _graphics.PreferredBackBufferWidth = 480;
        _graphics.PreferredBackBufferHeight = 800;

With this configuration active, the game will always appear in portrait mode, regardless of how the device is physically rotated. You can test rotation on the emulator by clicking the rotate buttons that appear to the right of the device window and see how the graphics on the screen respond. With the game running in portrait mode, the graphics will display sideways when the device is in a landscape orientation.

You can see this in effect by running the Orientation sample project. This also displays the name of the orientation that the device is currently using, the size of the back buffer, and the size of the game window. Notice that they do not change when the device is rotated.

2.2. Using Landscape Orientation

To operate your game in landscape orientation, don't specify any preferred back buffer size in the class constructor; the game will default to landscape mode. Try commenting out the back buffer configuration in the Orientation project and run it to see the results.

If you leave the device or the emulator in portrait orientation, the display will appear sideways because the game is now supporting only landscape orientations. Note that if you switch the device over between being rotated to the left and to the right, it automatically rotates the screen content to match. The Current orientation display from the program will switch between LandscapeLeft and LandscapeRight as you do this.

The game itself doesn't need to know anything about such a rotation because the screen size is absolutely unchanged.

2.3. Allowing Landscape and Portrait Orientations

You may wish to support your game in both landscape and portrait orientations. Doing so is easy to accomplish from the point of view of the phone, but may introduce additional work into your game because you will probably need to resize or reposition your game elements to fit into the new window dimensions.

To enable all possible orientations, comment out the code that sets the preferred back buffer size and replace it with the code shown in Listing 3.

Example 3. Allowing landscape and portrait orientations
// Allow portrait and both landscape rotations
        _graphics.SupportedOrientations = DisplayOrientation.Portrait |
                                DisplayOrientation.LandscapeLeft |
                                DisplayOrientation.LandscapeRight;

If you run the project now, you will find that it automatically adjusts to whatever orientation the device is held in.

One important point is the way that the Window size and Back buffer size values are reported by the example project. The window size remains completely unaffected by the rotation because at heart the device is always operating in portrait mode, so this is the size that it considers its window to be. The back buffer size (retrieved from the BackBufferWidth and BackBufferHeight properties of the _graphics.GraphicsDevice.PresentationParameters object) always reflects the dimensions of the window as it is actually being rendered. If you are supporting rotation, be careful to read the buffer size in the correct way.

You can, of course, provide any set of orientations that you wish for the SupportedOrientations property. Setting it to just DisplayOrientation.LandscapeLeft would prevent portrait or landscape-right orientations from being displayed. Generally if you are allowing landscape orientation, you should allow both modes so that users can hold the device in whichever way they are comfortable with.

To change the supported orientations after the game has started, set the SupportedOrientations property as needed and then call the _graphics.ApplyChanges method. The updated orientations will become immediately effective.

If you need to detect the orientation changing so that you can update your game accordingly, the easiest way to do it is to subscribe to the game window's OrientationChanged event. This is fired each time the orientation changes, and the new orientation can be retrieved from the Window.CurrentOrientation property. The Orientation example project uses this event to display the new orientation to the debug window each time it changes.

3. Graphic Scaling

Compared with modern game consoles, Windows Phone 7 devices are fairly low-powered in terms of graphical capability, despite the hardware that they have at their disposal. Yet they still run at a fairly high resolution: 480 × 800 pixels is a substantial amount of screen data to update.

In many cases, the hardware will be entirely capable of handling this, but when the graphic updates are more intense the phone may struggle. To assist with this scenario, the device has a hardware image scaler built in, which enables XNA to render at any size that it likes, allowing the scaler to increase the size of the rendered graphics so that they fill the screen. Just as with rotation, special hardware is present to perform this task, so it takes no processor time whatsoever. The scaler smoothes the graphics as it processes them, so it avoids displaying pixelated graphics. The scaler is particularly effective with fast-moving graphics, which further helps to disguise the scaling that is taking place.

To use the scaler, we just set the preferred back buffer size in the game constructor to whatever size we need. If the game is running in portrait mode, we can scale everything to twice its size by using the code shown in Listing 4. Note that the size provided here is exactly half the actual screen size. This means that we can render into the screen area 240 pixels wide by 400 pixels high (instead of the normal 480 × 800 pixels) and still have it fill the screen. This is one-quarter of the volume of pixels, resulting in a lot less work for the device to do.

Example 4. Double-size scaling in portrait mode
// Scale up by 2x
        _graphics.PreferredBackBufferWidth = 240;
        _graphics.PreferredBackBufferHeight = 400;

If your game is using landscape mode, set the preferred back buffer size so that the width is greater than the height, as shown in Listing 5. This is the correct approach if using both landscape and portrait modes via the SupportedOrientations property too: XNA will automatically swap the back buffer width and height when switching into portrait mode, so always provide the buffer size with the dimensions that will be used for the landscape display orientation.

Example 5. Double-size scaling in landscape mode
// Scale up by 2x
        _graphics.PreferredBackBufferWidth = 400;
        _graphics.PreferredBackBufferHeight = 240;

The scaler can also work with smaller resolutions than this if desired, but the more dramatic the scaling, the more pixelated and distorted the final image will be.

To change the scaling after the game has started, set the preferred back buffer size as required, just as we have seen in the constructor, and then call the _graphics.ApplyChanges method. The scaler will immediately start or stop work as required.

4. Suppressing Drawing

The update/draw loop that XNA employs is generally very good for presenting a game to the screen and offers great opportunities for rich-looking graphic updates. But sometimes the graphics being drawn to the screen aren't actually moving at all. XNA is unaware of this, however, and continues to clear and repaint the same identical scene frame after frame, using the CPU and graphics hardware in the process and wasting the battery as a result.

These is, however, a way to indicate to XNA that it doesn't need to redraw the screen and can just re-present the most recently drawn screen. This is achieved simply by calling the Game class's SuppressDraw method from within the Update function.

A simple approach to managing this is to create a bool variable within Update called objectsMoved, initially set to false. As soon as your Update code causes anything to happen that needs the screen to be redrawn, it sets this variable to true. At the end of the function, the code can then check this variable and call SuppressDraw if it still contains its initial false value.

 
Others
 
- iPad : Your Calendar - Adding New Calendar Appointments, Events (part 2)
- iPad : Your Calendar - Adding New Calendar Appointments, Events (part 1)
- Java ME on Symbian OS : Handling Diversity - Using Adaptive Code and Flexible Design to Handle Diversity
- Java ME on Symbian OS : Handling Diversity - Detecting Diversity using Properties
- BlackBerry Bold 9700 and 9650 Series : Email Set Up - Sync Google Contacts Using Email Setup
- BlackBerry Bold 9700 and 9650 Series : Email Set Up - Maintaining Your Email Accounts
- iPhone Programming : Other Native Platforms - MonoTouch
- iPhone Programming : Other Native Platforms - PhoneGap
- Windows Phone 8 : Phone-Specific Controls (part 2) - Pivot Control
- Windows Phone 8 : Phone-Specific Controls (part 1) - Panorama Control
 
 
Top 10
 
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
programming4us programming4us
 
Popular tags
 
Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS