I’m looking forward to this as well, and am brewing ideas for a few games on the platform.

Do give Engadget’s article a look! If you’re a game developer familiar with XNA, and especially if you’ve done any Zune HD programming, you should feel right at home developing for Windows Phone!

In fact, you can even get started now by downloading the XNA Game Studio 4.0 Beta from XNA Creator’s Club Online.  It includes a Windows Phone 7 emulator, so you can get a head-start on development even before devices are available.

This tutorial will provide step-by-step instructions on porting an application from the Zune HD to Windows Phone, using the existing Zune HD Sparkles application (InputToyZuneHD) as an example.  The full source code for that version can be downloaded here.

Important Notes:

• This article is written about pre-released technology.  It is likely that some of the features, the API, and the products mentioned here will change before final release.  I will attempt to keep this article up-to-date, but no guarantees can be made of the accuracy of this material when compared to the final (future) product.
• Since the Windows Phone emulator doesn’t include accelerometer support, you’ll need to wait for actual Windows Phone 7 devices to become available to actually see that part of the code in action, but you can certainly work with touch input right now using the emulator.

Prerequisites

This tutorial assumes that you’ve already created an application for Zune HD using the steps in the first set of tutorials. If you haven’t, you may want to at least read through Making the Zune HD Sparkle with XNA Game Studio 3.1 – Part 1 and Part 2.

Before you begin, you’ll also need the following:

• The XNA Game Studio 4 Community Technical Preview.
• The InputToy code for the Zune HD.  If you have an existing project to work from, you can begin from there.  Otherwise, download the code, unpack it, and follow along.

For reference, the full source code for the finished application for Windows Phone 7 can be downloaded here.

Converting a Zune HD project to Windows Phone 7

The first thing you’ll need to do is create a new Windows Phone game project and copy the source files into it. Call the project InputToyWP7. I won’t go into this process in detail here, since there’s already an article in the XNA Game Studio 4 documentation about how to do exactly that, called Migrating from Zune to Windows Phone.  It’s a great guide—trust me, I wrote it!

The source files you will need to copy from the old project are:

• Game1.cs
• Instructions.cs
• Menu.cs

Copy these into the InputToyWP7 directory in your Visual Studio 2010 project.

You’ll also notice that there’s an InputToyWP7Content directory in your project, as well. A major difference between the way XNA Game Studio 3.1 and 4.0 behave is that content projects are now full projects alongside the code project, and not in a sub-directory within the code project’s directory.

From the old project’s Content directory, copy the following files into the new project’s InputToyWP7Content directory:

• btnHelp.png
• btnPause.png
• btnPlay.png
• Flare.png
• Instructions.png

Once all these files have been added to your projects, you’ll be ready to proceed with the code modification necessary to get the application running on the WP7 emulator supplied with the XNA GS 4 CTP (wow, three TLAs in a row!).

Modifying the game code for Windows Phone

Screen dimensions

The original Zune HD version of this application was written for the Zune HD’s native screen resolution of 272 x 480.  Windows Phone 7, however, sports a native resolution of 480 x 800.  At some point, the Windows Phone emulator may support the built-in hardware scaling that is planned for the phone, but for now, it supports only the standard 480 x 800 resolution.

In anticipation of being able to set my screen dimensions to be equal to the Zune HD’s resolution—therefore preserving the original look of my application—I’m going to set the screen dimensions in a Vector2 that I can easily change in the future.  Add the following member to the Game1 class:

Vector2 screenDimensions = new Vector2(480, 800);

Now, in the game’s constructor, we’ll set the GraphicsDeviceManager‘s PreferredBackBufferWidth and PreferredBackBufferHeight to these dimensions.  We’ll also set IsFullScreen to true.  Add the following code to Game1′s constructor:

// Frame rate is 30 fps by default for Windows Phone.
TargetElapsedTime = TimeSpan.FromSeconds(1/30.0);

// This makes use of the built-in hardware scaler to work with our original (Zune HD) resolution
graphics.PreferredBackBufferWidth = (int)screenDimensions.X;
graphics.PreferredBackBufferHeight = (int)screenDimensions.Y;

// use the whole screen
graphics.IsFullScreen = true;

Another neat thing that we’ll get for free is an automatic translation of touchscreen coordinates from WP7′s native resolution to the resolution that we set for the backbuffer, so we can count on having the same touch coordinates (272 x 480) that we did for Zune HD. This isn’t an issue now, since we’re using 480 x 800 resolution, but it’s nice to know that no additional code changes will be needed when using automatic backbuffer scaling.

Speaking of touch input… we’ll now modify our touch input code so it works with GS4.  Thankfully, there won’t be much to do.

Changing the touch input code for XNA Game Studio 4

One difference between XNA GS 3.1 and 4.0 is how the touch input classes are referenced.  In XNA GS 4, they are now inside their own assembly.  To make our old code work with XNA GS 4, we’ll need to add a new reference to Microsoft.Xna.Framework.Input.Touch to the top of Game1.cs:

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Audio;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.GamerServices;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;
using Microsoft.Xna.Framework.Input.Touch;
using Microsoft.Xna.Framework.Media;

You’ll also need to make sure that Microsoft.Xna.Framework.Input.Touch is also referenced by your project itself:  Click on the References node in your InputToy source project, and make sure it contains Microsoft.Xna.Framework.Input.Touch in the list.  If it doesn’t, right click the References node and click Add Reference…, then select it from the list and click OK to add it to your project.

That’s it!  Aside from this change, we don’t need to do anything extra to our code to support touch input on WP7.  As mentioned before, due to the magic of hardware scaling, all our touch input code from the Zune HD version of the application will continue to work fine.

Changing the accelerometer code for Windows Phone

This is where things get interesting.  Accelerometers are not supported by XNA GS 4, as they were for Zune HD on XNA GS 3.1.  To work with the accelerometer on Windows Phone, you need to add the Microsoft.Devices.Sensors assembly to the project, which is, thankfully, included with the XNA GS 4 CTP you downloaded as a prerequisite.  Add the following line to the using statements at the beginning of Game1.cs (I added it after the using Microsoft.Xna.Framework.Media line):

using Microsoft.Devices.Sensors;

You’ll also need to make sure that Microsoft.Devices.Sensors is also referenced by your project, as you did for Microsoft.Xna.Framework.Input.Touch.

Microsoft.Devices.Sensors is not an XNA GS assembly—it’s supplied by Silverlight—and doesn’t follow the usual programming patterns used with XNA Game Studio.  There’s no polling for input as there was with Accelerometer.GetState in GS 3.1.

Instead, we’ll be using the AccelerometerSensor class in Microsoft.Devices.Sensors.  We’ll also define an event handler that will be called when the ReadingChanged event is raised.

First, add the following members to the Game1 class:

...
List<Sparkle> sparkles;
Instructions instructions;
Menu menu;
bool accelActive = false;
AccelerometerSensor accelSensor;
Vector3 accelReading = new Vector3();

First, we have a boolean value that we’ll use to keep track of whether the accelerometer is active or not.  Next is a member to hold the AccelerometerSensor object, and finally is a Vector3 that we’ll use to hold the X, Y, and Z values returned by the accelerometer.

Next, we’ll add the following code to Game1′s constructor:

// This makes use of the built-in hardware scaler to work with our original (Zune HD) resolution
graphics.PreferredBackBufferWidth = (int)screenDimensions.X;
graphics.PreferredBackBufferHeight = (int)screenDimensions.Y;

// use the whole screen
graphics.IsFullScreen = true;

accelSensor = new AccelerometerSensor();

// Add the accelerometer event handler to the accelerometer sensor.
accelSensor.ReadingChanged +=
   new EventHandler<AccelerometerReadingAsyncEventArgs>(AccelerometerReadingChanged);

// Start the accelerometer
try
{
   accelSensor.Start();
   accelActive = true;
}
catch (AccelerometerStartFailedException e)
{
   // the accelerometer couldn't be started.  No fun!
   accelActive = false;
}

After creating an instance of the AccelerometerSensor, we add the event handler to handle the ReadingChanged event.  It will be called AccelerometerReadingChanged, and takes an AccelerometerReadingAsyncEventArgs argument. We’ll define this handler in a short while.

For now, notice that we also have to Start the accelerometer, and that this call can fail with an AccelerometerFailedException.  If it does, we simply set accelActive to false.

In this case, we’ll have the accelerometer active during the entire run of the program.  In your own games, you may want to turn off the accelerometer when its not being used.  This can improve performance, since there will be no need to receive or respond to ReadingChanged.

Instead, we’ll just turn off the accelerometer when the program shuts down.  Add the following lines to UnloadContent, which is called as the game is exiting:

protected override void UnloadContent()
{
   // Unload any non ContentManager content here
   // Stop the accelerometer if it's active.
   if (accelActive)
   {
      try
      {
         accelSensor.Stop();
      }
      catch (AccelerometerStopFailedException e)
      {
         // the accelerometer couldn't be stopped now.
      }
   }
}

Now, lets revisit the ReadingChanged event handler.  We called it AccelerometerReadingChanged, but didn’t actually define the method.  We’ll do so now.  Add the following method to the Game1 class:

public void AccelerometerReadingChanged(object sender, AccelerometerReadingAsyncEventArgs e)
{
   accelReading.X = (float)e.Value.Value.X;
   accelReading.Y = (float)e.Value.Value.Y;
   accelReading.Z = (float)e.Value.Value.Z;
}

There isn’t much to it: this method simply gets the X, Y, and Z values from the AccelerometerReadingAsyncEventArgs object, and saves them in the Vector3 that we defined earlier.

Now, all we need to do is make use of this data.  We actually had code that did this for our Zune HD version of the application, and we’ll reuse that code.

In Game1′s Update method, remove the lines that were used to get the accelerometer state, since these are no longer used.  Remove these lines:

// grab the accelerometer state.  This will be used for sparkle
// movement.
AccelerometerState accelState = Accelerometer.GetState();

Later in Update, there’s code that sets the particle speed based on the value in the accelState variable.  Find it, and modify the code (modified bits are in green, as usual) so that it looks like this:

if (accelActive)
{
   // accelerate the sparkle depending on accelerometer
   // action.
   s.speed.X += accelReading.X * ACCELFACTOR;
   s.speed.Y += -accelReading.Y * ACCELFACTOR;

   // move the sparkle based on its speed.
   s.position.X += s.speed.X * etms;
   s.position.Y += s.speed.Y * etms;
   s.rotation += s.speed.Length() * ACCELFACTOR * etms;
}

The only changes we had to make were to make use of the accelActive value that tells us the accelerometer has been made active (by calling Start), and switching out the accelState variable that we removed earlier with our accelReading class member.

That’s it!  Though modifying the accelerometer code was a little more work than it took to modify the touch code, it didn’t take much more than defining a single event handler and adding the code to instantiate, start, and stop the AccelerometerSensor.

You should now be able to build the application and, once you get your hands on a Windows Phone 7 device, be able to see it behave just like it did for Zune HD.  For now, however, you can at least play with the touch portions of the application in the Windows Phone 7 emulator:

As before, please let me know if you have any questions or comments regarding this tutorial, or if you’d like to see articles covering other subjects.  I hope you enjoyed it!

This is part two of a two-part tutorial dealing with touch and accelerometer input on the Zune HD.  It’s assumed that readers have already read the first part, which provides a full discussion of building the application to this point, including required prerequisites.  If you haven’t read it already, see Making the Zune HD Sparkle with XNA Game Studio 3.1 – Part 1.

This part of the tutorial adds a number of GUI elements to the application, making it more complete by adding an instruction screen and a menu to manipulate the behavior of the display.

As before, the source code can be downloaded here.

Adding an Instructions Screen

As I mentioned at the end of part one, the application, as it is, doesn’t give the user any indication of what to do: it initially starts with a black screen.

We’ll now add an instructions screen that will appear when the app is first started, and then will fade into the background, allowing the user to continue to create sparkles without the instructions visible.

I’ll do this as simply as possible: the instructions screen is simply another texture that will be displayed and faded.  The instructions look like this:

Add this file (also in the source zip, if you downloaded it) to your content project.  The Asset Name should be “Instructions” and the Build Action, as before with the flare image, should be “Compile”.

The Instructions Class

We’ll add a new class to handle the instructions screen, to avoid mucking up Game1′s code.  In Visual Studio, add a new class called Instructions.cs.  If you create the class by right-clicking the InputToyZuneHD project and selecting Add…, then New Item, and then Class, you’ll be provided with some skeleton code for your class:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace InputToyZuneHD
{
     class Instructions
     {
     }
}

Replace all the using lines after System with the following Xna.Framework namespaces :

using System;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Content;

We’ll be making use of these namespaces in our code, but won’t be needing System.Collections.Generic, System.Linq, or System.Text.

Now, begin filling in the class, adding some class data members:

private const float TIMETOSHOW = 6000.0f;
private const float FADETIME = 2000.0f;

private State state;
private float timeRemaining;
private Texture2D image;
private Color color;
private Vector2 pos;

The TIMETOSHOW and FADETIME members will be used to control how long to display the instructions, and are in milliseconds.  There is also a State enumeration, made public so it can be seen outside the class, and related data member to track the state of the instructions display.

The next four members: timeRemaining, image, color, and pos, are used to update and display the instructions.  Their use, if not already obvious, will be shortly.

Add a constructor, initializing the state and color members:

public Instructions()
{
    state = State.HIDE;
    color = new Color(255,255,255,255);
}

Also, add a loadContent public method that will be used to fill the image and pos members:

public void loadContent(ContentManager cm, GraphicsDevice gd)
{
    image = cm.Load<Texture2D>("Instructions");
    pos = new Vector2(
        (gd.Viewport.Width - image.Width) * 0.5f,
        (gd.Viewport.Height - image.Height) * 0.5f);
}

We’re placing the image in the middle of the display area (provided by GraphicsDevice.Viewport), based on the image dimensions.

Next, add a public method to show the instructions, and another to check to see if the instructions are visible or not.  We’ll call these show and isVisible.  Yes, these methods practically name themselves:

public void show()
{
    state = State.DISPLAY;
    color.A = 255;
    timeRemaining = TIMETOSHOW;
}

public bool isVisible()
{
    return (state != State.HIDE);
}

As long as the instructions are not in the HIDE state, they are visible.

The core of the Instruction class is really the update method, which serves to set the state and alpha-channel of the color, based on the time remaining:

public void update(float etms)
{
    if (state == State.HIDE)
    {
        return;
    }

    timeRemaining -= etms;
    if(timeRemaining < 0)
    {
        state = State.HIDE;
        return;
    }
    else if (timeRemaining < FADETIME)
    {
        // fading out
        state = State.FADEOUT;
        color.A = (byte)(255.0f * timeRemaining / FADETIME);
    }
}

You may recall that etms, the elapsed time in milliseconds since the last frame, was a value that we used in the first part of the tutorial.  It’s used here to reduce the time remaining.

Lastly, we’ll add a method to draw the instructions image, using a SpriteBatch:

public void draw(SpriteBatch sb)
{
    if (state == State.HIDE)
    {
        return;
    }

    sb.Draw(image, pos, color);
}

Rather self-explanatory:  If the state of the instructions is HIDE, don’t draw it.  Otherwise, draw it with the image, pos, and color members.  Notice that this Draw call is far simpler than the one we used to draw the sparkles.  That’s because we’re not applying any rotation to the image.  If you’re simply drawing an unscaled, non-rotated image on the screen, this version of Draw is the way to go.

That’s it for the Instructions class!  Next, we’ll hook it in to our game loop.

Adding the Instructions Class to the Game

Open the Game1.cs class that we worked with in the first part of the tutorial.  We’ll add a new data member to Game1, and then initialize it in Game1‘s constructor:

List<Sparkle> sparkles;
Instructions instructions;

public Game1()
{
    graphics = new GraphicsDeviceManager(this);
    sparkles = new List<Sparkle>();

    instructions = new Instructions();

    Content.RootDirectory = "Content";
...

In Game1.LoadContent, add code to load the instructions content and show it (since we want the instructions to show as soon as the application starts):

flareImage = this.Content.Load<Texture2D>("Flare");
flareOffset = new Vector2(
    flareImage.Width * 0.5f, flareImage.Height * 0.5f);
instructions.loadContent(this.Content, this.GraphicsDevice);
instructions.show();

In Game1.Update, update the instructions screen right after getting the elapsed time in milliseconds.  There’s no need to update instructions if it’s not visible, however:

// elapsed time will be used in updating movement
float etms = gameTime.ElapsedGameTime.Milliseconds;

// update the instructions state if needed
if (instructions.isVisible())
{
    instructions.update(etms);
}

The last thing we need to do is add the instructions to the draw code.  Since we want the player to be able to draw sparkles on the screen even while the instructions are showing, we’ll draw the instructions first, right after the call to SpriteBatch.Begin, and before drawing any sparkles.  In Game1.Draw, add:

spriteBatch.Begin();
// draw stuff in the background
if (instructions.isVisible())
{
    instructions.draw(spriteBatch);
}

// draw the sparkles
foreach(Sparkle s in sparkles)
...

You should be able to build and deploy the application.  Now, when you run it, you should be able to see the nifty instructions screen show as soon as the application loads, and watch it fade out after about six seconds.

Adding a Menu

There’s still one more part of the GUI that would be nice to have: the ability to show the instructions screen at will while the game is running, and also the ability to stop and re-start the sparkle fading, so the user can spend more time using the accelerometer to play with existing sparkles.

We’ll now add an interactive menu to accomplish this.  It will be small and unobtrusive so that it won’t interfere with sparkle creation, but large enough that the player can actually use the menu.  Our menu will consist of two buttons, one of which (the pause/play button for sparkle fading) will have two states.

The buttons look like this:

Add these files to the InputToyZuneHD content project.  As before, they should have Asset Names that correspond to their filenames (“btnHelp”, “btnPause”, and “btnPlay”, respectively) and the Build Action of each should be set to “Compile”.

The Menu Class

As with the instruction screen, we’ll create a new class to handle the menu.  It’ll be called Menu.cs.  The using block should look like this:

using System;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.Input;

Declare the following private data members at the beginning of the new Menu class:

private const int BUTTONMARGIN = 4;

private Texture2D pauseBtnImg;
private Texture2D playBtnImg;
private Vector2 pauseBtnPos;

private Texture2D helpBtnImg;
private Vector2 helpBtnPos;

private bool paused;

The BUTTONMARGIN represents the distance we’ll place each button from the edges of the screen, and the rest of the variables hold the texture and position of each button, and whether fading is paused or not.  You’ll note that we only need one position for the pause/play buttons, since they’ll appear in the same position on the screen.

Now, add Menu’s constructor, setting paused to false:

public Menu()
{
    paused = false;
}

As we did with the Instructions class, we’ll add a loadContent method to load the class content:

public void loadContent(ContentManager cm, GraphicsDevice gd)
{
    pauseBtnImg = cm.Load<Texture2D>("btnPause");
    playBtnImg = cm.Load<Texture2D>("btnPlay");
    pauseBtnPos = new Vector2(
        0, gd.Viewport.Height - pauseBtnImg.Height);

    helpBtnImg = cm.Load<Texture2D>("btnHelp");
    helpBtnPos = new Vector2(
        gd.Viewport.Width - helpBtnImg.Width,
        gd.Viewport.Height - helpBtnImg.Height);
}

The pause/play button is placed on the bottom-left part on the screen, and the help button is placed on the bottom-right.  This will provide a minimal, but useful, user interface.

We’ll also add a public isPaused method that the Game1 class can use to determine whether or not to fade the sparkles:

public bool isPaused()
{
    return paused;
}

Now, we’ll get to the core of this class.  Unlike the instructions screen, the menu is interactive, so it must handle user input.  We’ll create a handleInput method that takes a TouchLocation, so it can determine if the TouchLocation intersects one of the buttons, and a reference to the Instructions class, so we can show the instructions screen if the help button is pressed:

public bool handleInput(TouchLocation tl, Instructions instructions)
{
    if (tl.Position.Y > (pauseBtnPos.Y - BUTTONMARGIN))
    {
        if (tl.Position.X < (pauseBtnImg.Width + BUTTONMARGIN))
        {
            // toggle the pause state.
            paused = !paused;
        }
        else if (tl.Position.X > (helpBtnPos.X - BUTTONMARGIN))
        {
            // show the game instructions.
            instructions.show();
        }

        return true;
     }

     return false;
}

The function returns true if it handled the input, and false if it didn’t.  We’ll use this in Game1 to determine whether or not to draw a new sparkle for this TouchLocation.

Finally, there will be a draw method for the menu, so it can be displayed:

public void draw(SpriteBatch sb)
{
    // draw the buttons.
    sb.Draw((paused ? playBtnImg : pauseBtnImg), pauseBtnPos, Color.White);
    sb.Draw(helpBtnImg, helpBtnPos, Color.White);
}

It’s time to hook the menu to the game loop, and see how it all comes together!

Adding the Menu Class to the Game

Open Game1.cs again, and add a new member variable for the Menu class:

List<Sparkle> sparkles;
Instructions instructions;
Menu menu;

In Game1′s constructor, initialize the menu:

instructions = new Instructions();
menu = new Menu();

Load the menu’s content as we did for the instructions.  In Game1.LoadContent, add:

flareOffset = new Vector2(
     flareImage.Width * 0.5f, flareImage.Height * 0.5f);
menu.loadContent(this.Content, this.GraphicsDevice);
instructions.loadContent(this.Content, this.GraphicsDevice);

Next, we’ll need to send touch events to the menu, to see if any of the buttons were pressed.  Add the following lines of code to Game1.Update:

foreach (TouchLocation tl in touchCollection)
{
    if ((tl.State == TouchLocationState.Pressed)
        || (tl.State == TouchLocationState.Moved))
    {
        if (tl.State == TouchLocationState.Pressed)
        {
            if (menu.handleInput(tl, instructions))
            {
                break;
            }
        }

        // add sparkles based on the touch location
        sparkles.Add(new Sparkle(tl.Position.X,
            tl.Position.Y, ttms));
...

You might be wondering why, if tl.State == TouchLocation.Pressed was already tested for, we’re testing for it again?

The reason is this: I made a design choice to not allow the menu to be activated if the player simply drags his or her finger over the menu area during a swipe meant to create sparkles.  Similarly, I didn’t want the pause/play button to be turned on and off if the player swipes the screen a little after pressing the button.  Only a new touch will activate the menu.

Another design choice has been made here: if a menu button was touched, we use break instead of continue in the foreach loop.  This causes all further touch-points to be ignored.

As an experiment, you might like to see what happens when you allow TouchLocationState.Moved to activate the menu, or use a continue instead of a break if a menu button was activated.  I find that experimenting with design choices such as the above really gives me an better idea of how to design my user interface elements to respond as the user expects them to.

There’s only one thing left to do here, and that’s to draw the menu!  In Game1.Draw, add a line to draw the menu, just before SpriteBatch.End is called:

// draw the foreground (AKA the HUD)
menu.draw(spriteBatch);

spriteBatch.End();

The menu is drawn after the sparkles so it will always appear over the sparkles.  This type of display is often called a heads-up display, or HUD, since it is drawn over any game action.  Health-bars, mini-maps and other such game interface elements are often drawn this way.

That’s all.  Build, deploy, and run the application again to see its final form (at least, for now).  You should be able to display the instructions again by pressing the help button, and you should be able to toggle the fading off and on by using the pause and play buttons.

I hope that you enjoyed the tutorial.  If you have any questions about its content, feel free to contact me.

Introduction

This article explores using XNA Game Studio to access the two primary forms of user input on the Zune HD: the multitouch screen, and the accelerometer. We’ll do this by building a small demo that allows the user to create sparkles by touching the screen, and to move them around by tilting the device.

Over the course of this tutorial, the following subjects will be covered:

• Multitouch input
• Accelerometer input
• Animating blended sprites
• A simple UI  (in part two)

I won’t be going over how to create a new XNA game project, nor will I describe how to add textures using the Content Pipeline. I assume that the reader has read enough about Game Studio to know how to do these things already. If you haven’t, I suggest downloading XNA Game Studio (a link is provided below) and going through the first tutorial provided in the Game Studio documentation.

The full sample, including source code, images, and VS2008 project files, can be downloaded here. Unless you want to make your own textures while following along with the tutorial, you’ll at least want to grab the images from the zip archive.

public class Game1 : Microsoft.Xna.Framework.Game
{
    static Random random = new Random();
    class Sparkle
    {
        public Vector2 position;
        public Vector2 speed;
        public float rotation; // in radians
        public Color color;
        public long birthtime;

        public Sparkle(float x, float y, long time)
        {
            position = new Vector2(x, y);
            rotation = (float)(random.NextDouble() * 2.0 * Math.PI);
            color = Color.White;
            birthtime = time;
        }
    }
...

const int SPARKLELIFE = 4000; // ticks
const int MAXSPARKLES = 100; // maximum number of sparkles, for performance tuning.
const float ACCELFACTOR = 0.01f;
const float FADEFACTOR = 255.0f / SPARKLELIFE;

GraphicsDeviceManager graphics;
SpriteBatch spriteBatch;
Texture2D flareImage;
Vector2 flareOffset;
List<Sparkle> sparkles;

// Create a new SpriteBatch, which can be used to draw textures.
spriteBatch = new SpriteBatch(GraphicsDevice);
flareImage = this.Content.Load<Texture2D>("Flare");
flareOffset = new Vector2(
    flareImage.Width * 0.5f, flareImage.Height * 0.5f);

// Allows the game to exit
if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)
{
   this.Exit();
}

long ttms = (long)gameTime.TotalGameTime.TotalMilliseconds;

// Process touch events
TouchCollection touchCollection = TouchPanel.GetState();
foreach (TouchLocation tl in touchCollection)
{
      // add sparkles based on the touch location
      sparkles.Add(new Sparkle(tl.Position.X,
               tl.Position.Y, ttms));
}

foreach (TouchLocation tl in touchCollection)
{
   // add sparkles based on the touch location
    sparkles.Add(new Sparkle(tl.Position.X,
             tl.Position.Y, ttms));

   // if there are too many sparkles, remove from the head.
   if (sparkles.Count > MAXSPARKLES)
   {
      sparkles.RemoveAt(0);
   }
}

protected override void Draw(GameTime gameTime)
{
    GraphicsDevice.Clear(Color.Black);
    spriteBatch.Begin();
    // draw the sparkles
    foreach(Sparkle s in sparkles)
    {
        // when drawing with a specified origin, the origin affects
        // both the rotation and position parameters.
        spriteBatch.Draw(
            flareImage, s.position, null, s.color, s.rotation,
            flareOffset, 1.0f, SpriteEffects.None, 0);
    }
    spriteBatch.End();
...

// update the sparkles. We count from the end of the list in case
// we need to remove a sparkle (without upsetting the order).
for (int i = sparkles.Count - 1; i >= 0; i--)
{
    Sparkle s = sparkles[i];
    if ((ttms - s.birthtime) > SPARKLELIFE)
    {
        sparkles.RemoveAt(i);
        continue;
    }
    else
    {
        // fade the sparkle a bit, depending on its age.
        s.color.A = (byte)(255.0f - (ttms - s.birthtime) * FADEFACTOR);
    }
}

long ttms = (long)gameTime.TotalGameTime.TotalMilliseconds;

// elapsed time will be used in updating movement
float etms = gameTime.ElapsedGameTime.Milliseconds;

// grab the accelerometer state.  This will be used for sparkle
// movement.
AccelerometerState accelState = Accelerometer.GetState();

// fade the sparkle a bit, depending on its age.
s.color.A = (byte)(255.0f - (ttms - s.birthtime) * FADEFACTOR);

// accelerate the sparkle depending on accelerometer action.
s.speed.X += accelState.Acceleration.X * ACCELFACTOR;
s.speed.Y += -accelState.Acceleration.Y * ACCELFACTOR;

// move the sparkle based on its speed.
s.position.X += s.speed.X * etms;
s.position.Y += s.speed.Y * etms;
s.rotation += s.speed.Length() * ACCELFACTOR * etms;