Bill Reiss is a Windows Platform Development MVP and a Senior Consultant for AgileThought

All posts tagged Windows Phone

At the end of Part 2 of this series, we had our character running in place. image_thumb5

This was done through the Update method of the XNA Game class processing when the frame should change, and then the Draw method called the appropriate SpriteBatch.Draw method to draw the current frame. Here is the source code that we’ll start with and build upon in this post.

This is a fairly short one, we just need to build upon some of the topics so far to build a platform for our player to run on, and then we’ll be done with Step 1 (“Draw Stuff”) of building an XNA game.

Here is the platform image:


Click on the image and then select to save it to your computer. Call it platform.png.

Now just like with the player image from Part 1, add an existing item to the content project. This time we’ll use platform.png. Now we want to do exactly the same thing we did before, adding a field to store the texture, and a couple of others to store the animation state:

Texture2D platform;
float platformOffset = 0;
float platformScrollSpeed = 200;

And in LoadContent we’ll load it:

platform = Content.Load<Texture2D>("platform");

And then in the Draw method we’ll draw a row of these under the player:

for (float f = -platformOffset; f < 800; f += platform.Width)
    spriteBatch.Draw(platform, new Vector2(f, 300 + runFrameHeight),

Notice that you can use the same texture multiple times when drawing. This is starting to look better:


Now to give an illusion of motion we can scroll the platform by changing the platformOffset in the Update method based on the speed and the elapsed time:

platformOffset += platformScrollSpeed * (float)gameTime.ElapsedGameTime.TotalSeconds;
if (platformOffset > platform.Width) platformOffset -= platform.Width;

Every time we scroll more than the width of a block, we’ll subtract the width of the block from the offset so that the number doesn’t keep getting bigger, but since we shift by exactly the width of one block the motion looks smooth and continuous.

Run it again. You should now see the running man and the scrolling platform. Not bad for less than 40 lines of code.

Here is the source code for the project at this point:

In the next post we’ll start Step 2 and look at how to handle input in XNA.

In the last post we created a new XNA game solution for Windows Phone, added an image to draw to the content project, loaded it, and drew it to the screen. We also explored how to remove the taskbar and taking advantage of hardware scaling for performance. At the end of Part 1 we were somewhere around here:


Here is the source code for the starting point for this post:

Now let’s take it a step further and only draw a part of the image so that we only see one frame at a time.

This image that we’re drawing (called a texture in XNA) is known as a sprite sheet and it’s copied from the Platformer sample that ships with XNA. A sprite sheet is an image that contains multiple frames of motion for a sprite or sprites.

When using the graphics processor (GPU) to draw like XNA does, it’s more efficient to use a single texture and draw only what you need from it instead of loading a texture for each frame and swapping them. It’s even more efficient to pack all of your textures into a single texture and with each draw call draw only what you need. This is because there is significant overhead in telling the graphics processor to use a different texture.

The sprite sheet that we’re using is the texture used when the character is running. There is one part of the texture for each frame in the running animation and by drawing these in sequence we can get the illusion that the character is running.

TIP: If creating your own character, you can draw over an existing sprite sheet, it’s easy to find these on the internet. By drawing over an existing one it’s easier to draw the character in the correct positions. Instead of figuring out what positions you need to give the illusion of running you can just focus on the artwork.

To draw only a single frame, let’s add fields to store the current frame and the frame height and width:

int playerCurrentFrame = 0;
int runFrameWidth = 0;
int runFrameHeight = 0;

In the LoadContent method we’ll take the loaded player texture and calculate the frame width and height from it:

player = Content.Load<Texture2D>("run");
runFrameWidth = player.Width / 10;
runFrameHeight = player.Height;

Then in the Draw method, we’ll change the Draw call as follows:

spriteBatch.Draw(player, new Vector2(80, 300),
    new Rectangle(playerCurrentFrame * runFrameWidth, 0,
    runFrameWidth, runFrameHeight), Color.White);

This is a different overload of the Draw method, there are a lot of them. Take some time to look at all of the different SpriteBatch Draw calls since the right overload can save you a lot of effort.

Run the app again. Now you should only see one frame.


Now if we want to animate the character, we can do this with the Update method.

playerCurrentFrame = playerCurrentFrame % 10;

Since there are 10 frames in this animation, the frame count is incremented every time the Update method is called, and when it gets to 10 it starts over. Run the app again.

Looks like he’s running a little fast, so let’s slow him down a bit. Instead of updating the current frame every time Update is called, it’s do it based on a time value. Add the following fields to the Game class:

double playerAnimationDelay = .05;
double currentPlayerAnimationDelay = 0;

And in the Update method, the code changes as follows:

currentPlayerAnimationDelay += gameTime.ElapsedGameTime.TotalSeconds;
while (currentPlayerAnimationDelay > playerAnimationDelay)
    playerCurrentFrame = playerCurrentFrame % 10;
    currentPlayerAnimationDelay -= playerAnimationDelay;

Now by changing the playerAnimationDelay value you can control exactly how fast your character animates. He’s also facing the wrong way for our needs, so change the spriteBatch Draw call as follows:

spriteBatch.Draw(player, new Vector2(80, 300),
    new Rectangle(playerCurrentFrame * runFrameWidth, 0,
    runFrameWidth, runFrameHeight),
    Color.White, 0, Vector2.Zero, 1, SpriteEffects.FlipHorizontally, 0);

Cool now he should be facing the right way and running at a slower speed.


In the next post we’ll look at giving our character something to run on.

To get started developing games for Windows Phone you need to have the Windows Phone 7.1 SDK installed. You can get it here. Once you’ve installed this you’ll also want the 7.1.1 update, which you can get here. The update requires the 7.1 SDK to be installed first.

If you’re installing on Windows 8, check out my post about installing the Windows Phone development environment on Windows 8.

In this post we’ll start creating a new XNA game, and begin with the most visible step, and the one people thing of first when they think of game development. We’ll draw something to the screen.

Step 1: Draw Stuff

Let’s start by creating a new XNA game project. Run Visual Studio 2010 with Windows Phone SDK 7.1.1 installed. Select File -> New -> Project and select XNA Game Studio 4.0 and choose Windows Phone Game. We’ll call our game MyFirstGame.


Choose to target Windows Phone 7.1, there’s no real reason to target 7.0 anymore.


With 7.1 there are many new capabilities with the most important for games being fast app switching, or the ability to resume your game via the back button without reloading everything.

This creates two projects, one for your XNA game and one for your game’s content. Content projects contain any assets for your game, including images, sound effects, 3D meshes, shaders, and level data. Assets that are added to the content project are compiled to a proprietary XNB format that XNA understands so that XNA doesn’t need to know how to deal with the various asset types when the game is running, the heavy lifting is done at compile time.


The solution that is generated is a fully functioning game. It doesn’t do a whole lot yet, but helps you to know where your code needs to be added. Run the game in the emulator and you will see the “blue screen of life”, by default you get a Cornflower Blue background and not much else, but at least the back button works.

Run the game and show what it looks like so far.


Now one thing you may notice is that the game doesn’t fill the entire screen. It’s kind of hard to see in the emulator, but by default the system tray is displayed, and your game is scaled (letterboxed and preserving aspect ratio) in the remaining space.

To remove the system tray, in the game project, go to Game1.cs. and add the following to the Game1 constructor:

graphics.IsFullScreen = true;

Run the app again and you should see that it fills the entire area.


Now it’s time to draw something.

Save this image to your computer. You can do this by clicking on it and then right clicking and save the image. Call it run.png.


In the content project, select Add Existing Item and go to the Assets folder and pick run.png from wherever you saved it to.

Add a field to the Game1 class:

Texture2D player;

and in the LoadContent method after the TODO comment add the following:

player = Content.Load<Texture2D>("run");

The text “run” is the asset name of the content we want to load. By default this is the filename without the extension, but you can change this in the properties pane for the content item.

In the Draw method, add the following to draw the texture:

spriteBatch.Draw(player, new Vector2(80, 300), Color.White);

When drawing using SpriteBatch, you need to make sure that for every Begin of the SpriteBatch that you have a corresponding End. You should also limit the number of Begin and End calls that you do, but you can do as many Draw calls as you want between a single Begin and End. It’s not a big deal to have a few Begins and Ends but don’t have one per draw call, since most of the overhead when drawing is in the End call because this is where the graphics are actually rendered.

Run the game. It should look like this:


One thing you’ll notice is that the texture is being drawn sideways.

By default XNA apps are in landscape mode on the phone. You can change this by adding the following to the Game constructor:

graphics.PreferredBackBufferWidth = 480;
graphics.PreferredBackBufferHeight = 800;


By specifying a height that is larger than the width, XNA automatically determines that it should be in portrait mode.


There’s another neat trick when it comes to the back buffer width and height and XNA on the phone. The phone resolution of 800×480 is almost 400,000 pixels. Drawing this many pixels can potentially impact the performance of your game, especially if drawing a lot of big textures. You can automatically scale the game using hardware scaling by specifying smaller values for the preferred width and height. By specifying values of half the native size you end up drawing one quarter of the pixels that you do in full resolution. Of course, all of your textures will be scaled up too, so you’re sacrificing level of detail for performance, but if you need it, it’s good to have it available. Change the constructor code as follows:

graphics.PreferredBackBufferWidth = 240;
graphics.PreferredBackBufferHeight = 400;


Run the app and it should look like this:


Everything is now double size. Now that we’ve had fun with orientation and scaling, let’s remove the code to set the width and height and go back to displaying it in landscape mode. We can also rotate the emulator so that it’s displaying in landscape mode on the screen.


Here is the source code for everything up to this point:

In the next post we’ll look at drawing a single frame of this image and how to draw different frames over a period of time.

I recently revamped my Intro to XNA presentation so that I could present something fresh at the Orlando Code Camp. I have this problem where I don’t like to take the easy path and keep presenting the same thing.

When I’ve presented about game development recently I’ve had the impression that most of the attendees thought it was cool but it was something that they couldn’t actually do.

Because of this, I decided to try to make it more approachable and break down game development into its core parts and if you take them one at a time it’s not that scary.

So these are the steps I broke it down to:

  • Draw stuff
  • Handle and act on input
  • Play sounds
  • Monetize
  • Stick with it!

You can find my presentation slides and demos here:

I’ve decided to turn this presentation into a series of blog posts, so stay tuned and I hope you enjoy the posts as much as I enjoyed putting it together. When we get to the end it will look something like this: