Category Archives: XNA - Page 2

Dean’s opened his new site

My coworker Dean has opened up his new website now, you can go check it out!

My new project!

After I left the XNA team last year, two of the most popular questions I was ask was why I left and what I was going to do next. It was hard to really formulate a good response to either given the general culture of secrecy that seems to always be around. However, now is the time to lay it all out on the line!

First, why did I leave to begin with? Philosophical differences I suppose you could call them. I was pushing very hard to get a LISP and COBOL version of the project out, and they didn’t think it would have a large enough audience. I still can’t believe they were so naive, but c’est la vie.

When I left I had a multitude of opportunities available to me, each of which were very compelling. Right when word got out I was leaving, I was contacted by the good folks at a new team that was forming. They had discovered that certain images in certain sequences could actually change the chemistry in the brain and give the user experiencing them a completely new outlook on life. The government wanted to get involved though, and I’ve worked with the government before. The technology was exciting, but not enough to work with them again.

Yet another group offered me a new job which sounded at first glance to be quite boring. Have you seen those big number signs where they’re constantly increasing with witty phrases such as “Your share of the national debt is <blah>”? Did you know that Microsoft wrote that software? I was offered the chance to be the guy who watches the numbers scroll by and make sure they stay accurate. Sure, it sounds boring, but you get to travel the world and see lots of numbers, how bad could have it been? Everyone loves numbers!

However, the job I finally took was over in Microsoft Game Studios working on an amazing new title. I probably shouldn’t be telling anyone this, but I’ve been holding it in so long, I just can’t wait anymore. What’s the worst they could do? I’m proud to announce our new game Kinectodeck. Everyone has seen how amazing it can be when you’re the controller, but we wanted to see how amazing it could be if you were actually in the game!  We use an amazing set of new technlogies to transform your living room into the actual game playing field. There are eight different Kinect sensors spread throughout the room along with sixteen mini-projectors which bring the game world directly there! It is a completely new innovative experience, where the possibilities are really limitless.  One of our recent test subjects was sent on an safari adventure where they were out riding a tiger through a lake:

We have a few bugs we still need to work out though. For example, due to our desire to have maximum realism, we may have went a little overboard. Shortly after the picture above was taken, the tiger ate our poor test subject. It’s ok though, she signed the release form. Minor setbacks, something you would expect from such an ambitious project. Major innovation doesn’t happen by being safe!  We’re moving quite fast though, and an expected release date should be just about a year from now, and I can’t tell you how excited I am.

You may be wondering how you write the games though? Why XNA of course!  You will of course need an AppHub membership to get the toolset. I’m also happy to announce that the toolset will be available for download (in a very early alpha form) next week! Stay tuned for more information, this is an exciting time in our industry and I am ecstatic to be a part of it.

Sometimes I don’t understand book reviews..

Not that I have any complaint about them, it’s just odd. For example, my latest book only has a single review, but the review is glowing and the best it could be.  Now, I naturally don’t know how other books are doing, but I am a little obsessive compulsive, so I do watch the average Amazon sales numbers, and compare them to how my book has been doing. Generally, in the category the book is in, we do very well (which is awesome), yet I see other books doing much worse in the average sales with many more reviews and I wonder why? Does their publisher try to prime the channel with reviews? Pay people to give reviews? Maybe those books just give people the overwhelming need to tell others about them, where ours does not?

I also know that our book isn’t perfect, I’ve seen mistakes in there.

I’m curious though, what do you think about the book? Like it? Hate it?

Visual Basic for XNA?

So it seems that it was annouced today that XNA is coming to Visual Basic! I have to admit the announcement caught me a bit by surprise. As one of the people who has had to investigate (at various times) what it would take to make this happen, I have no idea where the team has gotten the time to do this! As the article says though, it was one of the most popular feature requests I can remember though so it’s good that it’s finally happening.

Wish there was more information though. For example, when is it coming? Is it coming on all the platforms, particularly Xbox? The picture in the article implies it will, but that doesn’t necessarily mean anything. I know they said to wait a few months, but given people have been waiting for literally years at all, I wish they would have waited until they could give us all the information rather than teasing it early when they cannot.

Although, I suppose I could be in the minority in thinking that. Some folks just like be teased and waiting a few months.

Loading… I hate loading…

I guess I’m impatient, because there are very few things that annoy me more than loading screens. In a world of instant gratification, waiting for any significant amount of time is unacceptable. Hell, I’ve only just started typing this and I’m already annoyed that I’m not finished yet. Loading just bugs me, and I see it creep a lot on Windows Phone 7 games. Perhaps I should ramble on about that for a while.

The first goal of the game should be to show me something on screen as soon as possible. While you can “somewhat” use the splashscreen.jpg trick to show something quick, in XNA applications, it doesn’t stay on screen long enough and looks awkward (in my opinion).  I personally would rather show my splash screen on the first render.  However, that leads me to another common mistake I see people making, and that’s loading a bunch of content (or all!) in the LoadContent method.  This is certainly a bad idea if you want to show something on screen quickly. This is essentially the order you will see things happen at startup:

  1. Game’s Constructor is called
  2. Initialize is called
  3. LoadContent is called
  4. Update is called
  5. Draw is called
  6. Goto 4.

While there are certainly nuances here, that’s the basic order, and notice that Draw isn’t called until way at the end.  I’ve seen people decide that the best way to fix this would be to draw something in LoadContent, and then they implement that, see that it works and call it a success. If only it were so easy. If your application is starting up once more after being tombstoned, essentially the same sequence of events happens, however there is a caveat this time.  While the “startup sequence” is happening, the phone will be displaying the “Resuming…” screen (my how I dislike that screen), and will not show anything from your application until the “startup sequence” has finished. In this case, the sequence doesn’t finish until *after* LoadContent has finished. So if you showed something on screen early in your LoadContent method, and then loaded a bunch of content, it would work in the initial startup scenario, and potentially fail in the restore from tombstone scenarios.

The easy way to get around these issues is to do all of your content loading (aside from the first thing you want to see on screen, such as a splash screen) on the second update call.  This allows you to show something on screen quickly in both the initial startup and coming back from tombstoning cases, and if you don’t have much content, should be sufficient enough. Your splash screen image will stay static on screen (and your application is essentially non-interactive) while the content is loading. If it takes more than a few seconds to get to this state though (ie, you have too much content), you have more work to do.

The most common thing I see happening here is the game will load only the content needed for the main UI portions, and will force you behind a loading screen after you choose the level or what have you. Again, this works perfectly fine, but we can do so much better! Why can’t you load everything you need while I’m playing around with the UI? For ease of explanation, let’s say that you are making a 2D game, and you have a large list of strings that are all the sprite textures you will need to load. What if you had a class such as this:

public static class BackgroundLoad
{
    // The thread that will load everything
    private static Thread loadingThread;
    private static Game game;

    /// <summary>
    /// Returns true when the background loading is complete and
    /// false otherwise
    /// </summary>
    public static bool BackgroundLoadingComplete
    {
        get { return (loadingThread != null) ? !loadingThread.IsAlive : false; }
    }

    /// <summary>
    /// Start background loading all assets
    /// </summary>
    public static void Go(Game g)
    {
        game = g;
        loadingThread = new Thread(BackgroundLoadThreadMethod);
        loadingThread.Name = "BackgroundLoadingThread";
        loadingThread.IsBackground = true;
        loadingThread.Start();
    }

    private static void BackgroundLoadThreadMethod()
    {
        // Imagine this was filled with your asset names
        List<string> assetNames = new List<string>(); 
        Action<string> loadTextureAction = new Action<string>((asset) =>
            {
                game.Content.Load<Texture2D>(asset);
            });

        foreach (string asset in assetNames)
        {
            loadTextureAction(asset);
        }
    }
}

So long as you called BackgroundLoad.Go(this); sometime after you started up, your game would dutifully start loading all of your assets behind the scenes in a background thread.  This isn’t a foolproof solution though. For one, you have very little control over background threads on Windows Phone 7. You cannot change priority, and you have no control over how much they will execute (although on average for every 4ms your main thread is executing your background thread will run for 2ms).  In this example, you are also using the graphics device on another thread, which will take out a lock to avoid multiple threads manipulating it at the same time. In the larger scheme of things though, it’s still probably faster in this mechanism than without.

You will notice two potentially useless pieces of code here as well. First, a property to dictate when the loading has been complete, and a second in which the actual asset load is happening within an action rather than directly in code. The property is self explanatory if you think about it, you still need to know when all of your content has been loaded so you can allow the user to start the game! This just gives you easy access to it.  The action delegate is slightly less obvious though.

What should you do when the user has gone through the UI and is ready to play the game but the content isn’t done loading? As was mentioned earlier, you don’t have any control over the background threads execution time, and because it is running half the speed as the main thread, as the code is written now, your loading time could potentially be *increased*! This is most definitely not what we wanted. What you really want is a mechanism where you would load things in the background if the user was still messing around with the UI, but will switch to loading in the foreground if the user was waiting on loading, and that is what the action delegate is for. If you replaced the code in the thread method with the following, you will get this behavior:

private static void BackgroundLoadThreadMethod()
{
    // Imagine this was filled with your asset names
    List<string> assetNames = new List<string>();
    AutoResetEvent resetEvent = new AutoResetEvent(false);

    Action<string> loadTextureAction = new Action<string>((asset) =>
        {
            game.Content.Load<Texture2D>(asset);
            resetEvent.Set();
        });

    foreach (string asset in assetNames)
    {
        if (game.UserIsWaiting)
        {
            Deployment.Current.Dispatcher.BeginInvoke(loadTextureAction);
        }
        else
        {
            loadTextureAction(asset);
        }
        resetEvent.WaitOne();
    }
}

Now your code is loading in the background while the user is messing around with the UI and will switch to the foreground once they’re done. In the degenerate case, this is still slightly slower than simply forcing them to wait at a loading screen, but given the degenerate case is almost certain to never happen, a mechanism such as this will (for most intents and purposes) always be faster. It certainly took me long enough to exlain all this, I should have had a loading screen for this post…

As a final caveat, this was an extremely simple example of multithreading. If you do anything more complex and don’t have knowledge of multithreading (or what the ‘lock’ keyword does), you should probably read up a bit on that!