Reach vs. HiDef

Reach vs. HiDef

  • Comments 64

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:

 

Reach

HiDef

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.
Occlusion queries No Yes
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.

  • Texture3D no longer supports DXT formats

  • Texture3D never supported DXT compression, in any version of XNA.  Or any version of D3D9, for that matter.

  • Why!!!

  • Hi we have a game soon to be release (www.xtractordefender.com) the game install correctly on our 4 years old computer with  good (middle range) video card . We tested on computers and laptop with onboard video adpter and most of the failed. Our game is an ISO 2D and we used 4096X4096 graphic capabilty of the Hidef profile. We are thinking now to cut our graphic in half and go with the reach profile . Any thoughts would be appreciated.

    THX

Page 5 of 5 (64 items) 12345
Leave a Comment
  • Please add 8 and 7 and type the answer here:
  • Post