Breaking changes in XNA Game Studio 4.0


I was relieved when the comments on my earlier post about backward compatibility agreed with the approach we chose for XNA Game Studio 4.0. Banjobeni summed up the general sentiment:

"If you break it, break it good."

The initial motivation for breaking changes in XNA GS 4.0 was the addition of Windows Phone, but this is about more than any one platform. A quick history lesson:

Version 1.0 of the XNA Framework was designed around DirectX 9 on Windows. We had little time to create an enormous API, so had to move fast and decisively. In retrospect I think we did a great job choosing the right places to concentrate our design efforts, and I’m proud of what we built, but there were many areas where we decided “hey, we don’t have time to agonize over this detail, so let’s just copy whatever native DirectX 9 does, and move on”.

When we started work on Xbox 360 in the second half of the 1.0 development schedule, some of these hasty decisions needed to be revised (and some were revised further in our 2.0 release), but many were left alone. Even when things didn’t exactly fit the Xbox, they were similar enough that we could squint and say “yeah, that’s close enough to get the job done”.

When we looked at the new phone platform, we found more things that did not work quite the same as on Windows. Had we tried to squint until they looked the same, we would have ended up with our eyes screwed most of the way shut! I’m a perfectionist, and that just didn’t feel good enough.

Ok, let’s change our API in the places necessary to make the phone consistent with our other platforms.

But breaking changes are expensive. Having gone three years without any major breaks, we felt this was a good time to introduce an inflection point, cleaning up our act and setting ourselves up for the future. But we also felt it was important that this be a one time thing. Breaking changes every three years may be ok, but every year, or every six months, most certainly would not. If we’re going to break it, let’s break it good, taking all the pain in one go so we don’t have to break again for many years to come.

So, we took the opportunity provided by the phone to also reduce those nagging Windows vs. Xbox inconsistencies.

We also used this opportunity to improve usability, applying our three years of experience to look at which things cause the most confusion for our customers, and tweaking these APIs to reduce the chance of error.

Finally, we gazed deep into our crystal ball in an attempt to predict the future. This failed miserably (sadly, it turns out I am not psychic at all :-) so instead I made some guesses. XNA Game Studio 4.0 sits on top of DirectX 9 on both Windows and Xbox 360, and we have no immediate plans to move to DirectX 10 or 11, but looking years into the future, it seems at least possible we might someday want to do that. DirectX 11 adds some things that are not in DirectX 9, but it also changes and in some cases removes features. Adding features is relatively painless from a compatibility perspective (it’s easy to imagine how a third profile could someday sit alongside Reach and HiDef) but taking things away hurts deep (it would suck if any such third profile could not be a strict superset of HiDef, in the same way that HiDef is a superset of Reach). So we looked at what it would take to implement our API using DirectX 11, and made sure we didn’t include anything that would make this excessively difficult. I am not promising we will ever support DirectX 11, just saying we did some thinking about this and laid some groundwork so if we ever do want it, we can go there without having to break backward compatibility.

An overarching goal of these API tweaks was that even though we are breaking things, we still want the new API to feel like the XNA Framework you know and love. Some of the details may be different, but existing developer knowledge and design patterns should be easy to move across.

Another goal was to prefer simplicity over complexity. I am a big believer in minimalist design. It’s easy to add new things each time we encounter a new problem, but I think more valuable to hone them down to their core essence, trying to find the minimum surface area necessary to communicate between developer and runtime. It makes me happy that the XNA Framework 4.0 API surface is significantly smaller than the 3.1 version.

I’ll be writing more about these changes and the reasons behind them over the coming weeks, but here is a quick summary of the more significant breaking changes:

  • Replaced StorageContainer.TitleLocation with a new OpenStream API
  • Replaced individual graphics renderstates with a new state objects API
  • Premultiplied alpha is now enabled by default
  • Made it easier to use SpriteBatch with custom renderstates and custom shaders
  • No more SpriteBatch vertex shader magic, so you can easily position SpriteBatch text in a 3D world using BasicEffect
  • Vertex buffers are now strongly typed, each one having an associated VertexDeclaration
  • You no longer need to specify a VertexDeclaration before drawing, because this is implicit in your choice of vertex buffer
  • Vertex buffer sizes are now specified as number of vertices rather than bytes
  • Replaced GraphicsDevice.Vertices with a new SetVertexBuffer API
  • Each rendertarget now has an associated depth buffer: no more DepthStencilBuffer type
  • RenderTarget2D now inherits Texture2D: no more GetTexture method
  • SetRenderTarget atomically sets all rendertargets, rather than changing just one layer
  • Replaced Effect.Begin and End with a new EffectPass.Apply method
  • Removed the low level shader APIs (VertexShader, PixelShader, Set*ShaderConstant)
  • Removed EffectPool, StateBlock, GammaRamp, ClipPlane
  • Removed triangle fans
  • Removed point sprites
  • Changed the Color type from BGRA to RGBA byte ordering

I suspect some of you will have concerns about some of these removals. Don’t panic! This article is already too long, and I’m running out of time to write more, but I am confident once I explain the why, how, and wheretofore of these changes, you will agree they are good and sensible. If there are specific things you would like me to write about first, please let me know via the comments below.


Comments (72)

  1. Thanks shawn for the info,,but

    1 .Each rendertarget now has an associated depth buffer: no more DepthStencilBuffer type

    this meen that if we are on the xbox360 we can use the full 10mb special ram , course there will allways an underlying depthbuffer, in place

    2.RenderTarget2D now inherits Texture2D: no more GetTexture method

    Do we have custrom resolve from a lover rendertarget to a higher texture resulition

    3. when are we gonna test out the HiDef version of the Framework

  2. Matan says:

    Great post, as usual. I have to say I was a bit concerned at first when you talked about Reach vs. HiDef , this post however makes me feel like the changes will be a lot better.

    I do have a few questions though about the list of changes, although I assume they will come with the post about each of them individually, so these are the posts I, personally, would like to hear about first:

    1) "Removed the low level shader APIs (VertexShader, PixelShader, Set*ShaderConstant)"

    2) "Removed point sprites"

    3) "Replaced Effect.Begin and End with a new EffectPass.Apply method"

    To be honest I don’t have any questions about the third, it juts sounds like a really good idea and I would like to hear more about it.

    Either way, sounds like you’ve done more than just a great job with GS 4.0.

  3. Tim James says:

    ResolveTexture2D also seems to have vanished, aswell as graphicsDevice.ResolveBackBuffer. Might be worth noteing.

  4. fn2000 says:

    I’m developing for Windows, so the obvious question to your post here is: will the GS4.0 make it harder for me? I do use a lot of low-level API’s (as far as you can call any part of XNA API low-level) so are these changes more into making API more clean and consistent across framework or it’s more about removing features that YOU think most people won’t use anyway so why bother?

    How about performance of GS4.0 vs. GS3.1 – how much overhead new usability changes will introduce if any?

    Thanks!

  5. ColesyM says:

    There is only one I am really concerned about, and that is the removal of clip planes. Sure it may be some future proofing, but right now popular techniques simply rely on it, such as planar reflection.

  6. sRc says:

    "RenderTarget2D now inherits Texture2D: no more GetTexture method"

    that makes me glad. I had a heck of a time trying to figure that one out when all the posts on the forum I could find about it seemed to be from back in 1.0 and some other things had changed in that time

  7. Grant Kot says:

    As for me, I’m interested in how to work around the removal of point sprites. In my game, I have hundreds of thousands of particles and using point sprites allowed me to quickly pass in the data needed to render them. Though I was also looking into geometry shaders to do these, which would even allow non-square particles, but since there’s no directx10 or 11… I know I can use spritebatch or make my own triangles, but aren’t point sprites faster?

  8. I like some of the concepts present in this release but… and I don’t want to sound ungrateful or whiney here, but please don’t oversimplify the API.  Just because collapsing the caps and combining alpha renderstates makes it easier for new developers, some of us really want the level of control that comes with the more diverse option set and losing that functionality could push us away.

    On a more positive note, once I got used to the EffectPass.Apply change, I really started to like it. And the RenderTarget and VertexBuffer changes sound awesome.  Kudos to the whole team!

  9. ShawnHargreaves says:

    > I’m developing for Windows, so the obvious question to your post here is: will the GS4.0 make it harder for me?

    Not at all! In fact I think they will make it easier, as you will not have such a difficult time making your game compatible across different PC’s.

    Ultimately, though, you’ll have to judge this for yourself :-)

    > How about performance of GS4.0 vs. GS3.1 – how much overhead new usability changes will introduce if any?

    Mostly they make things faster, as they move much validation logic from draw time to create time.

  10. ShawnHargreaves says:

    > There is only one I am really concerned about, and that is the removal of clip planes.

    Clip planes can be implemented quite easily in a shader (like they are in DX10+), and this will perform just as good as using the older dedicated API (in fact many DX9 drivers implement them by patching shaders to add clip instructions).

    This does mean you don’t get clip planes on the phone (no custom shaders there), but then, you wouldn’t have gotten them anyway since there is no fixed function clip plane hardware either!

  11. ShawnHargreaves says:

    > As for me, I’m interested in how to work around the removal of point sprites.

    Heh, yes, I was expecting some questions about this!

    The motivation for this removal was obviously that there are no point sprites in DX10 or 11, but we too were pretty worried about this. It would be bad if something like the 3D Particle sample was no longer possible, or decreased in performance!

    Short answer: don’t worry, it’s fine, turns out point sprites aren’t so great for performance even on hardware that does support them, and we actually managed to make the 3D Particle sample run FASTER on Xbox by changing it from point sprites to triangle lists!

    Longer answer is somewhat subtle and full of details that deserve a post of their own. Stay tuned…

  12. ShawnHargreaves says:

    > Just because collapsing the caps and combining alpha renderstates makes it easier for new developers, some of us really want the level of control that comes with the more diverse option set and losing that functionality could push us away.

    I would love to hear more about which specific options you are worried about losing?

    I’m pretty confident that once you see where things have moved, or what alternative ways exist to replace the things we removed, you’ll see that all the neccessary abilities are still very much present.

    These changes were about simplification for sure, but not just for new developers and not at the cost of removing important features that people need!

  13. Matt Enright says:

    Sounds great – my experiences with point sprites, vertex declaration tricks, and render target resolving often turned out to work only when bent to the will of a specific graphics card, destined to fail on nearly any other machine. The framework will be better for the removal/simplification of them.

    One red flag was raised: "Each rendertarget now has an associated depth buffer: no more DepthStencilBuffer type"

    As mentioned, this could have some negative performance issues with the Xbox 360’s 10MB eDRAM. It also increases the memory usage for some shadow mapping techniques and other off screen rendering methods that don’t require a depth buffer. That could be resolved by specifying that a render target has no associated depth buffer, but a lack of depth buffer sharing could affect other rendering configurations, like deferred lighting.

    Kudos on the changes, though. A few carefully placed constraints prevents so much pain down the road, and encourages more productive game crafting.

  14. David Black says:

    How do the vertex buffer changes affect support for hardware instancing? (on windows, I assume vfetch is still possible on 360).

    I have a lot of instanced geometry and my framerate would be terrible without instancing support…

  15. Erzengel says:

    "# Vertex buffers are now strongly typed, each one having an associated VertexDeclaration

    # You no longer need to specify a VertexDeclaration before drawing, because this is implicit in your choice of vertex buffer

    # Vertex buffer sizes are now specified as number of vertices rather than bytes "

    Thank you (plural you) for this. I always found it as a failure to leverage the OO from C# that this wasn’t done.

    The removal of clip planes concerns me as well. I rarely use shaders, relying on BasicEffect for most of my work, but I need ClipPlanes for my portal system. They were so simple to use; now you’re saying "We’re taking that out, so you have to make it yourself". Isn’t the reason I’m using XNA is so I don’t have to make it myself for such simple things?

  16. Alarmed says:

    While I like the simpler API, I have some *serious* concerns about the features you’re removing and how it will impact XNA performance, usability, and flexibility for serious developers.

    "Removed the low level shader APIs (… Set*ShaderConstant)"

    The xna 3.x SetConstant methods are considerably faster than CommitChanges.

    With CommitChanges now missing how are effect parameters set while an effect pass is active?  And how does this perform compared to CommitChanges / SetConstant?

    If the new method is slower than SetConstant, then SetConstant should not be going away – it is a critical part of making xna Effects efficient.

    "Removed … ClipPlane"

    Regardless of how this is implemented in the driver it’s handled *automatically* for the user and for *all* rendered objects.  Telling users they need to code clipping plane calculations into the custom shaders of all their objects, just to support simple reflections (which should be object independent) is ridiculous.

    Is this code included in BasicEffect, DualEffect, and SkinnedEffect?  How will the core effects work with reflections?

    Clipping planes are also an important tool used to optimize complex rendering, especially in forward rendered situations.

    CompiledEffect and the ability to load effects dynamically is also missing.  At the very least loading game resources dynamically should be supported on Windows.  For developers with editors this functionality is critical, and unfortunately MSBuild and the content pipeline is far too slow for real-time use.

    I haven’t had the time to dive into XNA 4.0 further, so I’m sure there are more missing features I’m not aware of yet.  But I’m concerned that serious developers and their needs are not being considered at all here.

  17. fn2000 says:

    Shawn, thanks for answers – I feel much more secure now 😉

  18. Zeljko says:

    "Removed point sprites"

    Id like to hear about why are we losing point sprites.

  19. Michael Wilson says:

    Removal of point sprites looks like a big problem. The reason being that you can do an expensive VS calculation for a point sprite and it only happens once, wheras for a quad it is repeated four times. Not a big issue on Windows with modern GPUs, but I’m pretty sure that would be a serious performance hit on the X360.

    Something I’ve been meaning to ask, did you add pass-by-reference versions of Effect.SetParameter? It’s a very heavily used method in most 3D/non-SpriteBatch games, but as of XNA3.1 it only accepts pass by value, which struck me as odd when all the vector maths functions have pass-by-reference versions. Is there some kind of hidden parameter validation going on that wouldn’t work without immutable arguments?

  20. Alarmed says:

    Ok apparently there are more problems:

    "Each rendertarget now has an associated depth buffer: no more DepthStencilBuffer type"

    How do you share depth buffers between render target?

    When shadow mapping, several shadow maps or pages will share a single depth buffer to reduce memory usage – how is this accomplished in XNA 4.0?

    (and what happened to my last comment? :)

  21. Grant Kot says:

    Thanks for so quickly answering my previous question. Now I have some questions on how to get the DynamicSoundEffectInstance stuff working. I tried to get a 440hz A sinusoid playing. It has the right pitch, but I can’t seem to get that pure sound that it’s supposed to be, it either sounds like a sawtooth or some other strange waveform. Here’s what code I’m using:

    for (int i = 0; i < 480000; i++)

    {

       wave[i] = (byte)(Math.Abs(Math.Sin(441.0*i/96000*Math.PI))*256);

    }

    I’m not sure how to handle negatives and where to zero it.

  22. Sean Mealin says:

    Being a completely blind developer, I’m interested in the audio API.  Can you please talk about some of the changes in 4.0?  More specifically, are there any changes in 3D audio?  I thought I heard something about being able to stream sounds without using the XACT tool, which is not accessible with screen reader software.

  23. All of that sounds great to me! Except for the point sprites which you seem to have saw coming. : j

    But not worried, all the work arounds seem justifiable. Excellent work!

  24. ShawnHargreaves says:

    Ok guys, here’s the deal: I’m not going to respond to individual followup questions in this thread, but don’t worry, I’m not ignoring you: it’s just that there are many different topics coming up here, all of which deserve to be addressed in far more detail than will fit in this comment box! As soon as I have time (ie. when I get back home after MIX) I will be making a separate post on all the questions raised here, so I can make sure I properly explain everything in the proper amount of detail. I’ll start with the things that the most people asked about here. Please be patient while I work through these many topics!

    I also just want to reiterate that these changed were absolutely designed to benefit skilled developers who are making high end games, and not just beginners!

  25. Cookiecat says:

    Hey Shawn, since you mentioned the topic of Breaking changes in XNA 4.0, I thought I’d share an issue I ran into last night while upgrading my XNA 3.1 project to XNA 4.0.  

    It seems you guys have changed the signature to SpriteBatch.Begin.  Before, I was calling

               _spriteBatch.Begin(

                   SpriteBlendMode.AlphaBlend,

                   SpriteSortMode.FrontToBack,

                   SaveStateMode.None );

               Color modColor = Color.White;

               _spriteBatch.Draw( _circle, _position, null, modColor, 0, Vector2.Zero, 1.0f, SpriteEffects.None, 0 );

               modColor.A = 100;

               _spriteBatch.Draw( _circle, _position2, null, modColor, 0, Vector2.Zero, 1.0f, SpriteEffects.None, 0.5f );

               _spriteBatch.End();

    but this didn’t compile, so I switched it to the most seemingly logical equivalent in XNA 4.0:

               _spriteBatch.Begin(SpriteSortMode.FrontToBack, BlendState.AlphaBlend);

               Color modColor = Color.White;

               _spriteBatch.Draw( _circle, _position, null, modColor, 0, Vector2.Zero, 1.0f, SpriteEffects.None, 0);

               modColor.A = 100;

               _spriteBatch.Draw( _circle, _position2, null, modColor, 0, Vector2.Zero, 1.0f, SpriteEffects.None, 0.5f);

               _spriteBatch.End();

    When rendering, these two calls do not do the same thing as I would have expected.  Here is the side by side comparisons of XNA 3.1 vs. 4.0

    http://img227.imageshack.us/img227/5554/xna31vs40.png

  26. ShawnHargreaves says:

    > I tried to get a 440hz A sinusoid playing. It has the right pitch, but I can’t seem to get that pure sound that it’s supposed to be

    Dynamic audio uses 16 bit PCM format.

    If you need more help with this, I would recommend asking on the creators.xna.com forums, where our audio dev can help you out (I only know about the new audio stuff from a high level, not all the gory details of how to use it)

  27. Sushovan says:

    >Changed the Color type from BGRA to RGBA byte ordering

    Shouldn’t it have been ARGB? /wonders

  28. ShawnHargreaves says:

    > Shouldn’t it have been ARGB? /wonders

    Nope.

    RGBA is the standard color layout in DirectX 10 and 11, and thus also the native layout of most modern graphics hardware.

  29. Piersh says:

    Eek! No more point sprites or clip planes? Say it ain’t so :(

    +1 for reconsidering this…

  30. mattbettcher says:

    I would like to know about the DrawInstancedPrimitives method and how that works and what platforms it’s available on.

  31. Markus Ewald says:

    +1 for point sprites.

    I can replace them in my game without too much effort thanks to a pluggable particle renderer, but I would have 4 vertices instead of 1 for each particle (or 3 with some clever billboarding).

  32. barkers crest says:

    +1 for more info on:

    1.  Clip Planes

    2.  Sharing a single depth buffer between render targets.  

    I’m guessing if the RenderTarget change is an improvement perhaps the GraphicsDevice will no longer require the DepthStencilBuffer to be set to accommodate rendering algorithms that do not read/write to depth buffer…and perhaps the RenderTarget has a constructor that gives the option to not create a DepthBuffer.  Thus, a savings in memory.  I’m really curious to hear about this.

  33. David Black says:

    Requiring all render targets to have an individual depth buffer does seem a bit wasteful of memory.

    Eg things like tone mapping, blurring, saved textures for distortion mapping, parts of volumetric fog, SSAO etc etc.

    All the types of things the 360 is good at with its insane fill rate… And the extra cost of the buffers is likely to hurt the 360 more with its limited Expensive Graphics Ram(or whatever its called).

    Looking at the CTP, there does not appear to be any options to disable creation of depth buffers(Unless specifying Unknown for a format disables creation, which would be counter intuitive:-(

    Hopefully this will be improved before release?

    Perhaps there is something I dont know about graphics hardware… (eg they almost always create hidden depth buffers along with render targets) or depth buffers are lazy created when the user tries to render with depth buffering enabled(which would be kinda cool, if a little confusing).

  34. PolyVector says:

    I reuse a single depth buffer throughout my deferred renderer.

    +1 for hearing about depth buffer reuse. :)

  35. Tom Gillen says:

    How does the linked render target/depth buffer work with multiple render targets?

    Is there no longer any way of changing render target while preserving the current depth buffer? If not, then I’ll have to either manually restore depth when sapping to the lighting buffer or accept that occluded lights can no longer be efficiently culled.

  36. mattbettcher says:

    Does the emulator use the same garbage collector as the actual phone? How close is the emulators speed to real life?

  37. Clayman says:

    No more SetxxxConstant and CommitChange,so what’s the best way to update effect parameter?

    Also curious about the behavior of EffectPass.Apply.

    GraphicsDevice will do redundant check when set state object(good), are there other redundant check beside this one?

  38. How close is the emulator to the real phone’s also from what I here the cortex-a8 and the scorpion arm cpu’s are very differant in speed from each other… which one is the emulator trying to match? and at what clock speed.

    Also what about the emulators garbage collector?

    I don’t expect to answer this right now but if you could in the next few weeks (if you are allowed) that would be great.

  39. Michael Wilson says:

    > RGBA is the standard color layout in DirectX 10 and 11, and thus also the native layout of most modern graphics hardware.

    Out of curiosity, why did XNA originally use BGRA as the default?

  40. ShawnHargreaves says:

    > Out of curiosity, why did XNA originally use BGRA as the default?

    Versions of DirectX prior to 10 used BGRA color layout. This is a quirk of older Microsoft platforms (GDI does the same thing) that we’re gradually trying to move away from.

  41. ShawnHargreaves says:

    This has nothing to do with the topic of this post, but since a couple of people have asked about the emulator, I will answer that anyway.

    The emulator is a full functional emulator of the phone behavior, but it does not attempt to emulate performance characteristics. It runs the full phone OS (including the same CLR runtime as the phone) in a virtual machine, but it does not do hardware level timing emulation.

  42. ShawnHargreaves says:

    btw. I’m not ignoring all your questions about point sprites, rendertargets, etc, just planning on addressing these in a separate article rather than commenting on each question here.

    Keep the questions coming – this is great feedback to make sure my next few articles cover all the things you want to know!

  43. Adrián Montesinos says:

    Something that XNA really needs is good floating-point performance on xbox. There’s no use of SIMD instructions. Without SIMD, most of the gameplay and physics math runs VERY slow. Have you (plural you) ever thought about that?

    I can’t wait for using it.

  44. Joe says:

    Apparently nothing has been done to improve Matrix operation in the Compact Framework on the XBOX Platform. I still think this is something that should be addressed as Game programming without SSE code is a big limitation.

  45. David Black says:

    Hmm, from what I remember about native 360 code performance, the big problem is branching on float compares. Otherwise the standard float unit on the 360 is pretty good.

    So I would suggest trying to remove comparisons in your math intensive code. Which would be a lot easier with some VMX extensions to the CLR, so we can use the more sophisticated predication etc. However a single intrinsic style function for fsel(assuming the CLR doesnt generate it) would probably help in this area.

    So do the Math.* operations use branchless versions, eg Min,Max etc? I would guess not.

  46. Grant Kot says:

    +1 for SIMD/performance improvements on the xbox. If you look at my youtube channel http://www.youtube.com/kotsoft, you’ll see what kind of game i’m making. My game will have fluid simulations with fluid simulations with 10s to 100s of thousands of particles, and it runs fine on the pc, but it’s really slow on the xbox. The xbox live indie games are doing well, but i think by making the speed of XNA on the Xbox more like c++ code it would bring a whole new level of games to the market. With the current performance, only so much is possible.

  47. XD says:

    Removed triangle fans

    it is useful for cilinders/cone caps, disks and other geometry generated by revolution(to cap them)

  48. PolyVector says:

    FP/math/general performance is the bane of my existence too, but I think we should stick to requesting clarification on 4.0 changes, not making feature requests.

    Also, can I have a pony? :)

  49. BigBen says:

    Hello, I’ve a question about XNA 4 on Windows Phone.

    I’ve my owne Engine based on XNA 3.1 and I changed it to be on XNA 4. I’ve references of my Engine in the Content project (to load some classes).

    To try on Windows  Phone, I cliked right on all my project to Create a copy for WP (except for the Content project).I added the references of my WP Engine to the Content project. But when I compile it says me that it can’t load the assembly of my dll. It works on PC dll, why not on WP dll ?

    Thanks for your answer.

  50. ShawnHargreaves says:

    BigBen: you cannot reference a Windows Phone project from your Content project, because the content build process runs inside Visual Studio on your Windows PC, not on the phone!

    More info in this article: http://blogs.msdn.com/shawnhar/archive/2008/11/24/content-pipeline-assemblies.aspx

  51. BigBen says:

    Thanks for your help, now I can launche my Engine on Windows Phone.

    I have an other problem (since 3hours), my components are initialized (my Core, SceneManager, and LevelManager (my engine is divide on multiple assemblies)), but after the first draw of all my entities the program stop without throw exception. I tryed step by step and it stop just at the end of the draw method in the Game class.

    It works fine on Windows but not on Windows Phone. Could it be a memory problem ?

  52. BigBen says:

    I’m so sorry, don’t post my last post, I just solved my problem. A bad reference… So my Engine is runnning under Windows Phone.

    Thank’s for your help, and your blog :)

  53. KIKIAlex says:

    "Each rendertarget now has an associated depth buffer: no more DepthStencilBuffer type"

    If all the render targets have individual depth buffers a lot of memory is wasted for no good reason on any game that is using deferred rendering or any post processing effect.

  54. default_ex says:

    # Each rendertarget now has an associated depth buffer: no more DepthStencilBuffer type

    Does this mean we can no longer share the depth-stencil buffer between all of the render targets?

    # RenderTarget2D now inherits Texture2D: no more GetTexture method

    Thanks a lot for this one, it’ll make some of the things I’ve been working on lately much more universal.

    # SetRenderTarget atomically sets all rendertargets, rather than changing just one layer.

    Does this mean we can no longer swap out just a single render target? Will doing so, if possible, invalidate the rest of the render targets that were intentionally left in place?

  55. FlyingWaffle says:

    Regarding deferred rendering and depth+stencil buffer culling, you described very well all the necessary steps in your very own 2004 article

    http://www.talula.demon.co.uk/DeferredShading.pdf

    Could you please describe how to do all that stuff in XNA 4.0? I.e. efficient culling of light volumes with z-test and stencil tests, etc? Cause I’m *really* lost now. :)

  56. Fduch says:

    Why was BGRA color format (SurfaceFormat.Bgr32) removed from XNA4??

  57. ShawnHargreaves says:

    Why was BGRA color format (SurfaceFormat.Bgr32) removed from XNA4?

    Because it is unnecessary (the same thing as Color, just with the bytes in a different order), and also not supported everywhere (DX10+ are moving toward consistent RGBA as opposed to BGRA ordering).

  58. Fduch says:

    >>Why was BGRA color format (SurfaceFormat.Bgr32) removed from XNA4?

    >Because it is unnecessary (the same thing as Color, just with the bytes in a different order

    I think you should first make sure RGBA is supported everywhere before removing BGRA.

    System.Windows.Media.Imaging.RenderTargetBitmap supports ONLY PixelFormats.Pbgra32. And now XNA4 stops supporting this format and I have to flip all texture bytes myself in the main memory.

    Looks like .Net is starting to crumble under all the incompatibilities, inconsistencies, inconveniences… Teams should communicate more and share code, interfaces, classes, principles, ideas. *stops dreaming*

  59. Fduch says:

    I just looked at MS.Internal.PixelFormatEnum enumeration from PresentationCore in .Net 4.

    The only 32bit formats there are: Bgr32, Bgra32, Cmyk32, Gray32Float, Pbgra32.

    And the only RGBA formats are: Prgba128Float, Prgba64, Rgba128Float and Rgba64.

    So many useless formats but no mention of that elusive "consistent", "supported everywhere" 32bit RGBA.

    P.S. Sorry for bitterness, but incompatibilities without workarounds drive me crazy.

  60. mikeschuld says:

    "The current vertex declaration does not include all the elements required by the current vertex shader."

    When loading in a textured truck model everything sits happily and renders as it should. When loading the simple untextured teapot model, I get the above error. XNA 3.1 didn't complain when there were missing items. Is there a way to tell the shader something is optional? I really liked one shader that worked for all my sample models :(

  61. ShawnHargreaves says:

    > XNA 3.1 didn't complain when there were missing items.

    3.1 just passed this through to the driver, which depending on hardware might return 0s, or NaNs, or might crash, or lockup, etc. This situation resulted in undefined behavior, which happened to work out ok on your particular card+driver, but would have caused compat issues if you tried to ship this code to customers with different hardware.

    No, there isn't a way to tell shaders that data is optional. If a shader uses an input, the caller must provide that input. In 4.0 we check that you are doing this right, so you can be sure that your code will work reliably on different machines.

    The error message should tell you which specific vertex channel is missing, so you can either add thsi to your model data, or change your shader to not require it.

  62. Vinod says:

    Hi..

    I was using hashtable in 3.1 but in 4.0 for wp7 its not there … can u suggest me an alternative …

  63. ShawnHargreaves says:

    > I was using hashtable in 3.1 but in 4.0 for wp7 its not there … can u suggest me an alternative …

    System.Collections.Generic.Dictionary

  64. Kyle says:

    I'm also getting the InvalidOperationException "The current vertex declaration does not include all the elements".. I'm not sure how to tell which channel its referring to. It doesn't say more than that.  I'm getting the exception when I'm binding a VertexBuffer of type VertexPositionColorTexture.  TexturesEnabled is true, VertexColorEnabled is true, the Texture is set to a normal Texture2D which is loaded fine.   I also ran the EffectsPass (just a count of 1 of them in the list) prior. All 3 matrices set.

  65. ShawnHargreaves says:

    Kyle: this is on Windows Phone, right? Try running your game on Windows, that'll give a more detailed error message.

  66. Paul says:

    for some questions you couldnt see answers on xna 4.0 try davidtblogs.wordpress.com

  67. Opelion says:

    uhm one thing i noticed is Compiled effect class is missing but its not all in any place telling its missing

    hmm i had a couple of shaders in strings and prebuilt it in engine that way i dont have to keep adding the effects in every project i make

    soo question is without the compiled effect class how can i compile strings and put them in effects?

  68. ShawnHargreaves says:

    Opelion: Game Studio 4.0 effect compilation is handled by the Content Pipeline. You can do that in Visual Studio, or automate it using MSBuild, or call into the EffectProcessor directly from your own code, but this functionality requires the Content Pipeline so is not available on computers that do not have Game Studio installed.

  69. Opelion says:

    hmm so not even the run time of XNA 4.0?

    tyvm 😉

  70. Guy says:

    Dear Shawn,

    1. Keep up the good work and the good community support

    2. Did you post the article/blog which should give detailed answers to the questions above yet? If so, can you post a link to it here?

    Thanks.

  71. LotusXP says:

    "No, there isn't a way to tell shaders that data is optional. If a shader uses an input, the caller must provide that input. In 4.0 we check that you are doing this right, so you can be sure that your code will work reliably on different machines."

    According to this MSDN article, the shader will simply init values that are not within the stream to 0's.

    From Writing HLSL Shaders in Direct3D 9 (msdn.microsoft.com/…/bb944006(v=VS.85).aspx):

    "The input structure identifies the data from the vertex buffer that will provide the shader inputs. This shader maps the data from the position, normal, and blendweight elements of the vertex buffer into vertex shader registers. The input data type does not have to exactly match the vertex declaration data type. If it doesn't exactly match, the vertex data will automatically be converted into the HLSL's data type when it is written into the shader registers. For instance, if the normal data were defined to be of type UINT by the application, it would be converted into a float3 when read by the shader.

    If the data in the vertex stream contains fewer components than the corresponding shader data type, the missing components will be initialized to 0 (except for w, which is initialized to 1)."

  72. ShawnHargreaves says:

    LotusXP: that article is talking about missing components /within/ a data channel, for instance if you provide a float3 position but the shader asks for float4 data.  That behavior is well defined as described in the MSDN article.

    But this is not the same thing as the shader asking for a data channel that is not present in the vertex data at all, for instance trying to use a texture coordinate when no such value is available. This latter situation is undefined behavior. On some systems you will get zeros, on others random values, and some machines will crash or hang. Really not something you ever want to be doing!