XNA 2.0 Beta Released

Nov 20, 2007 at 3:00 AM
Get it while it's hot and fresh out of the oven: http://www.microsoft.com/downloads/details.aspx?FamilyId=1A096AC7-AEC5-4CD0-9826-1F07EB26EEFD&displaylang=en
Nov 20, 2007 at 3:13 AM
Also, the README is actually worth reading while waiting for the download. There are some interesting "known issues" that are good to be aware of, like:


1.1.8. XNA Game Studio 2.0 (Beta) Is Incompatible with the Released Version of Games for Windows - LIVE

XNA Game Studio 2.0 (Beta) is incompatible with the released version of Games for Windows - LIVE. Do not install XNA Game Studio 2.0 (Beta) on a computer on which a Games for Windows - LIVE game is installed. This issue will be corrected in the final release of XNA Game Studio 2.0.

Nov 20, 2007 at 4:04 AM
First Impressions:

  • The new parameterized content pipeline is nice. Same functionality as before, but now properties can be exposed that appear in the Visual Studio Properties sheet for content files. i.e. in the content processor you can write:

[DefaultValue(typeof(MyEnumeration), "Option1"), Description("My description"), DisplayName("My Property")]
        public virtual MyEnumeration MyProperty
        {
            get
            {
                return prop;
            }
            set
            {
                prop = value;
            }
        }

and you'll see "My Property" in the property sheet for any content file using this processor, along with a list of all valid enumerations of type MyEnumeration. This seems to work for all simple data types, as long as you can represent it as a string, int, float, etc. It'll even display whatever you put in the description annotation in the property sheet when you click on the property. This also extends to chaining in the content pipeline, as a content processor can now invoke a build of a needed dependent by importer name, processor name, and collection of properties, instead of just a processor name like in 1.0.

  • SpriteFont is much better. Fixed-width support seems good. Though, as the beta is Windows-only, I cannot test that the memory leak is fixed on Xbox.
  • VS integration is largely different from what it was in C# Express. Instead of content files being treated like source files, content files are in a separate sub-project under the game project, with its own set of assembly references. This is a nice move, very intuitive.

That's about all I've seen so far, other than superficial differences like LoadGraphicsContent became LoadContent. I'll try to take a look at the networking features once I get the beta LIVE key you need to sign up for.
Coordinator
Nov 20, 2007 at 4:39 AM
Awesome, can't wait to play around with it.....all night long :)

I wonder if it worth porting my GSE1.0r template over to it, it should take too long, and it might be nice to do some benchmarks to see if there are any improvements. I wonder if I run the CLR against it if it'll be any worse or better? Lots of interesting questions.

I don't predict massive changes between this beta and the actual 2.0. There were quite a few between 1.0beta and 1.0, but I don't that will be the case for 2.0beta and 2.0.
Coordinator
Nov 20, 2007 at 4:49 AM
Ha, just saw that I don't have to do much porting, there is a converter!
Nov 20, 2007 at 4:55 AM
A benchmark may be interesting if you're using a lot of XNA library code. What do you mean by running the CLR against it? On Windows, XNA runs on the same CLR as everything else, namely the .NET 2.0 Desktop CLR. XNA 2.0 doesn't provide a new CLR, nor did 1.0. XNA and the CLR is only bundled together on the Xbox.
Nov 20, 2007 at 7:01 AM
Should we shift the prototype over to GS2.0? And who should do it?
Coordinator
Nov 20, 2007 at 7:19 AM
I mean CLR Profiler against it, to see if there are any improvements on GC, like the spritebatch. However I'm not sure any issues for GC exist on PC, like the spritebatch does on 360.

I'm currently shifting the template over, and it was remarkably easy. The only real changes were to the index and vertex buffer declarations and render targets. There is still a small bug with the water shader in debug mode. I've got everything working except the water component. I'm too tired to post it all or finish it tonight, but I will try and get it up tomorrow.
Nov 20, 2007 at 7:30 AM
I don't think you should shift the template over, it's a "released" software and shouldn't be using beta a platform. But you could provide a readme on how to convert it to 2.0beta, though it should not be supported. Having the prototype as on the beta framework makes much more sense.
Nov 20, 2007 at 6:19 PM
XNA is so immature at this point that I don't think it really matters that its beta software. Until XNA becomes a platform for gamers/users in addition to developers, I think keeping with the latest release of XNA is the way to go. Especially once 2.0 retail hits in a month, no one will be using 1.0.

How much more are you planning on doing with the template?
Coordinator
Nov 20, 2007 at 7:28 PM
I'm planning to get the template moved over as soon as we finish design, most of the changes are waiting until after then. Anything before then is just minor changes.

I figured it'd be good to get it converted to 2.0beta before I integrate it with the prototype, which I believe should be 2.0beta while were designing it. By the time the prototype is ready for use 2.0 retail will be as well I believe. If we start with 2.0beta for the prototype, it will make the transisition to 2.0 retail much easier.
Nov 20, 2007 at 7:32 PM
I'm just concerned that there might not be a midigation story from 20beta to 20release, as it's not always that beta software is supported when the release is provided, and example of this is phpBB (non-ms though) which has hit me a few times.

Nov 20, 2007 at 7:54 PM
Once 2.0 retail hits, the template should be verified to work as in 2.0 beta, of course. Then, it doesn't matter what happens to 2.0 beta.
Nov 20, 2007 at 8:02 PM
I just think that there are more important issues to focus on than to convert the released template engine into a beta stage. The focus should really be to get the plan for the next engine finalized so we can start on it.
Nov 20, 2007 at 8:08 PM
I agree, but its really only a matter of running the project through the provided project converter. If it would take a significant effort, then I wouldn't bother and just concentrate on the new framework.
Coordinator
Nov 20, 2007 at 10:27 PM
If I find how to extract a Texture2D from a rendertarget in 2.0 I'll already be done with the conversion of the template.

There are really not a whole lot of changes that will affect any code we're already using. It took me about 10 minutes to convert the entire template if you exclude a small bug with debug versions of shaders and some new syntax I had to learn.
Nov 20, 2007 at 11:14 PM
What are you trying to accomplish? Why do you need the Texture?
Nov 21, 2007 at 12:36 AM
What's wrong with using RenderTarget2D.GetTexture()?

Or are you trying to use the new ResolveTexture2D? In that case, ResolveTexture2D is a Texture2D. Just call ResolveRenderTarget(myResolveTexture), then use myResolveTexture as any other texture.
Nov 21, 2007 at 12:58 AM
If you are trying to take a ScreenShot you can do something like this:
        /// <summary>
        /// Takes a screenshot of the current scene and saves it to disk
        /// </summary>
        protected virtual void TakeScreenshotCore()
        {
            using (ResolveTexture2D destinationTexture = new ResolveTexture2D(
                    ThunderGame.GraphicsDevice,
                    this.Camera["default"].Viewport.Width,
                    this.Camera["default"].Viewport.Height,
                    1,
                    SurfaceFormat.Color))
            {
                ThunderGame.GraphicsDevice.ResolveBackBuffer(destinationTexture);
 
                string filename = string.Format(@"screenshot\Screenshot - {0}.{1}.png", DateTime.Today.ToShortDateString(), DateTime.Now.Ticks);
 
                destinationTexture.Save(filename, ImageFileFormat.Png);
            }
        }
Nov 21, 2007 at 4:25 AM
Looks like we're not going to be getting any more information on the Xbox CLR for 2.0; no technical documentation, no documentation on the "improvements" made for 2.0, just some more short XNA "tutorials" on writing performant code. :(
Coordinator
Nov 21, 2007 at 5:28 AM
Here's a snippet from the water refraction function

Device.SetRenderTarget(0, RefractionRenderTarg);
            Device.Clear(ClearOptions.Target | ClearOptions.DepthBuffer, Color.CornflowerBlue, 1.0f, 0);
 
            foreach (DrawableComponent thisComponent in RefractedComponents)
                thisComponent.Draw(gameTime, ref ViewMatrix, ref ProjectionMatrix, SceneLight, CurrentCam);
 
            
            Device.ResolveBackBuffer(RefractionMap);
            Device.SetRenderTarget(0, null);

When I set the render target (on the last line) to null I get an error "This device does not accept null as a value". However the actual parameter 'null' that I am passing the rendertarget is not what it is referring to. If I put a render target in place of null I still get this error.

If I don't call SetRenderTarget than the following line (which sets clip planes back to normal) breaks.
Coordinator
Nov 21, 2007 at 5:34 AM
the xbox is unfortunately limited, but it'll be good practice of making high performing code on limited hardware, such is very common in the gaming industry.
Nov 21, 2007 at 5:44 AM
I don't know if this will help http://blogs.msdn.com/shawnhar/archive/2007/02/04/xna-rendertarget-semantics.aspx
Nov 21, 2007 at 5:47 AM
I'm not talking about hardware, I'm talking about the software tools. The Xbox hardware isn't limited, it's quite good. It's the Xbox CLR that's like a black box and only the XNA team knows what really goes on inside of it. Someone with an XDK can compile C/C++ code and look at what PPC code is generated. Knowing how the compiler handles loops and repeated memory accesses can be very important in tight-loop code, where preventable cache thrashing and not keeping variables in registers can hurt performance by a significant amount, even ignoring some of the more traditional compile-time code optimization techniques.
Nov 21, 2007 at 6:49 AM
I totally agree on the fact that performance is key. But I don't think that we should waste lot of time investigating all the possible performance flaws in the Xbox CLR. I think that we should write a engine that works, and use the techniques we know, then once we have a working engine, then we can start profiling it on both win and xbox.

This is most likely going to show that some things work on one platform and not the other. And that is the reason why everything should be implemented using a plugable pattern, which will allow us to replace parts of the engine depending on the target platform (similar to what should be done in the networking area). Though for those using our engine the API stays the same, so they should only be considered writing the most performant game possible.

I do realize that we won't be able to write the most performant code all the time if we can't change the API depending on the platform, but that's a tradeoff I don't mind paying.

I do here assume that we are writing an engine targeting both windows and xbox, otherwise the above statement isn't valid.
Nov 21, 2007 at 1:44 PM
Getting software to work is the first step, yes, but I'm talking about once it works and you need to squeeze more performance out of some of the critical sections (identified through profiling) where the algorithms are already as efficient as possible. With the XNA software tools on Xbox, this becomes a strictly empirical process. You don't know what the IL -> PPC assembly translation is, so you have to guess. Imagine the following:

for i = 0 to N do
    for j = 0 to N do
        A[i, j] := <some combination of accesses to arrays A and B based on i, j>
    endfor
endfor

If you need to optimize this, it becomes very useful to know how the compiler (or in this case, the CLR) is going to generate code for it. Is there a direct translation, which is most likely inefficient? Will it attempt to partially unroll the loop to help cache access patterns and limit the number of potentially mispredicted branches? Will it make efficient use of registers to store intermediate results across loop iterations? If you know the IL -> PPC translation, you can predict what code is going to be generated and massage the C# to compile down into the IL you need.

Clearly, this is a case-by-case process and not all projects will need to concern themselves with this. What bothers me is that the software tools aren't available in XNA for Xbox, mainly just for legal reasons.
Nov 22, 2007 at 12:33 AM
I wouldn't be too concerned about that at this time. At the time where we get to profiling and worry about tight loop iterations, the framework version is prob on the other side of 3 :)

Though I do agree that we should keep profiling in order to dertermine any alarming pitfalls, even if it's windows only. Many perf hits will be the same on both targets as they are structure releated and not hardware related.
Nov 22, 2007 at 1:16 AM
You're right, it's not a big issue at this time for this project, I was more referring to in general for other projects, and the general feelings of the XNA team that indicate that these things aren't important and won't show up in future releases.
Nov 25, 2007 at 12:22 PM
Does the latest source release support the 2.0 Beta? I keep getting errors, such as the template not being supported by my installation. If the beta is not supported that could be my problem.
Nov 25, 2007 at 12:42 PM
The 2.0Beta isn't supported in the current bits.
Coordinator
Nov 25, 2007 at 5:25 PM
2.0 isn't in the current source, but it is supported in the current release, v0.181