I must confess, I oversimplified when I labeled the yellow circle in this post as “Windows laptop”. Sure, the Reach profile in XNA Game Studio 4.0 does correspond to what features are widely available across different Windows machines (which makes it valuable even for Windows developers who do not care about other platforms), but this profile also matches the capabilities of Windows Phone 7 Series. The great thing (in fact the reason this whole profiles idea works) is that it turns out the abilities of the phone hardware closely match the baseline Windows feature set.
Things to know:
- The features listed in black are required and supported consistently across all platforms and hardware
- The few features which are not 100% consistent are listed in red
- HiDef is a strict superset of Reach
- If you run a Reach game on a HiDef platform, the framework will still enforce Reach rules. This lets you test your phone game on Xbox 360 or a high end Windows PC, and get helpful exception messages if you accidentally try to use a feature that is not supported on the phone.
With no further ado, here is an overview of the two graphics profiles:
|Supported platforms||Windows Phone 7 Series, Xbox 360, and any Windows PC with a DirectX 9 GPU that supports at least shader model 2.0||Xbox 360, and any Windows PC with a DirectX 10 (or equivalent: see below) GPU|
|Shader model||2.0 (but Windows Phone does not support custom shaders)||3.0+ (Xbox 360 supports custom shader extensions such as vfetch, which are not available on Windows)|
|Max texture size||2048||4096|
|Max cubemap size||512||4096|
|Max volume texture size||Volume textures are not supported||256|
|Non power of two textures||Conditional: cannot use wrap addressing mode, mipmaps, or DXT compression when the size is not a power of two||Yes|
|Non power of two cubemaps||No||Yes|
|Non power of two volume textures||Volume textures are not supported||Yes|
|Max primitives per draw call||65535||1048575|
|Index buffer formats||16 bit||16 and 32 bit|
|Vertex element formats||Color, Byte4, Single, Vector2, Vector3, Vector4, Short2, Short4, NormalizedShort2, NormalizedShort4||All of the Reach formats, plus HalfVector2, HalfVector4|
|Texture formats||Color, Bgr565, Bgra5551, Bgra4444, NormalizedByte2, NormalizedByte4, Dxt1, Dxt3, Dxt5||All of the Reach formats, plus Alpha8, Rg32, Rgba64, Rgba1010102, Single, Vector2, Vector4, HalfSingle, HalfVector2, HalfVector4. Floating point texture formats do not support filtering.|
|Vertex texture formats||Vertex texturing is not supported||Single, Vector2, Vector4, HalfSingle, HalfVector2, HalfVector4|
|Render target formats||Variable (see below)||Variable (see below)|
|Multiple render targets||No||Up to 4. Must all have the same bit depth. Supports alpha blending and independent write masks per rendertarget.|
|Separate alpha blend||No||Yes|
|Blend.SourceAlphaSaturation||Only for SourceBlend, not DestinationBlend||Yes|
|Max vertex streams||16||16|
|Max stream stride||255||255|
When I list the HiDef profile as requiring a DirectX 10 GPU on Windows, I don’t mean that XNA Game Studio 4.0 uses DirectX 10 or 11. It does not: our Windows framework is implemented using DirectX 9. But the HiDef profile requires a GPU with roughly Xbox 360 level capabilities: MRT, floating point surface formats, vertex texture fetch, etc. These are optional caps in DirectX 9, but we need them all to support HiDef (think of it as DirectX 9 turned up to 11). In theory it is possible that a DirectX 9 GPU could support all these caps, just like every DirectX 10 GPU exposes them all when we access it via the DirectX 9 API, but in practice I know of no such DirectX 9 chip. Rather than confusing everybody by saying “HiDef requires this complex set of caps”, it is easier to simplify this to just “HiDef requires a DirectX 10 GPU”. A nice benefit of accessing DirectX 10 hardware via the DirectX 9 API is this means HiDef games can run on Windows XP as well as Vista and Win7.
You will notice that rendertarget format support is still allowed to vary. There were just too many differences in format support for us to successfully standardize this. We have a caps API for querying what formats are available, but more importantly, we have a built-in fallback mechanism. The format parameters used when creating rendertargets and backbuffers have changed from “format” to “preferredFormat”. We will try to give you the exact format you asked for, but if that is not supported, we will automatically fall back to the closest possible match, looking for a format with similar bit depth, number of channels, etc. In most cases this means you can just write code and have it run across different devices without bothering to check caps. For instance if you make a phone game that asks for a Bgr5551 rendertarget, then run this on Xbox where 16 bit rendertargets are not supported, we will automatically switch to Color format instead.
These Game Studio 3.1 vertex element formats are no longer supported by any profile: Rg32, Rgba32, Rgba64, UInt101010, Normalized101010.
These Game Studio 3.1 texture formats are no longer supported by any profile: Dxt2, Dxt4, Bgr555, Bgr444, Bgra2338, Bgr233, Bgr24, Bgr32, Bgra1010102, Rgba32, Rgb32, NormalizedShort2, NormalizedShort4, Luminance8, Luminance16, LuminanceAlpha8, LuminanceAlpha16, Palette8, PaletteAlpha16, NormalizedLuminance16, NormalizedLuminance32, NormalizedAlpha1010102, NormalizedByte2Computed, VideoYuYv, Video UyVy, VideoGrGb, VideoRgBg, Multi2Bgra32.
Some of these formats were removed because they are not supported by enough hardware, or in some cases no hardware at all. Others were removed because they were redundant, as other formats provide the same functionality but with a slightly different bit layout. For instance we no longer have both RGB and BGR versions of the same formats.
Game Studio 4.0 changes the Color type from BGRA to RGBA byte ordering. Most games will never notice the change, as we not only updated the Color struct, but also changed our texture and vertex declaration creation code to match. If you have code that creates Color format textures directly, setting their contents from a byte array rather than a strongly typed Color, you will need to swap the order of your red and blue channels.