Understanding the Device

The Zune player, while comes in different form factors, has the same capabilities across the board except for the storage size it has. All Zune devices have the following characteristics:

• A screen resolution of 240×320 pixels. This is regardless of the physical size of the device. The resolution is the same.
• An internal storage medium that is either flash or hard drive based.
• The biggest size game you can create is 2GB.
• The amount of memory available for your game in total is 16MB. This includes your code in memory, data, textures, sounds, etc. Take away some memory for the XNA Game Framework and you realistically have around 12MB of memory to work with.

So what does this mean to you as an aspiring Zune game developer? Well… the most obvious factor you have to consistently keep in mind is that 16MB of available memory. If you don’t take that into account and just code away, I guarantee you that your game will run out of memory pretty quickly.

Memory on the Zune

As I mentioned above, you have a total of 16MB of memory to work with for your Zune game. If left unchecked, your game will probably run out of memory leaving you quite unhappy. This will manifest itself in one of many ways including Out of Memory Exceptions or Out of Video Memory Exception. You see one of those bad boys, and you know you’re in trouble. So let’s see what kind of things can cause this evil to happen!

A common scenario you might find yourself in is if you write a game on Xbox and/or Windows and just directly port it to Zune via the Convert to Zune feature of our project system. The game will probably build just fine, you’ll do some quick fixes to scale your textures down to fit the Zune screen. You’ll hit F5 and the game will launch on the Zune and things will look nice and happy. You’ll think that the XNA Game Studio team are a bunch of amazing geniuses to enable something so cool to be so easy. Well… until your game crashes and you start to call us some really bad names.

So what happened? Is the XNA Game Studio team a bunch of n00bs? In certain games, yes…they are! But in coding, so not! Here’s what happened:

Textures..Textures..Textures

Your game, the one you initially created on Windows or Xbox, is probably using some nice, big textures. Windows and Xbox have way..way..waaaaaay more memory than their little brother the Zune. So if you have a texture that is say 512×512 in dimensions in your game, that is would come out to approx 1/2 MB of memory.

To calculate the size of a texture in memory, the formula is:

Texture has no transparency: width x height x 2bytes

Texture has transparency (alpha channel): width x height x 3bytes

So right there, you just ate 1/2 MB of your 16MB of memory.

So right there, that’s your first clue why you ran out of memory. You have to be very careful about the size of the textures you’re loading. And no, scaling the texture in game doesn’t solve that! You have to scale down the actual texture and then build the game.

Tip: Keep the sizes of your textures small! If you don’t need transparency, don’t use it. Re-use textures as much as you can.

Another area you can optimize is animations in your game. 2D animations are usually created using sprite sheets (see my post on the topic). Since such animations are created using frames of equal size usually, that means you can end up with a pretty big texture just for an animation. To get around that, you might need to approach it a bit differently. Things to consider:

1. Instead of storing all the frames in your animation, start storing only the the parts that actually move and animate them over the static parts. This way your frames don’t have to be of equal size and can drastically reduce the size of your texture strip.
2. Animations don’t have to be done via texture strips. Borrowing from the 80s style of game development (which makes sense since they had similar restrictions), you can animate stuff by using static textures and compositing them over each other. Check out this video to get an idea of what I am talking about. See how the boss is just a set of textures that are moved around to give the animation? Much smaller in size than animating the boss the usual way.

How you create your world is another area you want to focus on. In Windows/Xbox, you can use relatively hefty textures for your backdrops and so forth. Try that on Zune and you’re taking away from your memory budget. Consider using Tile Maps (I just started a post about this) for your world. They use much less memory and encourage reuse of textures.

I was talking to Yuichi Ito about this subject last week, and he actually told me this story of some artist he was working with back in the day. He said the guy knew he had little memory to work with but wanted the game to look good still. So he had to improvise. He started using the same texture he used for trees in the background for the hair on the characters! Just changed the color. No one noticed ;) You’d be surprised how much you can get away with and people won’t notice.

Yet another area you want to look into is particle effects. If you have any in your game, make sure you’re not using a separate texture for every particle color you’re using. Use a master white texture and then use the Tint color argument of SpriteBatch.Draw to color them.

Audio and Music

Audio and music in your game is very much like textures. So they need the same amount of focus from you or else you’ll hit the memory barrier yet again. Audio gets loaded in memory to be played, so the bigger it is, the more memory it will eat up. So use lower quality audio for your Zune games! You can read all about audio in general in Eli’s blog post about it right here.

Smaller Audio == more memory for your game!

Under the Hood

XNA Game Studio on the Zune runs using the .NET Compact Framework (NetCF). NetCF, while quite similar to its bigger brother on Windows, it’s not quite the same internally. Desktop .NET has a lot more memory and CPU power to work with, while NetCF doesn’t. So certain measures had to be taken to ensure good performance on the target platforms. This means some features are less efficient  than they are on the desktop. So how does this affect us while we create Zune games?

Most of the content you can create on a Zune game has both a Managed object and a native resource attached to it. For instance, a Texture has both a Texture2D object (the managed one) and an underlying Texture resource that is in Zune native land. The managed object references that native resource and wraps it. This way you get the nice looking managed objects without having to worry about the underlying implementation.

So when you actually load a Texture2D object, NetCF sees a small object being loaded, the managed object that represents the Texture. It doesn’t see the huge native resource that is also loaded by that texture object. As far as NetCF is concerned, your Texture2D object is only a few bytes large and therefore is not a priority when it has to do garbage collection. But we know better! If anything, that object better get collected as soon as possible since it’s actually pretty large. NetCF disagrees though :) So you need to lend a helping hand.

When you’re done with textures you were using, you need to either call Content.Unload to unload all the content that was previously loaded by your content manager or call Dispose on that texture yourself. You can make this a bit easier on yourself by creating a new instance of ContentManager in your code to load specific textures you know you’ll want to get rid off soon. You can have more than one ContentManager in your game, it’s totally fine. Same applies to things like Audio and others.

Clean up after yourself! Don’t rely on Garbage Collection to do the right thing for you!

Here’s another interesting implementation detail for you to keep in mind. When you load a Texture in memory, ContentManager will load it in system memory first, then copy it to Video memory. Guess what? In Zune, System and Video memory are one of the same! So when you load a Texture that is 1MB in memory size, you are actually using 2MB of memory to finish the operation. The first 1MB though will get garbage collected when more memory is needed. But keep that in mind since if you have 4MB of memory available, you will not be able to load 4 x 1MB textures because of this. You’ll only be able to load 3.

Debugging the Issues

So how do you debug memory issues on the Zune? When we would talk to people about this topic for Xbox 360 development, we usually would just tell people to use performance profiling tools on Windows against a Windows build of the same game. Since Windows and Xbox 360 are relatively close to each other, you can actually spot the issues on Windows using the more advanced tools and can fix them for the Xbox 360. Can’t really do that for the Zune :/

The Zune is severely dwarfed in power when compared to a PC. So perf issues that affect the Zune probably won’t appear on Windows in any obvious way. Sure, you can try, but I doubt you’ll get much helpful information. But there are tools that can still help you somewhat. We provide the Remote Performance Monitor tool (RPM) that can be used to tell you how much memory you’re using by your game and so forth.

To use RPM, launch it from your Start Menu (Microsoft XNA Game Studio 3.0->Tools). Get your Zune device hooked up and the game deployed on it (but not running). Then:

• Click on the Launch application button in the UI:

• Pick your Zune device from the list and then enter the name of the game you deployed:
• 
• Hit the Ok button. Your game should launch on the Zune.
• Now we check the GC Heap by clicking on the “GC Heap” button on the toolbar, you’ll see a window similar to this one:
• 
• This already provides you with good information. You can see how many objects your code is running at the moment and the size in KB of all of them. This way you can see which objects are getting too big and might need to get on a diet.
• Another area you might want to look at is the JIT section of the main window UI:
• 
• This will tell you how much space your code is taking up in memory. Another data point that might help you realize you may need to reduce the size of your code. Unless you’ve written your game in a very horrible way, I don’t think you’ll have much to optimize here though.

In Conclusion

Developing games on the Zune is indeed a very exciting thing! We can’t wait till we see the kind of games people will come up with. The experience of developing a game the right way can be quite challenging but also rewarding. So get started on those games and let us know how we can help you out!

This game is one of the entries for the Dream.Build.Play contest this year. Wow… just wow! Stuff like this truly blows us away and makes coming to work every morning a pleasure! So thank you people! You rock beyond words! I leave you with the awesome trailer for BattleTennis!

It does support Visual Studio 2008 of course but ONLY allows development on Zune and PC, there is no Xbox 360 support with this release. You can install this side by side with your current installation of XNA Game Studio 2.0 and Visual Studio 2005.

Read more about it here. If you run into issues, and you probably will, let us know so that we can fix them for the release.

Have fun everyone!

Zune

We have been working for a while on getting the Zune music player as a supported platform for XNA GS. Actually, if you remember from reading Yuichi Ito’s interview, this is the “secret” stuff he’s been working on for a while now! This will allow you guys to write your own games using the familiar XNA Framework and run them on a Zune device. All Zune devices are supported, old and new. You can read the FAQ that was posted in the forums about it. But I can tell you that I have used it (got it working on my Zune) and it is awesome! I was truly impressed by the work that was done so far, and it’s not even done!

Community Publishing

Ah… you’ve been asking for this since we released the first betas of XNA GS: “Can we publish our games on Xbox Live???”. Finally we have an answer that is good! Soon you will be able to upload a game you’ve written to the new http://creators.xna.com site (still in development but already looks HAWT!) and once it’s “approved”, people are going to be able to download it on their Xboxes through Xbox Live market place! So start making those games!!!! There are a lot of details regarding the publishing system that I am sure we’ll talk about more in the coming months. But trust me, this is very cool stuff. The guys working on this feature are incredibly cool and good at what they do.

XNA Games for download!

Yep, for a short while you are able to download 8 games that were built by XNA GS on Live Marketplace! Samurai Dishwasher is one of them! Go check out what people have done using XNA GS and have fun playing them. They are really cool games.

Now go have fun and I’ll get back to getting my lazy butt to continue my game series. I got some nice posts coming up… I just need to write them ;)

Here’s a quick list of what’s new in this awesome version:

• Networking Support
• Expanded Support for Visual Studio 2005 Products (that means Visual Studio 2005 Pro and up, an no, no support for Visual Studio 2008)
• XNA Game Studio Device Center and Easier Xbox 360 Connectivity
• Cross-Platform Game Project Converter
• Updated Game Project Format
• Integrated Game Content Projects
• XNA Game Studio Package Utility
• Updated Microsoft Cross-Platform Audio Creation Tool (XACT)
• Parameterized Processors
• …and more! Have a look at the “What’s new” page in the docs for the full list of changes.

All my tutorials have been done using XNA Game Studio 2.0. So it’s a good idea to upgrade to that version if you haven’t by now.

Have fun! I will get to writing my next tutorial very soon. Just gotta get to feeding my camel first.

Visual Studio 2005 Pro and up support (as well as Express of course)

Networking! You can write games that use Xbox Live on Windows and Xbox! This feature simply ROCKS!

Content is now a project of its own vs mixed in with your other source files.

Ability to automatically convert a Windows project to a Xbox one with one click

Parameterized Processors are here! Supported by the Visual Studio IDE

No more device lost/reset in the framework. We handle it for you!

And many many more features!

Go get it! Report bugs as you find them of course.

What is the content pipeline you say? Let me tell you! The Content Pipeline (CP) is the component that takes care of bringing game assets such as 3D models, textures, effects, etc to your game in a very simple manner. A typical usage scenario for the CP is creating some model in say 3D Max or Maya or whatever, export the model to Direct X File format (.x) or Autodesk FBX (.fbx). Add the file to your project in Visual Studio, add something like 4-5 lines of code, hit F5 and voila…model rendered on screen. Few more lines of code and you can use the game pad, mouse or keyboard to move the model around. You can do the same for textures, effects, sounds, etc.

Stay tuned for more info about the CP specially once the beta 2 is out. That thing is awesome!