Xbox 360 Programming Considerations
The most important graphics consideration for programming for the Xbox 360 console is the wide variety of televisions that the Xbox 360 system supports. The Xbox 360 system supports both HDTV and normal television sets, at multiple resolutions (480p, 720p, 1080i, and 1080p) and multiple aspect ratios (4:3, 16:9, and 16:10). The console will automatically scale the output of a game to the resolution of the owner's display, and if the game is using a widescreen aspect ratio, the console automatically adds "black bars" (letterboxing) if the owner's display is not widescreen.
However, there are still two things XNA Framework programmers should consider when programming for the Xbox 360: the title safe region and aspect ratios.
Title Safe Region
On standard tube televisions, the display area of the television is normally not a perfect rectangle. In fact, a significant amount of the display may not be visible on a CRT tube. In television, the inner 80—90 percent of the picture is considered the "title safe" region. Any graphics displayed outside of this region on a standard television may be obscured or distorted.
Programmers should ensure that any critical information (score, number of lives, ammo, and so on) is displayed within the title safe region, while drawing the background or a 3D scene across the entire display. Critical text should be displayed within the inner 80 percent of the screen. Programmers should also ensure that any text displayed on-screen is large enough to be legible on a standard television.
If the aspect ratio of the back buffer is widescreen and the aspect ratio of the owner's display is not, the Xbox 360 will add black bars at the top of the display so that the entire back buffer is on screen. To avoid letterboxing, developers must program their games to use both standard and widescreen aspect ratios, and adjust their display to the default aspect ratio offered by the Xbox 360. For this reason, a single widescreen back buffer on Xbox games is recommended.
To detect the console display setting, you can use the DisplayMode property on the GraphicsDevice. This will be valid during or after your game's Initialize method. Some common display modes are listed here.
|Xbox Display Setting||DisplayMode Width and Height|
4×AA multisampling is provided for free by the Xbox 360, so using 4×AA multisampling is recommended. Developers should be aware that this will often activate predicated tiling.
Shaders compiled for Xbox 360 will be compiled as Shader 3.0 shaders regardless of the version specified in the effect file. Shaders written for 1.1 may exhibit errors on Xbox 360 if they depended on clamping behavior in 1.1 that is not present in 3.0.
Multiple Render Targets
Render targets function differently on Xbox 360 than on Windows. On Windows, a render target is always a texture in main memory, and is never cleared. On Xbox 360, the current render target is always set to the EDRAM output buffer. On Xbox, calls to SetRenderTarget and ResolveRenderTarget will both clear EDRAM, although ResolveRenderTarget copies the contents of EDRAM to a main memory texture first. For this reason, developers should call ResolveRenderTarget for their current render target before calling SetRenderTarget for a new render target. Developers can avoid problems by rendering fully to each render target before using a new render target, and rendering their final scene after all the other render targets have been resolved.
ResourceUsage flag settings other than ResourceUsage.Tiled and ResourceUsage.Linear have no effect on Xbox 360. You will still get exceptions in Xbox 360 games if you specify ResourceUsage settings that are not valid on Windows. It is recommended that you use ResourceUsage.None on Xbox 360 and Windows whenever possible.
Dynamic Vertex Buffer Usage
Xbox 360 does not support dynamic vertex buffers using the Overwrite/Discard semantic. This effects calls that utilitize DrawPrimitives. DrawPrimitives is recommended at all times on both Xbox 360 and Windows. (The performance benefits of DrawPrimitives on Windows are largely obsolete in newer video drivers.)
The Xbox 360 supports three input devices: the game controller, the Xbox LIVE Vision camera, and an optional USB keyboard. Mice are not supported, and most Xbox 360 users will not have a keyboard connected to their console. The XNA Framework does not support the Vision camera. Games for the Xbox 360 should be programmed so that they will accept all critical input from the gamepad.
XACT audio wave banks, sound banks, and settings files are platform specific. The XNA Framework Content Pipeline will automatically process XACT project files (.xap) into the correct platform type if the project file is added to Solution Explorer. If you are building the XACT project manually, ensure you are using the correct built files for your platform type when you load the built files into your game. Failure to use the correct platform-specific files will result in an error.
Accessing a player's storage on Xbox 360 (to let them save a game, for example) requires displaying the Storage Device Guide, where the user can choose between the hard drive or memory units. The best way to do this is to use the BeginShowStorageDeviceGuide method, as demonstrated in How to: Get a StorageDevice Asynchronously. The largest space available on a memory unit is 52 MB, so any save games must not exceed that size.
The maximum size of an XNA Framework project on an Xbox 360 console is 2 GB, so the entire game, including support files (level data, sound, and so on) must not exceed that size.
Source Code Considerations
Xbox 360 projects define an XBOX symbol for use with conditional compilation directives such as #if. You can use this to maintain source code that acts differently on Windows and Xbox 360 if that source is shared between projects. How to: Draw a Sprite shows an example of conditional compilation where the available screen space is calculated differently for Xbox 360 and Windows.