Reach vs. HiDef


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.


Comments (64)

  1. David Black says:

    Those HiDef requirements seem a little wide in places. In particular texture/vertex formats. My 9800GT does not support a bunch of them(or recent drivers dont expose them).

    eg the 10 10 10 2 texture format or the Short/NormalizedShort(not sure which) vertex format.

    I guess ATI DX10 cards are a little more fully featured…

  2. ColesyM says:

    Summary:

    Use power of 2 textures or you will lose mip-mapping, wrapping textures, or any DXT compression.

    Smaller draw batch sizes (16bit).

    No floating point textures, No Multiple Render Targets, No Occlusion Queries.

    No separate alpha blend (this will probably trip a lot of people up with their ’tile engines’.

    Vastly trimmed down texture format list.

    Re-arranged Color byte packing (this will trip up people who do SetData on setup, which seems like a lot).

  3. Tom Gillen says:

    So the existing caps API is still there?

    Also, as the HiDef profile is ‘Dx10-like’, and not strictly Dx10 hardware, I cannot use HiDef and assume the hardware can do fp alpha blending on windows?

  4. WaaghMan says:

    I suppose that Multisampling issupported only in HiDef, but it’s not mentioned. Will it be supported also on Reach?

  5. if all those feutures are not supported by the phone , well is not a Nvidia Tegra chip

    inside the phone,,

    please swict to the nvidia chip , or i think ie will fail,,you have a hard job here shawn

    to make is all fid together

  6. Multiple render targets: Up to 4 on HighDef. Isnt that going to give problems for using a lot of lightning with shadowmaps? Or well, I’ve had a lot of problems of reusing render targets (dont even know if it is supported), or is it now?

  7. Shwarn what is the Chip Name and Generation on the Phone

  8. ShawnHargreaves says:

    > So the existing caps API is still there?

    No.  Only a very simplified new API for querying whether Reach or HiDef is supported, and what backbuffer formats are supported.

    > Also, as the HiDef profile is ‘Dx10-like’, and not strictly Dx10 hardware, I cannot use HiDef and assume the hardware can do fp alpha blending on windows?

    We’re still working the exact details around FP blending support. I’d love to be able to provide this in a consistent way, but no promoses yet,

  9. ShawnHargreaves says:

    > I suppose that Multisampling issupported only in HiDef, but it’s not mentioned. Will it be supported also on Reach?

    Multisampling is in both profiles, but is part of the backbuffer format which is allowed to vary across platforms. The API is structured so that you ask for what level you would ideally like, but the runtime is allowed to give you back something different if the hardware doesn’t support what you asked for.

  10. ShawnHargreaves says:

    > Multiple render targets: Up to 4 on HighDef. Isnt that going to give problems for using a lot of lightning with shadowmaps?

    Sorry, I don’t understand this question. You don’t need multiple rendertargest to implement shadow maps. And also, you have multiple rendertargets in a HiDef game, just the same as you do with Game Studio 3.1.

  11. ShawnHargreaves says:

    > what is the Chip Name and Generation on the Phone

    We’re not discussing the hardware at that level of detail right now, sorry.

  12. Jamie says:

    It looks like these graphics profiles only effect the caps. Is there any feature differences between the two profiles?

  13. ShawnHargreaves says:

    > It looks like these graphics profiles only effect the caps. Is there any feature differences between the two profiles?

    I don’t understand – what exactly is the difference between a cap and a feature?

    I would count things like occlusion queries and multiple rendertargets as features.

  14. ChowYunCat says:

    I love that I can now get runtime errors on a low-end profile without having a low-end card available.  This is incredibly useful.

    Will GS 4.0 bring any improvements in the amount of memory (and subsequent address space fragmentation) used by content compilation?

  15. Andrew says:

    So does this mean support for Shader Model 1.x has been dropped?

  16. Andrew says:

    Also: it would be nice if you could give the Windows folks doing internet distribution a good way to give their users an early-out – before they download, install and start a game – only to have it spit out an error that "whoops you don’t support the Reach profile" (like the current "you don’t have SM 1.1" error).

  17. Michael Wilson says:

    I was surprised to see Luminance8 removed. What is the recommended format for a lightmap now? Alpha8 is presumably equivalent in use, just with a name implying the wrong semantics.

  18. ShawnHargreaves says:

    > So does this mean support for Shader Model 1.x has been dropped?

    Correct. Game Studio 4.0 requires at least shader model 2.0.

  19. ShawnHargreaves says:

    > I was surprised to see Luminance8 removed. What is the recommended format for a lightmap now?

    Alpha8 is the most direct equivalent, but depending on the lightmap data, Dxt1 could also be a good choice.

    Luminance8 was removed because support for this format is very patch across different Windows hardware, while Alpha8 provides the same functionality and is universally available in all our HiDef target parts.

  20. Matan says:

    Well not so much Reach vs. HiDef related but rather GS 4.0 question, but:

    Will the bug in the content pipeline writing to memory instead of file be fixed in GS 4.0 ?

  21. i found a video ,

    http://www.youtube.com/watch?v=S7Rde3O7K24

    nice to hear that after all you will support

    programenabel shaders

    i allso wacth a game demo with dynamic and baked shadows ,,

    looking forward to this ,

    that clears most of my ?

    Tanks shawn

  22. ShawnHargreaves says:

    > i found a video ,

    > http://www.youtube.com/watch?v=S7Rde3O7K24

    > nice to hear that after all you will support

    > programenabel shaders

    Michael,

    That is not correct. Like I said before, we do not support arbitrary programmable shaders in this release.

    We do support a set of five built-in configurable effects, which is what I am demoing in that GDC video.

    As shown by games like the Harvest demo made by Luma Arcade, these five effects provide a lot of different rendering options, and are more than sufficient to make some great looking games.

  23. yes , that it what i meen, sorry for the misplacement of words

    programmable shaders in form of five built-in configurable effects , where you can set some values , and render light on object

    when i first look at the blog post deffent places a round the i got the felling that you have close the framework down and give us five effect insteed , but i see this is not the case

    so if this is correct if you what target phone,windows,xbox360 cross platform use the new set Reach you have build

    but if you what to target windows,xbox360

    use this set HiDef

    and will have a  full hardware accelerated 3D

    on windows and xbox360 in HiDef

    shwawn can you confirm this , i havent slept for a week now

    this things i do like , is that i have building a 3d engine for 3 years and a small editor and some other tools ,,

    and with the new framework i can not use this any more , i doint what to get stuck with the 3.1 i whant to move to 4.0 and render in HiDef

    with all the extensions we can use ,, me and my 2 frinds has been working on a game allso for a year now , and i not shown any videos and pictures of i what to save that if we gonna sign and nda in order to bring it to the market

    so you can see i’am vorryed about things

    Best regards

    Michael Hansen

    this is my consern

  24. Michael Wilson says:

    > Luminance8 was removed because support for this format is very patchy

    > across different Windows hardware, while Alpha8 provides the same

    > functionality and is universally available in all our HiDef target parts.

    Hmm, interesting, I didn’t know that. Oh well, it took 30 seconds to change the lightmap format in my current project to Alpha8, and it seems to be working fine.

  25. ShawnHargreaves says:

    >> Luminance8 was removed because support for this format is very patchy across different Windows hardware, while Alpha8 provides the same functionality and is universally available in all our HiDef target parts.

    > Hmm, interesting, I didn’t know that. Oh well, it took 30 seconds to change the lightmap format in my current project to Alpha8, and it seems to be working fine.

    This is actually a great example of how Game Studio 4.0 helps people make more portable games!

    There is nothing in DirectX or the Game Studio 3.1 API to indicate that Luminance8 is less widely supported than Alpha8, so it’s totally reasonable that many developers would choose Luminance8 format. It does what you want, and it works on your machine, so all is good, right?

    The only way to find out that Luminance8 will cause compatibility problems is to run tests across hundreds of different graphics cards.

    But because we did that for you while designing GS4, now you are automatically steered toward the more compatible format, without having to run all those tests for yourself…

  26. ShawnHargreaves says:

    > shwawn can you confirm this , i havent slept for a week now

    Michael,

    Afraid I don’t really understand what your concern is.

    Are you interested in Windows Phone development, or concentrating on HiDef Xbox/Windows platforms?

    My previous couple of posts have lots of info about the capabilities of the different profiles and platforms – what part of this are you worried about?

  27. That i have to start all over again in the new 4.0 framework on xbox360 and windows , and i can not use all the tools and engine that i have build

    we are target the hidef platform , not the phone maby in the future when i see what can be done ,, if there is custrom shades in the future versions

  28. DragonSix says:

    Did you do something about the hiccup issues many people encounter (mostly when the framerate is fixed/low). As of now we can’t make games targeted for less than 60fps without encountering very perceptible short hiccups, on both xbox and pc.

    There’s so many threads on the forums about that, and every single one of these finish with "deal with it", something’s very wrong here.

  29. ShawnHargreaves says:

    > That i have to start all over again in the new 4.0 framework on xbox360 and windows

    You won’t have to start over again. You will have to convert your code, because 4.0 is not backward compatible with 3.1, but this conversion is usually quite easy.

  30. Eric Cosky says:

    I am curious if there is any chance we will be able to use XAML as an overlaid UI for XNA games. Since the phone will support Silverlight, it seems like it might be a possibility. I suspect that would be of great use to many people. Thanks for any comments regarding this.

  31. DarthCheesiest says:

    Michael Hansen, reading through your posts gave me a heart attack as well, but anyway the post says.

    Reach Shader Model

    2.0  (but Windows Phone does not support custom shaders)

    HiDef Shader Model

    3.0+  (Xbox 360 supports custom shader extensions such as vfetch, which are not available on Windows)

    Also think about how many different shaders there are in the XNA Samples.

    Shawn, I see that the max texture size is 4096 on the HiDef Profile. I quite liked the idea of being able to have 8192 size textures, it may be shockingly wasteful, but I think it would make it easier to test giant terrains, or in the case of our current game Burning Fist, texture the background using just one texture(4096 as it is).

    YouTube video for illustrative purposes only(not shameless plugging to go along with my admission of shameful programming)

    http://www.youtube.com/watch?v=aXqoON7My7k

  32. elung says:

    Shawn, just a quick question that I came across after seeing yout GDC presentation.

    Why there are 2 different aspect ratios?

    800×480 vs 480×320

    Game screen will look different.

  33. PolyVector says:

    @Shawn

    When you say the Normalized101010 format is "no longer supported by any profile", you mean it’s being removed entirely? I hope not, because it really saves me vfetch bandwidth/memory.

    I’m just hoping 4.0 will open up more hardware features (like vfetch_full/mini), not disable them.  I’m writing games for the Xbox360, not some lowest common denominator. 🙂

    *pleads* Normalized101010 is innocent,  I stole the 2bits from the cookie jar. 😉

  34. ChowYunCat says:

    If the HiDef profile requires a DX10 GPU, why is the maximum texture size 4K instead of 8K?

    DX10’s minimum requirements:

    http://msdn.microsoft.com/en-us/library/ee415742(VS.85).aspx

  35. ShawnHargreaves says:

    > Why there are 2 different aspect ratios?

    > 800×480 vs 480×320

    > Game screen will look different.

    If you just program to a fixed resolution, you will get letterboxing (black bars) if the game is played on a device with a different aspect ratio. Everything will still work fine, though, and we will never stretch or distort the image.

    If you want to detect the native resolution and adjust your rendering for different aspect ratios, you can do that to. I think it will depend on the game which is the better/easier way to go.

  36. ShawnHargreaves says:

    > If the HiDef profile requires a DX10 GPU, why is the maximum texture size 4K instead of 8K?

    It doesn’t strictly speaking require a DX10 GPU, just a 9-turned-up-to-10 card. There is some interesting target hardware that does not robustly support 8k texture sizes.

  37. ShawnHargreaves says:

    > When you say the Normalized101010 format is "no longer supported by any profile", you mean it’s being removed entirely?

    "no longer supported by any profile" means exactly what it sounds like – gone, kaput, no longer supported.

    This format was just too inconsistent across different hardware and APIs (for instance, it doesn’t existing DirectX 10 or 11).

  38. ChowYunCat says:

    > It doesn’t strictly speaking require a DX10 GPU, just a 9-turned-up-to-10 card. There is some interesting target hardware that does not robustly support 8k texture sizes.

    If you have the time, could you explain more about this?  Which hardware (Intel?) and what problems does it exhibit?

  39. elung says:

    Shawn,

    I cannot find this information:

    What is the color depth of the Reach profile?

    Is it 16bits? 24bits? or even 32bits?

    The old Windows Mobile 6.x has only max 65K colors.

  40. ShawnHargreaves says:

    > What is the color depth of the Reach profile?

    This is one of the few things that is allowed to vary. The second paragraph after the table gives more details about how this works.

  41. crab_apple says:

    Hey, Sorry if I missed it somewhere but I’m just wondering why we can’t write 2.0 shaders on wm7.  Is it because the hardware is incapable of doing it, or is it a decision you guys made?

    If it’s the latter, could you give a bit of an explaination why this decision was made?

    Just curious, thanks

  42. lights says:

    I hate you Shawn,and love you too.

    I think the Hidef is can not use with CTP yet.

    But the Reach is not same like this table.

    First:

    Vertex texture is done well on pc,is that your present?

    Second:Shader model 3 done well on pc too.

    And other qustestions:

    First:

      Where is the DrawInstance?(When)Can I use this with Reach.

    Second:

      when the windows phone 7 support custom shader(3.0)?Please,I realy want to known about the time.

       I use many shaders,I want run my program on the phone with shaders.

    Third:

      No MRT in reach?for a short time or forever?

  43. Gong says:

    Shawn – is there a way to provide our own fallback mechanism?

    as you said:

    "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"

    What if I don't like the _your_ closest possible match?

    is there a way I can manually check if my format is supported?

    seems like the method GraphicsAdapter.CheckDeviceFormat() doesn't exists any more.

  44. Gong says:

    Shawn Hargreaves – I follow every post of yours, I have no idea how I missed that. thanks.

  45. Piotr says:

    I found a solution for my problem but I got another:) -> precision loss:).

    I described it here forums.create.msdn.com/…/70326.aspx

  46. Diego says:

    Hello,

    First I want to say that the work made until XNA 3.1 was excelent. It's really a very good tool, rather helpful.

    That already said, I consider the strategy taken for XNA 4 was terrible. It's clear that it focuses in Windows Phone & that's ok. But it's important to know that a lot of people who have been working for years (me inc) was left out.

    Visual Studio 2010 doesn't run XNA 3.1. So we need to switch to XNA 4. XNA 4 changes a lot of things (if we do graphics & draw procedures are completely changed… come on).

    Even doing that we run a project & get a beautiful error telling us to change the graphic card because it doesn't support HiDef (?!!!)

    Oh, but there is an option! Good, let's see… let's see… oh, we need to specify a telephone profile. Well, we can live with that. Let's read more. Oh wait… No MRT.

    That's how a GeForce 6200 user who has no Windows Phone (& let me dare, doesn't even know what a Windows Phone is, as he uses his old mobile just to call & write messages), was completely left out.

    Now, seriously, for some people it's not easy at all to change a whole big project just because it was decided to focus on a Phone. & moreover, telling people to change their graphic cards is a thing that should really be considered before suggesting it so lightly. I'm not attacking nor blaming anyone. I'm just saying that if XNA was intended for games, this changes & sudden requirements have nothing to do with this.

  47. Aaron says:

    @Diego: I completely agree with you. I have a new HP computer (less then a year old) and it apparently doesn't support HiDef. Additionally, I recently upgraded my xbox and bought the kinect combo (xbox / kinect) and gave my sister my old xbox. I tried to open up XNA on the xbox and it says "A xbox 360 hard drive is required to use XNA", so not only do I have to buy a new computer, I also have to buy an external hard drive just to continue developing my game.

    I very much dislike that Microsoft is pushing the phone on us so hard. Visual Studio 2010 says "for windows phone", Creators club is now "App" hub. To me it feels like a corporation is pushing us game developers out of our home. I rarely use the creator club anymore because of this reason.

    So Thanks Microsoft! You sure know how to keep my kids starving and my pockets empty!

  48. ShawnHargreaves says:

    Diego:

    > oh, we need to specify a telephone profile

    It is important to understand that Reach profile is not just about mobile devices! This is also designed to match the capabilities of mainstream PC graphics hardware. If you want to ship a game on Windows, and have it run reliably on pretty much every computer that has some kind of GPU (which is basically any computer being made these days) as opposed to only on high end gaming rigs, Reach profile is the set of features that you can rely on working on every customer machine.

    > telling people to change their graphic cards is a thing that should really be considered before suggesting it so lightly

    Of course all the changes in Game Studio 4.0 were considered carefully. We think long and hard about everything we do. You can find lots of information about the reasons behind all these changes in some of the older posts on this blog.

    One of the big decisions we made with Game Studio 4.0 is to focus on people who are actually going to ship games to large numbers of customers, as opposed to only developing games as a hobby to run on their own computer. Of course hobby developers are still important to us, but that's not the main thing we decided to optimize our designs for. When you start thinking about what it takes to actually ship a game to hopefully many customers, it becomes less interesting to expose every little quirk of the particular computer that that single game developer happens to have in their development PC. What really matters is the broad patterns of what capabilities are available in customer hardware, and how widely installed each possible capability is. When you analyze that data, it falls surprisingly neatly into just a couple of buckets of hardware capability levels, hence our two profiles Reach and HiDef.

    This isn't at all about phone vs. PC, but about what it takes to make games that run not only on the developer PC, but also on millions of different customer PCs.

    Aaron:

    > not only do I have to buy a new computer

    Before you rush out to do that, I would consider whether you can make your game using Reach features. It's actually much rarer than many people seem to think to need HiDef capabilities at all. Of course if you are doing super high end 3D stuff you will need that, but many games, even graphically advanced ones with lots of fancy shader effects etc, can work just fine using Reach capabilities (for instance, I think only two out of all the graphics samples on the AppHub website require HiDef profile).

  49. MikeX says:

    Hi,

    Can you make a list of cheap video cards that support HiDef? 😛

    Mine was supposed to but it doesn't, and I'd hate to guess again.

    Thanks

  50. Neil says:

    1. Does using Reach/HiDef limit the API methods/classes available or is it simply some actions are performed in software and are slower or are ignored?

    2. If it's the latter then why bother choosing, just let XNA pick the most appropriate one?

    3. I put a check in my code (IsProfileSupported(GraphicsProfile.HiDef)) during Initialisation and changed the profile accordingly to hidef/reach. Assuming this works, as per the points above, what's the point and just let XNA pick the best profile. Or am I missing something?

  51. ShawnHargreaves says:

    Neil – if your game only requires Reach functionality then there is no point bothering to create a HiDef graphics device.  If it requires HiDef functionality it will not run at all on hardware that only supports Reach.

  52. TomC says:

    Also, a "Reach plus shader model 3" profile would have been nice, for people who haven't yet abandoned XP.

  53. ShawnHargreaves says:

    "Reach plus shader model 3" is basically HiDef…

    I don't understand what this has to do with XP?  XNA graphics profile support is determined by your GPU capabilities, not your OS version.

  54. I just found this posting and have to say that I'm not amused. Basically: why don't you let developers decide on the hardware requirements based on what their game actually uses, instead of requiring a DirectX 10 GPU for all games because otherwise there will be a "No suitable graphics card found yada yada" dialogue when you try to start the game?

    I see why you need the "Reach" profile, I really do! But XNA 4.0 completely neglects that some people make games for Windows with XNA, not just Windows Phone 7 (-> Reach) and Xbox 360 (HiDef)! Limiting the possibilities to these two profiles effectively eliminates the possibility for a game that has hardware requirements between those of a slow smartphone and a fast 360. That's a pretty HUGE gap right there!

    I've made a 2D game that uses a few pixel shaders for e.g. blur effects that worked perfectly fine on my Thinkpad X60 Tablet, which has crappy onboard Intel graphics. I wanted to keep the requirements low in order to reach a wide audience on PC. Now I have two choices with XNA 4.0:

    1. I bring the graphics down to the level of a Windows Phone 7 game, so make them more sucky on purpose just so I can use Reach (e.g. without GetBackBufferData, you cannot implement Bloom effects effectively).

    2. I require my players to have a DirectX 10 GPU although my game doesn't need that much graphics power the least bit, making my audience much much smaller.

    In the second case, I cannot even go on developing my game on my Laptop. Yay. So if I want my game on 360 and a wide Windows audience, I have to cross-develop it for XNA 3.0 and XNA 4.0 now, apparently. Sounds like a very baaaad idea…

    Why didn't you guys at Microsoft think of that when designing XNA 4.0? What reason is there to not give developers a choice to simply ignore the aforementioned dialog and still try to just run the game, crashing it in the worst case if the requirements are not fulfilled? None of this would be a problem for Windows Phone or Xbox 360, nothing would change there at all. Couldn't you just enable us to do so?

  55. ShawnHargreaves says:

    > Limiting the possibilities to these two profiles effectively eliminates the possibility for a game that has hardware requirements between those of a slow smartphone and a fast 360. That's a pretty HUGE gap right there!

    It's actually a very tiny gap. Only about 5% of the current PC hardware install base (and shrinking all the time) has capabilities that are significantly greater than Reach but less than HiDef.

    This is a common misconception: it is absolutely not true that Reach only exists because of Windows Phone!  The Reach feature set is also a great match for the hardware capabilities of broad install base PC laptop/integrated hardware.  The delta between phones and integrated PC GPUs is all about bandwidth and processing speed, as opposed to actual varying of capabilities.

    > I've made a 2D game that uses a few pixel shaders for e.g. blur effects that worked perfectly fine on my Thinkpad X60 Tablet, which has crappy onboard Intel graphics.

    Onboard Intel GPUs are a perfect fit for the XNA Reach profile. In fact I can't think of a single significant feature of that hardware which is not available in Reach.

    > without GetBackBufferData, you cannot implement Bloom effects effectively

    Sure you can, check out the bloom sample on create.msdn.com.  GetBackBufferData is /not/ a good way to implement bloom (that would be horrifically inefficient).

    In fact check out all the graphics samples there: I believe the lensflare sample is the only one that requires a HiDef GPU!

  56. Gavin says:

    Is there some hack I can use to get MRT back on a non DX10 card? I was able to do MRT on older machines in 3.1 but apparrently not in 4.0. Will 4.1 bring this feature back?

  57. Gavin says:

    Before anybody jumps on me for suggesting such a terrible thing, I only want to do this for a competition – I wouldnt try to do this for a commercial project.

  58. Thank you Shawn, I was able to fix my problem with the old XNA 3.0 code and now it runs fine on Reach.

    My original point still stands though: why do you think that you have to protect me from using features that not all graphics cards might have? Why can I not decide that myself? Where is the necissity to keep me, the developer, from using certain features of PC hardware that might be present on non-DX10 video hardware?

  59. Jack says:

    Texture3D no longer supports DXT formats

  60. ShawnHargreaves says:

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

  61. 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