Today several members of the XNA team did presentations at Code Camp Seattle. I missed Charles Cox's talk in the morning and Rick's talk didn't have anything from the new beta. However Mitch Walker went into some detail on the changes and demonstrated some new things. I have photographs of the demo but they will take a little time to put into order so for now here is what my notes said (hey if I'm wrong blame my memory and bad note taking !). Excuse the rough brain dump format - I figured you would prefer to see them sooner rather than later.

No date was given for the release other than 'soon' and 'watch the xna dev center for an announcement'. However Mitch didn't have any crashes during an hour demo so it must be pretty stable.

If you have any questions then please hold them for the beta release. It's unlikely that anyone (me included) will be able to give any more details other than what is listed below. This includes asking questions on the MSDN forums - we really don't need 200 hundred questions that we can't answer. So PLEASE try to honour this or expect to see the full wrath of my sarcasm in my replies!

Note that if you are reading this on Saturday 27th October you can still see all 3 XNA talks repeated at Seattle Code Camp on the 28th.

• No more design time support for components. They only added minimal value and it turned out to be far more complex on the xbox/compact framework. They also had some limitations like no way to control the order of creation and initialisation. They will be back in a future version in a more impressive way. For now components still exist, you just have to create, add them and set properties in your own code. As you will see they are also improved feature wise.
• XBox and PC builds require separate projects to make the build system work properly. To make an app run on both you need to make a new project of the other type and then add/link the source files. Future versions will use the build target mechanism from visual studio.
• GraphicsComponent is now GraphicsDeviceManager - it wasn't like the other components since it didn't have update or draw and caused confusion. Otherwise it has changed little other than some name changes to properties and methods for usability.
• Initialisation: The Game constructor should be used to create your objects and components. A new OnStarting overload should be used to initialise things as you can guarantee all services are published at this point.
• Game has LoadContent and UnloadContent calls which automatically get called for device creation and reset. A flag is passed in to indicate if you should load all content or just the ones from the Manual pool
• 2 types of resource - Automatic (which are reloaded for you on device reset/creation) and Manual (which you need to reload). ContentPipeline/Manager always uses Automatic.
• Game still has Update and Draw overloads. However a new GameTime object is passed in rather than being a property on Game. GameTime seems to have similar properties/methods to what we saw in beta 1.
• New overrides BeginDraw and EndDraw which are called either side of Draw. The default implementation of BeginDraw checks fora valid device and will stop Draw from being called if its not valid - this removes the check for EnsureDevice from beta 1. The default implementation of EndDraw calls Present.
• New overloads BeginRun and EndRun - should be used for Scene initialisation. I'm not sure exactly how this is different to Initialize.
• Components now get a Game object in their constructor.
• Components now only implement Update - if you want a component that also draws then you use DrawableComponent
• Components implement Initialize instead of Start - this matches the game class.
• Drawable components implement LoadContent/UnloadContent just like Game.
• Components have Enabled, Visible and RenderOrder properties to control activation, visibility and render order.
• Initialize will still be called if you add a component after the game object is initialized.
• Components are implemented using interfaces IGameComponent, IUpdatable, IDrawable meaning you can now add game component interfaces to something you wrote yourself that already has an inheritance tree. Useful since .Net does not support multiple inheritance. In general people should use the defined Component and DrawableComponent though.
• ContentPipeline - you simply add your content to the project. C# Express detects the file type and hooks up the right component pipeline component. You don't have to add textures if they are used by a model it automatically pulls them in. When you hit compile it builds them all into .xnb files which the content pipeline can read at runtime.
• Mitch demoed how easy it was to convert his FPS, grid, ModelView and camera components fro his gamefest video. The conversion took minutes.
• Some big changes around Render Target (and Mitch went pretty fast here...). Surface is gone, StretchRect is gone, UpdateSurface is gone, GetBackBuffer is gone (back buffer is now just RenderTarget 0). RenderTarget is a new strong type and you use a new construct called Resolve to get the data from it. Apparently this is very similar to the Xbox API and in this case it made more sense to implement the Xbox way of doing things for compatibility.
• SpriteBatch has a new parameter that defines when the state should be set - either at the Begin or the End. This means you can change the state yourself. Mitch did a demo of how to call a pixel shader that affects sprites. (more on that later). The way he did it was not using an Effect. I'm not sure if this was just so that he could demo Pipeline components or if you can't use effects on sprites because it will overwrite the vertex shader than spritebatch uses.
• Since XNA doesn't have a way to load a shader outside an effect Mitch demoed how to make a content pipeline add in that enables this.
• ContentPipeLine components have several components: Input - that handles the in file, Output - that controls what goes into the XNB file, Processor - converts from the input to the output (at this point you can detect if the target platform is PC or 360 as some things such as endian-ness need to be different), Reader - the part that read the XNB file (this will also be included in your game), Writer - the part that writes the XNB file (the subtlety between the Writer and the Output was lost on me in the rush of the demo).
• Any errors you throw from a pipeline component appear in c# express as a compile time error.
• After defining a new ContentPipeline component you add it into the options in c# express so that your game can use it.
• Running on the xbox - once the project was made as described above Mitch switched over to the xbox dev kit, selected an option to get the PC files and then on the PC hit 'run'. The program compiled and deployed over a local LAN to the xbox and then ran. It looked the same as on the PC.
• The next beta will not run on retail xboxes - that feature is not available until RTM. However the project types and supporting files will be shipped so you can build and compile and get ready.
• Finally Mitch demoed a couple of new demos/starter kits. The 1st one was a 2d match the color type puzzle game calle Marblets which, since Mitch announced it in public, I can now confirm I am writing for Microsoft. The second was a picture puzzle game where you swap squares around to reconstruct a broken up picture. Lots of gratuitous flipping and movement - looked pretty good. These are not shipping with GSE - Mitch said he thinks they will be offered as downloads.