Thanks to everyone that attended my presentation on “XNA Development Creating Games For Windows, Xbox 360, and Windows Phone 7.” As promised, here is both the source code and the power point presentation. Feel free to ask any questions you may still have, and I will get back with you as soon as I can.

This is a sample pong XNA game that works on Xbox 360, WP7, and Windows.

If you have been doing any kind of Silverlight or WP7 work then you are probably already aware of a property called CacheMode on all of your controls. This magical little property can improve the speed of your applications by caching the visuals instead of redrawing them every time.

This was EXTREMELY noticeable when I converted Zero Gravity to WP7. My jaw literally dropped to the floor the first time I ran the game. The speed was far from adequate… In fact the game was barely able to run. Here I saw demos at Mix with a device that were able to run full 3D without so much as a flicker; and here this very, very simplistic game was being brought to its knees. There is hardly any animation the screen is full of mostly static content. So how could this be performing so very poorly?

Of course with a liberal dose of the CacheMode=”BitmapCache” the application soon started to perform pretty well. But, did I use CacheMode correctly? Should I have included it on more elements? None of them? All of them? I am left with a problem of knowing “when is the application optimized to its peak efficiency?” This begs the question…

Why do we need CacheMode=”BitmapCache?”

Asking a developer to handle caching like this is like asking a 2nd grader to do their homework and then leaving them alone and unsupervised. Sure, some kids will buckle down and get their homework done, but more often then naught the 2nd grader is going to get distracted. This could make them take longer to do their homework or worse yet they won’t do it at all. (I know playing a game on Xbox would seem pretty awesome compared to doing homework!)

Caching is something that should absolutely be taken care of by the framework. Nobody is going to know performance enhancements better than the developers that create the API’s we all know and love. Go watch Seema’sperformance presentation at Mix10 for an example of how complicated performance can be. Sure, there may be edge case scenarios that require developers to reach in and take the reigns, but by taking the initial performance enhancements out of the hands of the developers you ensure that EVERYONE will participate “out of the box.” Seema’s presentation illustrates how very fragile the current Silverlight rendering pipeline is. Anything we can do to remove “problem points” can only help the framework in the long run.

There are many Silverlight (desktop) applications in circulation today do not implement CacheMode at all. They didn’t need to because the applications ran fast enough on today’s beefy computers. But imagine if all of these applications were optimized from the start! The UI could be more responsive and CPU usage could be reduced without the end developers writing a single line of code, and THAT is what we should be striving for.

Lets hope that future versions of Silverlight take control so everyone participates. Opt-out, not Opt-In.

Well, it looks like I do have an author (Author="DigitalTransfusion.Silverlight.Wp7.Project.Client author") so what is going on here? Well it turns out there is a character limit 50 characters for an author.

So this got me thinking, I wonder what the the character limits are? Well, wonder no more!

Publisher = 50 characters

Author = 50 characters

Title = 80 characters

So if you get errors for ValidationInvalidPublisher, ValidationInvalidAuthor, or ValidationInvalidTitle, chances are that your strings are too long.

In a previous post I released the source code to Zero Gravity. In this post I am going to dive in and explain the changes that had to be made to make the game ready for Windows Phone 7. I was actually surprised at how little actually had to change considering the code was originally written back when WPF/e was still walking around.

There can be only one!

The original game was written with a lot of MediaElements. The sound effects were loaded using something like this:

There are a couple of problems with this in Wp7. The first problem is that the MediaElement.SetSource method no longer accepts a type stream(even though the intellisense says it does). Instead it requires an IsolatedStorageFileStream. Whether this was a bug, or an intentional change, A quick fix would seem apparent:

Of course, you would notice that this effectively doubles the storage space needed for the audio files (once in the .xap, once in isolated storage). That isn’t a good thing, but with a little management you can make sure the application cleans up after itself…but there are more problems.

If you were to run this in the game, you would find that the background music would work. However nothing else would work. The movie transition between levels would fail and there would be no sound effects as you move around the boards. Needless to say, it is a very bad user experience.

So what is going on?

One thing that a lot of developers forget about with regards to Silverlight on Windows Phone 7 is that you can only have 1 active media element. In fact I forgot about this little tidbit of information, and had to be reminded of this fact. (Thanks Bill!) For anyone else that needs a reminder, I recommend watching Davit Cutler’s presentation from MIX 2010.

So what is the solution to this? Well, on Windows Phone 7, there this is a little bleed over beteween XNA and Silverlight. The solution is to use the XNA framework to handle all the audio. For the ease of transition, I kept the movie inside the MediaElement (since I am allowed to have one).

To make this work, I added a reference to “Microsoft.Xna.Framework.” This gives us access to the Microsoft.Xna.Framework.Audio.SoundEffect Class, which is used in XNA to play sound effects. So now the code to load the audio files went to something like this:

Note: I could be wrong here, I am not an expert in XNA, but all audio files had to be converted to .wav files. The desktop MediaElements accepted the .mp3 file format, so there was an increase in size in the WP7 version.

Night of the living dead

The next change from the desktop version stems from the fact that the phone can’t multitask (at least not yet). So when the game is interrupted by something (maybe a phone call, or someone needs to check their email) it is a best if the game doesn’t dump them out to the main game menu when they return (leaving them to start completely over). This is accomplished by a process that has been dubbed “Tombstoning.”

In the app.xaml.cs file there are four methods to worry about if you want to implement Tombstoning:

Application_Launching

This is ran when the game is started for the first time. Otherwise known as a cold boot. It does not run when the game is resuming.

Application_Activated

This is ran when the game resumes from being put into the background or unloaded. This process has been referred to as “reanimation” (the process of coming back to life after being deactivated/unloaded).

Application_Deactivated

This is fired when the application is “interrupted”, but not shut down. So if you answer a phone call, swap to another application or just press the windows key.

Application_Closing

This is fired when the game is being closed down, but not when the game is being deactivated.

So what does this mean for the game? Well if there is an active game and the user decides to press the windows button I want to store off the current level and score, and restart the user from the beginning of that level. This is accomplished by putting the following code into the Application_Deactivated:

How do I get there again?

One of the biggest differences between WP7 and most desktop environments is the user interface. that is to say that on the computer you have a keyboard. On a WP7 device you use gestures to get around, and it only makes sense to use swipe gestures to control the direction Lt. Bennett goes.

There is a really nice set of gesture helpers inside the wp7 Silverlight Toolkit. They make wiring the whole thing up a lot easier.

Always check performance with a device

I can still hear all the presenters at MIX reverberating the same message in every single session, “always check the performance of your app with a real device before deployment.” This cannot be understated. The emulator works fine, but generally performance on an actual device is even slower (though they have brought the difference between device and emulator speed differences down considerably).

The game runs at 60 FPS on a desktop without any issues, but if you did a straight conversion the game stutters a lot. Animations flicker, animations skip frames, and in general it just runs slow (15 FPS at certain points).

What this means is that you have to go through your code and basically copy/paste CacheMode=”BitmapCache” into many, many areas to help ensure that the game is sufficiently cached. This keeps the compositing on the GPU and not on the CPU, allowing there to be more clock cycles to process things like game logic. This equated to a HUGE difference in gameplay and animation speed.

While this is a really simple thing to copy/paste ClientMode, it is error prone. I can’t for the life of me figure out why the Silverlight team decided to leave performance enhancements like this to the developer and not to the underlying framework. If we leave it to the developers, there are going to be a lot of applications that don’t use the settings at all, or miss setting a few key objects here and there. But since it is left to the developer to do it, don’t forget to go through and test your application. “App.Current.Host.Settings.EnableCacheVisualization = true;” is your friend in this matter, so use it.

And that is it!

The rest of the application is exactly the same as the desktop version. While I know the code base is old, and by no means follows any of the modern patterns (lets face it, we were writing against an unknown architecture at the time), it is still a testament to how good a job the team is doing at backwards compatibility.

I for one was very shocked that the transition went as smoothly as it did.

It seems like only yesterday that Tim Heuer was showing off Zero Gravity and the lovable antics of Lt. Bennett. It is hard to believe that was over 3 years ago. The Silverlight platform has grown up by leaps and bounds in that amount of time, and with the looming release of Windows Phone 7, it seems only fitting that I get the opportunity to go back an take a look at the first game built in Silverlight with the intent of bringing it to the modern age. That’s right, Zero Gravity is now available on WP7 as well.

What amazed me the most out of this whole experience is that the codebase written back in WPF/e was able to be recompiled with very little modification into the latest version of silverlight. Sure, there were a few namespace changes, but nothing in the code needed to structurally change. Even the old way of using a pre-loader (back before there was such a thing as a “splashScreenSource”) runs without a hitch. In my next post, I will go into the changes that were necessary to get the game to work in WP7 but until then…

Just give me the source!

So without further adieu, I give you the source code for the original zero gravity

It sounds like a pretty bold statement, but it is true. There is a way to break the built in Silverlight 4 splash screen loader. Most people will probably never see the problem. I only found this bug because the website I am building uses an Akamai caching network that was mis-configured. It was an honest mistake because not everyone is used to using the .xaml mime type yet. IIS 7 works correctly out of the box and shouldn’t have this problem. Anyway, here is what is going on.

The setup

Just to make sure everyone is on the same page, here is the setup I will be using. All names have been changed to protect the innocent.

What is going on?

if you look at the following picture:

In the first pass through (fiddler capture 1), you will see that the application loads both the .xap and the splashloader.xaml. (200 response) Neither are cached. The application loads just fine because the .xaml page has a chance to download an instantiate while the .xap file is still being downloaded. The progress bar updates correctly, and the world is happy.

Where this process breaks down is if you don’t have .xaml files allowed to be cached, but the .xap files are. (fiddler capture 2) You can see that the .xap file is already downloaded and trying to instantiate while the .xaml file still needs time to download. Because the .xap is already loaded and ready to go, there isn’t ever a “download progress” tick, so the splash screen hangs at that point.

To prove that it works with caching, you can use Fiddler’s AutoRespond (or something like it) to reply back with a code 304. the file is loaded locally, and it begins to load again.

In summary

Like I said at the beginning of this article, IIS7 works correctly out of the box. If you find yourself in this situation, check your settings, and make sure that the.xaml pages can return a 304. I honestly don’t know if you can even break this in IIS7, but for people using other caching networks, web accelerators, etc…it is entirely possible to miss this setting.

It took me a lot of troubleshooting to figure this one out, so I hope this post helps someone out there save a few hours of mind numbing debugging. We can only hope that this is fixed in SL5.

One of the most maddening things in the world is when you have a problem with your application, but there isn’t an error code. Well recently I had such an error, and I hope I can save a few people from ripping out their hair.

IIS7 appears to work correctly, but after loading a single page it just stops responding to anything. No errors are given, the website just times out. Sometimes it would load half of the page before it would fail, so you would get to see what your page looked like without CSS. Not even raw images come up in a timely fashion.

If these symptoms sound remotely close to what you were seeing you have probably looked around the net and seen the threads about a problems with IIS7 and FF. The fix was to increase the timeout of worker threads. I have a hard time believing that increasing a timeout value is at all beneficial. (websites are supposed to load quickly right?) Besides, I was using IE so it didn’t make sense.

It turned out to be AVG.

I am not sure if a new tweak to the resident shield is to blame, or something else, but having AVG installed on my machine causes IIS7 to lock up on heavy sites. Disabling AVG didn’t help. I had to completely remove it for the website to work.

I hope they figure out what the problem is and fix it soon, but in the meantime I will have to make do without AVG.

My blog posts have been delayed for the simple fact that I haven’t had internet for over a week (aside from my phone) Apparently my ISP had a serious problem that impacted the entire region. It took them a while, but they finally got to it. But, I just don’t have the patience to type a blog post of any real size from a phone.

So, with that said, I will be doing the next installment of my Deep zoom tutorial this weekend.

What is Deep Zoom and how can it benefit my site?

Traditionally whenever a website has a lot of images to share, they put up something called an “image gallery.” The images are usually placed in a grid (columns and rows), and there is usually some sort of paging. This works, but there are problems.

There are usually only a few images visible at a time.

The client computer must make a connection for each and every image that is viewed. (even thumbnails can take up a lot of bandwidth)

If an image gallery is pretty active, there can be a LOT of pages.

If someone wants to look at the original size of the images, they are forced to download the larger version one at a time, often with a clunky interface.

Depending on the dimensions of the original image, the thumbnail can be very blurry when shrunk down to fit into the smaller size

Deep Zoom allows for you to display any number of images that are many different sizes in a single collection quickly and easily allowing users to go from one image to the next, without having to worry about paging, or waiting for the next image to download.

Deep Zoom creates pyramids of “smaller” jpegs that make up a single image. This means that only the image of the needed quality level is downloaded. Initially only really low quality images of the entire collection need to be downloaded. As a user zooms in to an image that interests them, only the details for that image start to download to get a “more clear” view of just that image. If the user pans around the collection, only the details for the new images are downloaded.

What does this mean for you? If you happen to have a site that has a lot of images that nobody wants to look at, the highest quality of that image is never downloaded. This means less bandwidth is used, and often times that can save you money at your web hosting provider.

In addition to saving you money in bandwidth, you can create very rich user interfaces that allow advanced filtering and animation. Say for instance you filter your image search results. You can animate all of the “images that match” into position while animating the non matches off the screen.

Simply put, if you have a lot of images that you want people to look at, you should be using deep zoom. You can implement searching, filtering, and give descriptions on selected photos, all while sending the bare minimum amount of data needed to view your collections. This results in a lot of saved bandwidth, and gives users a much richer experience over the traditional “thumbnail/paged” approach of so many photo galleries.

Building your first collection with Deep Zoom Composer

Before we get into the nuts and bolts about how deep zoom works, lets get a basic collection of images created. Deep zoom composer can be downloaded from here.

After installing the application, run it. You will be greeted with the following screen:

Click “New Project…” and enter your save location and name. Click OK.

The project is now created, but you will have to add your images to the scene. You can Tell you on the import screen by looking at the navigation at the middle/top of the page.

To add images you can either use the “Add Image…” button on the right pane, or just drag and drop files from windows explorer onto the work area. Once you have done this, you should see something similar to the image below.

When you are done adding images to the scene, you click on Compose (top/middle navigation) and you will be greeted with a blank canvas.

Select all of the photos in the bottom area and drag them up into the scene.

You will notice that the default layout is not very desireable, so lets put them into a grid. Make sure all images are selected and right click them. Choose “Arrange…” and then “Arrange to grid…”

Once you are done, hit OK and you should get something like this.

We want to get these images out into a deep zoom project for preview, so click export on the navigation (top/middle). You will see a quick preview in the window pane, but on the right hand side you will see a few ways of exporting these images. Click on the “Custom” tab

Give the export a name and location. You can leave it on the default template/settings and then click “preview” (I will get into the settings more in depth in later posts once we dive into the code.)

You can see that the images all exported and the Silverlight project loaded up in the browser. Mission accomplished right? Well, while it is true that I exported images, there are a few things to concider. The images are very spaced out vertically. Nothing to worry about though, lets go back to Deep Zoom Composer and click back to the “Compose” tab (top/middle) you can click on individual images and resize them manually. When you move images around you will notice snap bars that will help you position images, and then drag them all to have the same height. Do this for every image to get something like this:

This collection looks a lot better. Unless you chose images that were all the same size the widths will vary a little, giving this staggered effect. You can spend a bit more time playing with the alignment tools and figuring out how you want your collection to look, but once you are done, go back to the export tab. Under our custom settings, change the template to be “Deep Zoom Classic + Source”

You will see that you can’t preview, which is fine. We want to export the project. this will give us a base project (complete with .sln file) that we can look at in depth later. After the project is exported, you can click the option to “view in browser”

The images are all exported, and they are all butted up next to each other! This looks a lot better, and people are more inclined to click on pictures that are barely visible past the image that has focus.

Thoughts on Deep Zoom Composer

Deep Zoom Composer is a fully capable tool for generating small, static collections. The problem is that most of the time you will need to update your collections periodically. If a collection that has 1000 images in it, it is going to be a very long and tedious process to position each and every image to where you want it.

The templates are also very generic. Most of my clients have wanted a very custom set of controls and branding to be applied to the collection viewer, So most of the time the templates that are there by default just won’t work. Luckily they give you a few templates with source code, so you can get into the nuts and bolts of how everything is stitched together, but it will still take some time to learn what they implemented.

Probably the biggest (and final) drawback to using Deep Zoom Composer is that there is only really 1 “meta tag” you can use to supply information to your images. “Tag”

This works well for the limited templates they have, but what happens if you want to add a long description, a short description, a link for sharing, a video that starts playing if you click on the image? There is nowhere to add any of this metadata.

Luckily, Microsoft knew this tool wouldn’t fit everyone’s needs, and as a result they left us with an SDK of sorts. This means that we can programmatically create our collections and FTP the files up automatically. You don’t have to manually position images anymore. We can choose exactly how we want our images to display, and at what zoom levels they should be at.

What’s next?

Next in the series I will be tackling deep zoom from a programming level. I will show you how to programmatically create images and collections. I will reveal how the coordinate systems work, and how to get your images into a format you want. I will also give concrete examples that will help you decide if you should use a Sparse Image, a Multi Scale Image collection, or a hybrid of the two.

My first few posts will be around deepzoom. How it works, the math involved, and will end with a fully functional module you all can use in your silverlight applications. I did a few applications that used deepzoom on very large image sets, and to say that the math involved was foreign to me is an understatement. Nevertheless, I plan on demystifying as much as possible to save others the headaches I suffered in learning the technology.

After that, I have ideas for what I want to blog about (and I will definately get those blog posts written), but i am also interested in what you all want to see me write about. I am very heavy into Silverlight/WPF at the moment, but I can definately speak on a lot of other subjects. So tell me what you want me to write in the comments below. You may just get your request! 🙂