Breaking changes in XNA Game Studio 4.0

Breaking changes in XNA Game Studio 4.0

  • Comments 72

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.

  • +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.

  • Removed triangle fans

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

  • 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? :)

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

  • 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

  • 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 ?

  • 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 :)

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

  • # 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?

  • 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. :)

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

  • 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).

  • >>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*

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

  • "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 :(

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