SilverlightShow: Silverlight Community

Simulating rain in Silverlight Part 4 - Adding sound effects

editorial@silverlightshow.net (Lazar Nikolov ) — Fri, 30 Sep 2011 19:21:00 GMT

This article is compatible with the latest version of Silverlight.

Introduction

More resources...

($9.99)

This article is part 4 of my article series, Simulating rain in Silverlight. After I added wind effect in the previous article, now I add some “color” in the whole scene. Besides the sound effect, I also put in some visuals to control the wind speed. You can choose between three different rates that will alter the angle of the rain drops. To better react when changing the speed I had to do some minor changes in the simulation algorithm. You are free to download and play with the code from the link below.

It may seem very unfamiliar to you to have sound in your Silverlight application, but it, actually, is not that hard. Silverlight provides you with tools for handling sounds and videos in code and XAML. How? Just in a few seconds...

First, here is a demo:

View live demo

As you might see, you can choose between three different speeds that affect respectively the angle of the rain. Obviously, the stronger the wind is, the bigger the angle is. In nature, having summer rain with 40 kilometers per hour, results in approximately 10 degrees of inclination of the rain. Respectively, 60 km/h yields 30 degrees and 80 km/h – 60 degrees. Again, it depends on the intensity and rain density, but we can use this rule for orientation marks in our simulation.

You can download the source from the following link:

Download source code

How to add sound in your application?

Rain and wind simulation is not complete without any sound effects.

The MediaElement class is the key. It allows you to play a number of audio and video formats. For a complete list of supported files, read here.

The first thing you need to do is to find (or create the sounds) you are to use. There are a bundle of websites on the net offering free sound effects in any audio format. For example, check these out: http://www.partnersinrhyme.com/soundfx/Weather.shtml and http://www.shockwave-sound.com/.

My rain simulation uses two audio files – one for the rain and one for the wind. You need to add the files in the project and change the build action to Resource to ensure the media file gets copied in the ClientBin folder.

I declare my media elements in the XAML that control the both effects:

<MediaElement x:Name="WindSound"

Source="wind.mp3"

AutoPlay="False">MediaElement>


 
<MediaElement x:Name="RainSound"
                Source="rain.mp3"
                AutoPlay="False">MediaElement>


I set AutoPlay=”False” to prevent the media element from playing as soon as the app starts. I control this on my own:

private void WindSound_MediaOpened(object sender, System.Windows.RoutedEventArgs e)
{
    this.windMarker.Time = TimeSpan.FromMilliseconds(this.WindSound.NaturalDuration.TimeSpan.TotalMilliseconds - 1000);
    this.WindSound.Markers.Add(this.windMarker);
    this.WindSound.Volume = 0.3;
    this.WindSound.Play();
}

To loop the audio, I use markers. Markers are marks in the audio/video that you can jump to when needed. I create a marker one second before the end of the media file and I use it to mark the end of the file and loop the media. The alternative, to handle the media ended event, is not the best choice here since the sound is getting silent and silent in the very end:

private void WindSound_MarkerReached(object sender, TimelineMarkerRoutedEventArgs e)
{
    this.WindSound.Stop();
    this.WindSound.Play();
}

To change the rain angle on the fly, I must abstract the rain in maximum rate. The improvement that I make here is in the way I initialize the rain and all it dependencies. The drop settings are constructed in the rain constructor, so is the slice and the fall distance.
Having all this in mind, we have this method:

public void ChangeAngle(int angle)
{
    int fallDistance = (int)((double)this.Height / Math.Cos(Math.PI * angle / 180));
    this.FallDistance = fallDistance;
    this.Angle = angle;
    this.Slice = (int)(this.Height * Math.Tan(Math.PI * angle / 180));
    this.sliceCoef = (this.FallDistance * Math.Sin(Math.PI * angle / 180)) / this.Width;
    this.DropSettings = new DropSettings(0, fallDistance, Constants.ANIMATION_DURATION);
}

It changes not only the angle, but every aspect of the rain that depends on the angle.
Now, it’s easy to change the wind speed:

// Speed changed handler
private void SpeedSelector_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    this.HideArrows();
 
    switch (this.SpeedSelector.SelectedIndex)
    {
        case 0:
            {   // Light rain
                this.light1.Visibility = this.light2.Visibility = this.light3.Visibility = System.Windows.Visibility.Visible;
                this.rain.ChangeAngle(this.lightAngle);
                this.WindSound.Volume = 0.3;
                break;
            }
        case 1:
            {   // Medium rain
                this.medium1.Visibility = this.medium2.Visibility = this.medium3.Visibility = System.Windows.Visibility.Visible;
                this.rain.ChangeAngle(this.mediumAngle);
                this.WindSound.Volume = 0.6;
                break;
            }
        case 2:
            {   // Rough rain
                this.rough1.Visibility = this.rough2.Visibility = this.rough3.Visibility = System.Windows.Visibility.Visible;
                this.rain.ChangeAngle(this.roughAngle);
                this.WindSound.Volume = 0.9;
                break;
            }
    }
}

Of course, changing the wind speed affects the Volume property of the media file. That’s how you volume up or down an audio.
Conclusion
In this article I add sound effects to my rain simulation. Moreover, I build some visuals to change the wind speed. I strongly encourage you to use MediaElement when dealing with media files. It provides you with all you could need. Or solid base for all you could ever need!
Feel free to ask or comment!



Simulating rain in Silverlight Part 3 - Adding wind effect
editorial@silverlightshow.net (Lazar Nikolov ) — Wed, 28 Sep 2011 11:47:00 GMT

This article is compatible with the latest version of Silverlight.
Introduction
This is the logical continuation of my article "Simulating rain in Silverlight Part 2 - Optimization". 

More resources...

    Free SilverlightShow Webinars 
    Get Started with Silverlight 4 
    'Getting Ready for Microsoft Silverlight Exam 70-506' Ebook 



($9.99)
     All SilverlightShow Ebooks 


In this publication, I will add wind effect to the rain. And why is this wind effect the logical extension of the rain? Obviously, the nature rarely brings us the rain without a wind. Furthermore, it is not that trivial to add the wind effect...

 
Ок, let's take a good look at the phenomenon, just to make sure we have a solid understanding of what we're trying to simulate. Our simulation will assume the wind is constant. This way we avoid the random fluctuations of the rain drops. Why is this? Since Silverlight does not limit you, just experiment with it by yourself. Clear, we have rain drops, constant wind blowing the scene, and that is...just deal with the angle the drops are falling. 

From this point on, I will expect you to have read my previous articles, "Simulating rain in Silverlight" and "Simulating rain in Silverlight Part 2 - Optimization" since I am going to build over them.
Before I begin with the problem, here is a demo:
View live demo - 30 degrees angle
Download source code
What is the problem?
What are we up to now? In the previous articles we have the rain with the falling straight down drops. Now we will alter the angle of the drops to simulate the wind effect. You would say “Okay, that’s easy, just change the angle in the RotateTransform in the algorithm and it’s over”. I wish it was that easy. 
Changing the angle in the transformation does actually resemble the wind effect, but having the scene in the Canvas, we have to slice two portions to keep the picture consistent. First, we have drops from the left of the scene that need to be hidden after reaching the scene border. And then, we have the drops from the right that need to be hidden until reached the scene border.
And,
What is the solution?
Not that hard, actually, I promise. Just simple math...trigonometry. 
We have three types of drops in this simulation. One that falls all its way in the scene. Other that starts in the scene and falls until hits the left border of the scene. And last, the drops that start their way outside the scene and, at some moment, enter the scene until they fall.
We don’t need to pay any special attention to the first type of drops since they just need to have their angle set. It is rather different with the rest of the drops. First, we need to calculate what the point in the scene that distinguishes the first from the second type is. I call this property Slice. Having the height of the scene and the angle you simply use the tangent of the angle. Based on Slice, I need the slice coefficient:

 

this.Slice = ( int )( height * Math.Tan( Math.PI * this.Angle / 180 ) );
this.sliceCoef = ( this.FallDistance * Math.Sin( Math.PI * this.Angle / 180 ) ) / this.Width;

Having this information, it is easy to determine what type is a drop. Of course, the third type is easily distinguishable using the right border of the scene.


int leftMargin = Convert.ToInt32( rand.NextDouble() * ( this.Width + this.Slice ) );
this.sceneDrops[ currentDrop ].Margin = new Thickness( leftMargin, 0, 0, 0 );
double coef = ( double )leftMargin / ( double )this.Width;

The drop is Type 1 if the coefficient is less than the slice coefficient:


if ( coef <= this.sliceCoef )
{
    int newFinalHeight = ( int )( ( leftMargin ) / ( Math.Sin( Math.PI * this.Angle / 180 ) ) );
    this.sceneDrops[ currentDrop ].FallDistance = newFinalHeight;
    this.sceneDrops[ currentDrop ].FallTime =
        TimeSpan.FromMilliseconds( Constants.ANIMATION_DURATION.TotalMilliseconds *
        ( ( double )newFinalHeight / ( double )this.DropSettings.FallDistance ) );
}

To calculate the new length of the fall, that is the fall height, we use trigonometry. Of course, we also must alter the duration of the fall.
Similarly, to calculate the way of Type 3 drops, we use this code:


if ( coef >= 1 )
{
    int newInitialHeight = ( int )( ( double )( leftMargin - this.Width ) / Math.Sin( Math.PI * this.Angle / 180 ) );
    this.sceneDrops[ currentDrop ].FallInitialHeight = newInitialHeight;
    this.sceneDrops[ currentDrop ].FallTime =
        TimeSpan.FromMilliseconds( Constants.ANIMATION_DURATION.TotalMilliseconds *
        ( ( double )( this.FallDistance - newInitialHeight ) / ( double )this.FallDistance ) );
}

And voila! That was the main part of it all. Wasn’t that hard, right?
Conclusion
To summarize, in this article we’ve simulated wind effect applied to the rain effect from my previous article - "Simulating rain in Silverlight Part 2 - Optimization". In my next article, I will add visuals to harness and change the speed of the wind through UI. I will also create sound effects for both wind and rain to “color” the scene. J








Book review: XNA Game Studio 4.0 Programming: Developing for Windows Phone 7 and Xbox 360
editorial@silverlightshow.net (keyboardP ) — Tue, 27 Sep 2011 02:32:00 GMT

Don't miss...

    Webinar recording 'XNA for Windows Phone 7' 
    WP7 series by Andrea Boschin 
    XNA for Silverlight Developers Ebook: 



($2.99)
     All SilverlightShow Ebooks 

This review is for the book 'XNA Game Studio 4.0 Programming – Developing for Windows Phone 7 and Xbox 360', and has been submitted by a member of the Windows Phone 7 User Group - a user group supported by SilverlightShow.

We support user groups with books, swag, events promotion, free event passes and others. Contact us to get support for your user group. 

  
Introduction
The full title of the book is “XNA Game Studio 4.0 Programming – Developing for Windows Phone 7 and Xbox 360 (Developer’s Library)”. It’s quite a descriptive title in itself, pretty much summing up what to expect. The book is not designed specifically for Windows Phone 7 developers, since XNA can run on the Xbox and PC, but it does include Windows Phone 7 specifics (more on that later).
When it comes to technical books, much of its integrity can be obtained by looking at the authors’ achievements and relation to the subject at hand. With that in mind, XNA Game Studio 4.0 Programming has a solid foundation since the two authors, Tom Miller and Dean Johnson, are actually part of the XNA development team, which is a major advantage the book can boast.

 
Content
Being a “Developer’s Library”, this book is packed with content. Each topic is covered in enough depth to provide developers with enough information to find out how to implement features using good programming techniques. The structure of the book is discussed in the next section, but each chapter contains a decent step by step guide on implementing the topic at hand. It also provides background information on what’s happening as well as detailed code so that the reader can understand what the code does and adapt it to their projects. Being a reference book, the code isn’t overly verbose and so the reader can jump in to any chapter, find out how to code that specific feature and get back to their project without having to rely on any previous work. The quality of code is great and the custom Avatar animation chapter is certainly something that shines. 
Structure
The subtitle of the book, “Developer’s Library”, should not be underestimated as this book really does serve a purpose and does it very well. Many XNA books I’ve encountered go down the path of working with the user to build a game from scratch. Starting from a new project, the author would explain to readers how to display sprites, and then move on to input, effects, audio and so forth. These types of books certainly have their place, but XNA Game Studio 4.0 Programming takes a different approach. Instead of guiding the user step by step through a game, most chapters are treated in isolation. That is, you end up creating new projects as you progress through the book, instead of continuing with one project and expanding on it. This is a great approach to take, especially for a book that’s designed to be a reference, since it means that the reader can jump to any topic and immediately be able to implement the relevant feature without having to code previous projects. It also means the user can jump from topic to topic if they are already experienced with XNA and want to simply learn more about specific features. 
The downside to such an approach is that newcomers to XNA, or game programming in general, may not necessarily find it easy to create a complete game from scratch. Whilst they will learn a lot, certainly enough to create the components of great games, they may find it difficult connecting everything together into one game. However, this book does not claim to be for beginners and, as such, I do not hold this point against it. XNA Games Studio 4.0 Programming aims to be a reference book and it sticks to that philosophy very well.
I’d like to also give kudos to the authors for adding a chapter on 3D math basics. It’s a topic often left out of game development books despite math being fundamental to many games. If you’re proficient with vectors and matrices, it’s a chapter to skip, but it’s a great addition for those unfamiliar with it or need a quick refresher course.

 
Windows Phone 7
Although this book covers XNA in general, it does give specific information about Windows Phone 7. For example, it explains how to implement the various Windows Phone 7 specific features such as the accelerometer and location services. It also discusses how to implement the radio, Launchers and Choosers and tombstoning. The sections for each of these are succinct, but like the other topics in the book, they come with code to show you how to implement the features in XNA. As a side note, this book doesn’t discuss the Mango SDK features, presumably because the SDK was publicly released after the book has been completed.

 
Conclusion
XNA Game Studio 4.0 Programming is a very good reference book and provides a lot of code, as well as solid explanations, on pretty much all aspects of the XNA framework. With each chapter having a new project, it makes it very easy to just skip to your chapter of interest and be shown how to implement the feature from scratch. If you’re new to XNA, or game programming in general, I recommend you buy an introductory book to complement this one. Although this book has small projects that demonstrate the topic at hand, it may be a bit too disjointed for newcomers who want to create a game from scratch straight away. As a side note, this book assumes you’re familiar with C# as do many other XNA books. 
However, as mentioned previously, this book is a “Developer’s Library” and not a beginner’s guide. I highly recommend it to anyone using XNA. Those who already have experience with XNA will find it a nice desktop reference to have for those moments where you don’t know, or have forgotten, how to do certain things. The book tries to cover all topics in reasonable depth and there are many small details that often don’t get mentioned in other books. If you’re new to XNA, you’ll find it a nice book to be able to jump to when you want to find out more about a specific topic. 
There are many XNA tutorials on the web and, of course, the MSDN documentations. However, XNA Game Studio 4.0 Programming – Developing for Windows Phone 7 and Xbox 360 (Developer’s Library), centralizes all the key aspects of the XNA framework into one tidy book, which should be on the desk of any developer creating XNA projects. 


Book review: Professional Windows Phone 7 Game Development
editorial@silverlightshow.net (pauliom ) — Fri, 19 Aug 2011 08:23:00 GMT

Don't miss...

    Webinar recording 'XNA for Windows Phone 7' 
    WP7 series by Andrea Boschin 
    XNA for Silverlight Developers Ebook: 



($2.99)
     All SilverlightShow Ebooks 

This review is on the book 'Professional Windows Phone 7 Game Development: Creating Games using XNA Game Studio 4', and has been submitted by a member of the Windows Phone 7 User Group - a user group supported by SilverlightShow.

We support user groups with books, swag, events promotion, free event passes and others. Contact us to get support for your user group. 
 
Introduction
Writing a book for XNA on Windows Phone 7 (WP7) is challenging proposition, not because it is a difficult subject but because of the varied audiences. The opening chapter of ‘Professional Windows Phone 7 Game Development – Creating Games Using XNA Game Studio-4 (Wrox – Chris G.Williams, George W.Clingerman)’  explains who the book is pitched at; XNA developers who want to take advantage of a WP7 mobile platform, iOS/Android developers who want to add WP7 to their channels, and the .net developer who is a mild mannered business pro by day but wants to flex those gamer muscles by night. So is it possible to write a book to satisfy such a range of skills?
 
Topics by example
The opening chapters give a quick but good account of the WP7 platform and the developer tools you will be using. Once past the ‘Getting Started’ chapters you start getting into the WP7 technologies. When the book introduces a new technology/topic, such as Orientation or the Accelerometer, it does so by taking the reader through a small XNA project. The style works well; you end up with a number of projects each concentrating on a specific subject. This avoids some of the pitfalls of having too many new features and not knowing which one is wrong when the application crashes (perhaps that’s just me). It is also clear that the authors have tried to write the code samples to provide reusable utilities, not only for other WP7 applications but also with one eye on porting to other XNA platforms such as the Xbox. The obvious example of this is for input. You’ll learn about touch specific gestures (touch is not only on the phone) and that WP7 only has one XNA controller. However, rather than show samples dealing with just the one controller it includes code to handle multiple controllers (players). You could argue that’s confusing but I like that it reminds you to design for different channels and for potential future enhancements to WP7.
 
XNA or Windows Phone?
As you would expect from such a book the subjects covered vary from those focusing on XNA (such as game loops, controllers, handling screen/state transitions, etc) to those more aligned with WP7 (accelerometer, vibrate, handling calls, state management, etc). Some topics, such as background music or the back button, have their own very specific XNA & Phone flavours to them and the book does particularly well in making sure you are aware of the certification issues and pitfalls around those subjects. 
 
3D World
Previously when reading “learn gaming” books they tend to start with 2d as a basic course and then keep 3d for the advanced. The authors have decided that they can unleash 3d onto you. I think that given XNA is more 3d oriented this makes sense. However, it does present a problem; the book has to introduce 3d modelling tools. It does a good job at helping you dip your toe in the water with ‘Blender’ but do not expect in depth tutorials, it’s left up to you to grapple with the complex 3d modeller of your choice. 
Once you have your models you are shown how to animate and transform them. I found this section to be a little light on content but since it is a big subject the book does direct you to the samples from Microsoft rather than simply regurgitate what you can get for free. 
 
A Connected World
Today’s gaming world often involves the internet. Although WP7 does not yet have the peer-to-peer connections for what most people would consider a true network game, the book takes a couple of chapters to introduce how you might exploit its networking capabilities. This is split into two main camps; notifications you can provide/receive on the phone and consuming web services via WCF/REST. The book uses the examples of a high-score and a game match-making service for the tutorials. This area represents a real problem for the authors. Pitch this too low and risk really boring the .net developer, too high and you’ll lose new-comers to web services. I feel it was a little too low and I confess that I became bored quite quickly, but it is a good introduction to web services so it just depends on the reader’s needs.
 
More Phone
The remainder of the book focuses on WP7 features that really do not have a great deal of interest to the gamer. I feel a bit harsh writing that since the chapters culminate on a jigsaw picture puzzle utilising the picture chooser/camera. So sure you can use all the features to create some creative games but for me this was an interesting aside rather than “real” game development.
 
Can I write a game?
Having a book that talks about phone and XNA technologies is all well and good, but the real question is, “does it help me write a game?” It seems to me that the authors were stuck with a dilemma. Do they show small samples to help you understand a specific technology or do they introduce a sample game and take you along for the ride by slowly implementing it? As already mentioned they opted for the small samples but eventually, about half-way through the book, you are rewarded by implementing a full game, ‘Drive & Dodge’. It’s a simple game and uses all the techniques and technologies prior to the introduction of 3d. The second sample, ‘Poker Dice with Friends’ utilises the web services and 3d techniques. I don’t think anyone would expect to immediately be writing the next Halo but at what can you expect? The criteria I use to judge the level of a gaming book includes; collision detection, animated sprites and how to increase the speed/complexity of a game. These areas are covered but only at a basic level. You will certainly have enough skills to move assets around a screen, run a 3d animation and detect collisions by simple bounding areas. You are shown how to adjust movement based on elapsed time. However, I want to write more compelling games where I need much better collision detection than a bounding square. I want to animate Sonic as he jumps and spins. I want the on-coming obstacles on the road to hit my car rather than leap-frog past them because of the displacement due to speed and elapsed time.
Recommendation
I believe that the book should really be entitled, ‘Introducing XNA Windows Phone Development’. As an introduction it is good and provides you with a set of useful classes. However there is room for improvement. I would like to see it explain how to add a texture to a project. The downloadable solutions should be updated to the current version of XNA – can you tell I wasted time on that? Also much of the code is repeated and it does start to resemble a code typing marathon from a late 80s computer magazine. But these are not big problems and I would happily recommend this book for those gaming newbies – so those .net business pro’s should read this, although speed read the web services. Those with previous game writing experience will learn about WP7 touch and other subjects specific to the phone, so there is certainly something for you. 
Overall it’s a good book; if you’re new to game development then consider it an introduction, if you do not know WP7 then it will plug a lot of gaps for you. 


Book Review: Windows Phone 7 Game Development
editorial@silverlightshow.net (lookitskris ) — Thu, 18 Aug 2011 15:34:00 GMT

Don't miss...

    Webinar recording 'XNA for Windows Phone 7' 
    WP7 series by Andrea Boschin 
    XNA for Silverlight Developers Ebook: 



($2.99)
     All SilverlightShow Ebooks 

This review is for the book 'Windows Phone 7 Game Development', and has been submitted by a member of the Windows Phone 7 User Group - a user group supported by SilverlightShow.

We support user groups with books, swag, events promotion, free event passes and others. Contact us to get support for your user group. 

 
Gaming has exploded in popularity in recent years, more so on mobile devices. With these devices getting more powerful and more accessible, a wealth of possibilities is now open for developers.
There is no denying that game development is still a difficult task, but there are a wealth of resources, including this Windows Phone 7 Game Development book, to help you get well on your way to defeating goblins, winning a drag race or concurring a new world.
 
The Book
 
Windows Phone 7 Game development is, overall, a really great book and resource. Developers with a background in .NET/C# development will gain the most from this book, and even seasoned game developers who are new to the windows phone 7 platform will pick up a thing or two. However, this book is not aimed at developers who are new to programming or have little to no experience with .NET/C#.
 
XNA
 
The general order of the book is great and flows nicely. Proceedings start with an introduction the Windows Phone 7 landscape with getting started tutorials centred on XNA. These lessons focus on 2D gaming and demonstrate how to draw sprites and text to the phone screen.
After this, the author moves on to creating a reusable game framework. To me, this is quite a risky thing to be talking about from Chapter 2 but I feel it works really well. 
Right now, there are no adopted patterns / frameworks for XNA, so getting developers to think about this early on is great. This framework is then used to build a small space ship game and is developed in subsequent chapters.
The next few chapters are then used to introduce some more key concepts and then implement them into a working game that was started in the previous chapter. User Input discusses how the user can interact with a game – Keyboard, Touch etc. and Sounding Out with Game Audio discusses how to add sound effects and music to the game.
By this point, the reader is now in a great place to understand 2D games in XNA, but this is only part of the story. The next few chapters after this are where the real take-away content begins – a world of 3D!
What I really like here is that the author has brought it back and explains the core mathematics needed to create 3D worlds. these are then implemented within the context of XNA. This really adds value as understanding vertices, matrices, rendering, depth buffers etc. are essential and the knowledge gained here can be applied to other frameworks and platforms too. 
The sample games are also really great, and include flying a paper aeroplane around a 3D skybox. Very cool!
After this, there is some more value-added knowledge to be gained from the “enhancing your game” and “application life cycle” chapters. Here, features such as a settings class and a high score table are added to the game framework and other content covers phone specific events and persisting game data.
 
Silverlight
 
This is a relatively short chapter that introduces Silverlight as a game platform.
The section starts with an introduction to Silverlight and takes a walkthrough the tooling and languages before delving into the controls that come out of the box with the framework. 
Once this has been explained, the game specific Silverlight content begins with a look at sprites, animations & storyboards, events, input and a discussion on performance.
The final Silverlight specific chapter demonstrates Navigation, Game State, adding Music & Sound effects and using the XNA audio library within a Silverlight project. 
In my opinion, this content is great at what it explains, but in comparison to how in depth the XNA content goes, it feels a little out of place. If you are looking at using Silverlight to create a game, you might be better placed finding another book.
 
Distribution
 
The final part of the book is framework agnostic and covers how to distribute your game. This covers testing, trial mode, promotional upgrades and phone specific features such as theming.
Finally, there is content on the submission requirements and a walkthrough on how to prepare your game for submission to the marketplace.
The book ends with some notes on how to port your code to other platforms, and this includes making your XNA game run on Windows and your Silverlight application run in the browser.
 
Conclusion
 
Overall, this book is fantastic if you are a developer who has some C#/.NET experience and you are looking to create games on Windows Phone 7. If you are looking to create games in Silverlight or have little to no experience with programming, you will be better placed seeking a different book to get started.


XNA for Silverlight developers: Part 13 - Mango (2)
editorial@silverlightshow.net (Peter Kuhn ) — Mon, 20 Jun 2011 11:42:00 GMT
Are you interested in creating games for Windows Phone 7 but don't have XNA experience? 

Watch the recording of the recent intro webinar delivered by Peter Kuhn 'XNA for Windows Phone 7'.



Don't miss...

    What is Windows Phone series 
    XNA article by Levente Mihály 
    WP7 series by Andrea Boschin 
    The XNA series is now available as a fully offline resource 


     All SilverlightShow Ebooks 

This article is compatible with Windows Phone "Mango". 

Latest update: Aug 1, 2011.
In the last part of this series we've taken a look at one of the major new features in the upcoming Mango update for Windows Phone: integrating Silverlight and XNA in the same application, which is a thrilling opportunity for both normal application developers to enrich their applications with 2D/3D graphics content as well as game developers to simplify development of menus and other screens that require a rich user interface. In this part we'll take a look at the other new features Mango will bring that are particularly interesting to game developers. Remember that you need the beta version of the developer tools if you want to try any of these features yourself.
Fast Application Switching
With the update, the execution model of Windows Phone will be improved. In particular, a new "Dormant" state will be added to the application life cycle. The way this works is that when the user navigates away from your application, instead of tombstoning it right away, it is suspended in a way that preserves the whole application state intact in memory. The advantage of this is that you do not need to restore this state when the user returns to your application. Only if the user continues to work with the phone and the operating system eventually gets into the situation that it needs to free resources (memory) to guarantee a great user experience for a newly started or the currently running application, your application will be tombstoned.
To give the developer the possibility to distinguish between the dormant and tombstoned state, the Activated event of the PhoneApplicationService now provides an IsApplicationInstancePreserved property in its event arguments. If you want to benefit from the new fast application switching, you should not do any of your normal tombstoning restore procedures when this property is true. Everything is just as the user left it, even running timers and similar things are restored automatically. What you do need to do is check and restore external resources, for example when you had open network connections. The new code samples for the Mango update include an Execution Model Sample that demonstrates the feature in all details.
Debugging Tombstoning/the Dormant State
The Windows Phone emulator you use to develop your applications fully supports the new feature. In some cases this can be undesired, for example when you want to test your application's behavior with tombstoning and activation after it had been terminated. One nice feature of the new Windows Phone development tools is that you can influence this behavior in the project properties in Visual Studio:

When you check the above option, your application will be tombstoned when you debug in the emulator – nice!
Note: for XNA projects, the option is located on the "XNA Game Studio" tab in the project properties.
Support for Sockets
The topic of multiplayer gaming has been treated a bit as an orphan for hobby and indie game programmers in the first release of Windows Phone 7. The platform of course already has networking options, but they're based on web services and hardly allow more than implementing turn-based multiplayer games. The upcoming platform update adds support for sockets to the phone, which is much more suitable to implement a sophisticated, real-time multiplayer gaming experience. Both UDP and TCP clients are supported.
I have written a separate article on socket support in Mango that implements a small sample using a Windows console application as server. You can read this post on my blog; it also provides the full source for download. The code samples for Windows Phone also have a complete sample for this new feature: "Tic-Tac-Toe Over Sockets" is a complete Tic-Tac-Toe game that connects to a remote server an lets you play against a (not so brilliant :]) computer AI.
Sockets surely are a complex topic with a lot of subtle issues you can trip up on, and implementing your own solution on top of it can be troublesome. However, I expect that frameworks and helpers will emerge in the future and open the way for a broader audience to benefit from this feature easier.
Profiling
Games are probably the category of consumer software that has the longest tradition in performance optimization. Even today games on the desktop are optimized at a really low level, for example by implementing the most crucial routines in assembly. On the phone there is nothing like this, but still optimization is an important topic, especially given the limited resources available on the platform. A lot of developers not only make use of tools like profilers once they run into performance problems, but they also are interested in getting that information to optimize for power consumption or response times to user input. Luckily, with the upcoming Mango update, there will be a built-in option for that.
To start a new profiling session, you have to choose the new "Start Windows Phone Performance Analysis" option from the Debug menu in Visual Studio:

The next window enables changing some of the parameters of the session. I don't know if the "Memory" option is disabled because of the beta status or if it is simply not supported in the emulator.

You should take that warning seriously – it usually does not make any sense to profile the emulator as its performance has nothing in common with real devices. You cannot even relate your observations to real world numbers by "scaling the numbers" or similar; often the bottlenecks and limitations are completely different on the real hardware (here is an example of such an analysis I've done on that topic).

After finishing the profiling session, Visual Studio will present the collected data in the form of several graphs that show the frame rate, CPU and memory usage as well as other data like storyboards and garbage collection events. You can then select time spans and take a look at the details:

You can use the menu marked in the screenshot above to get comfortable access to detailed data about the individual frames, the storyboards and visual tree structure, the loaded modules and the executed functions in the selected time frame. The latter one also allows jumping directly to the related source code if it is part of your own application. A full discussion of how to interpret these results to optimize your application is way beyond the scope of this article. However, the MSDN documentation already has a few How-to articles about optimizing the responsiveness and animation smoothness of your application using the profiler. The general information about the profiling options with detailed explanations of the reports can be found here.
Sensor Input
One of the aspects of sensor input that will be improved is the tooling side. In the new emulator, you will be able to simulate accelerometer input with a nice visual interface, making it a lot easier to test this kind of input for your games in the emulator (without relying on third party solutions for this).

In addition to the improved tooling, the sensor APIs are extended by support for gyroscopes and the compass. If you are familiar with the topic then you know that all three of those sensors are needed to accurately determine the orientation of the device. To spare you from implementing the needed math to combine the low-level data from these sensors, the Mango update also introduces the Motion class. This class can be used similarly like the sensors (using an event-based approach and and the possibility to start/stop the reading of values) and provides MotionReading objects as result. The data included by that class contains the attitude (yaw, pitch, roll), acceleration and gravity information and the timestamp of the calculation. These values allow the implementation of interesting applications (for example in augmented reality scenarios) and games.
Note: Gyroscopes are not a hardware requirement for phone vendors. You have to take that into consideration and take proper action if a gyroscope is not available on the device your application is running on.
Summary
I hope part 12 and this article were able to shed some light on some of the interesting new features for game developers that the upcoming Windows Phone update will bring for you. I think it is obvious that this is not only a small update, but a tremendous step forward towards a more feature-complete platform and an even greater experience not only for the end-user, but also for us developers. Have fun building your dream game!


XNA for Silverlight developers: Part 12 - Mango (1)
editorial@silverlightshow.net (Peter Kuhn ) — Wed, 08 Jun 2011 11:10:10 GMT
Are you interested in creating games for Windows Phone 7 but don't have XNA experience? 

Watch the recording of the recent intro webinar delivered by Peter Kuhn 'XNA for Windows Phone 7'.



Don't miss...

    What is Windows Phone series 
    XNA article by Levente Mihály 
    WP7 series by Andrea Boschin 
    The XNA series is now available as a fully offline resource 


     All SilverlightShow Ebooks 

This article is compatible with Windows Phone "Mango". 

Latest update: Aug 1, 2011.
Although it'll take some months until the final release, the upcoming update for the Windows Phone 7 platform has already drawn a lot of attention, both in the developer community as well as for customers. We were able to see demonstrations of some of the new features early, for example at Microsoft's conference MIX, but the real excitement started when a beta version of the developer tools was released to the public a few weeks ago. In this article we'll take a look at what will change regarding game development; and if you haven't had time to get your teeth into the upcoming features and improvements yet, you'll be surprise just how much is in the box for us with this update.
Integration of Silverlight and XNA
This is one of the biggest improvements of the Mango update, and something that developers have been crying for since the very first moments of Windows Phone 7. Some – like the creative minds in that linked thread – have invented workarounds to enable this feature in some way, but of course all these efforts were futile, since the certification requirements explicitly forbid mixing both technologies. This will change with Mango, in a controlled way that allows integration of both technologies within the same application. Let's see how that works.
Creating the Application
To set up a project that combines Silverlight and XNA, you can use one of the two new templates that come with the beta developer tools for this purpose. The first one can be found in the "Silverlight for Windows Phone" node of the "New Project" dialog of Visual Studio and is named "Windows Phone 3D Graphics Application":

The other template is located in the "XNA Game Studio 4.0" node and named "Windows Phone Rich Graphics Application":

When you compare both templates, you can see that they create the same project structure. The difference is that the template that can be found in the Silverlight node adds some minimal game content (a moving rectangle) whereas the template in the XNA node only has the usual blank cornflower blue screen. If you want to learn about the new feature I therefore recommend using the first template, as the pre-built content helps you understand the involved concepts a bit better.

The Project Structure
The first interesting thing to note when you look at the project is the structure of the solution itself:

As you can see, three projects are created:

    A Silverlight project that is set as the startup project in the solution. 
    An XNA content project. 
    An XNA class library project. 

The reason for this setup is that on the one hand Silverlight always takes the leading role in an integrated XNA/Silverlight application (which might actually be a big advantage for those of you coming from Silverlight development). On the other hand, Silverlight doesn't know anything about XNA content and how to handle it. To solve this problem, the XNA class library is used as "the glue" between the two, meaning the content project is processed by the class library, and Silverlight in turn uses the class library to get access to the processed content.

Apart from that there's nothing special to the XNA parts in this structure. You can use the content project just like we have learned in part 1 of this series. And although you can add code to the XNA class library, you don't need to and simply can leave it completely empty if you like.
The SharedGraphicsDeviceManager
Like I just wrote, Silverlight takes the lead in the concept of integrated XNA/Silverlight apps, which means that the navigation features and concept of pages of normal Silverlight applications fully apply, and none of the central infrastructure elements of XNA, like the Game or GameComponent classes, are used. The idea instead is to explicitly tell the runtime when you want to use XNA rendering, on a per-page basis.
To this end, a new assembly Microsoft.Xna.Framework.Interop is introduced which contains the SharedGraphicsDeviceManager class. That class enables you to use XNA's immediate rendering mode in your Silverlight application and provides access to a graphics device through a property named the same. In the templates, the manager is declared in the application lifetime objects in the App Xaml, and from there on can be accessed using a static "Current" property on the manager class throughout your application, whenever you need to access it.


 1: <Application.ApplicationLifetimeObjects>

 2:     

 3:     <shell:PhoneApplicationService 

 4:         Launching="Application_Launching" Closing="Application_Closing" 

 5:         Activated="Application_Activated" Deactivated="Application_Deactivated"/>

 6:         

 7:     

 8:     <xna:SharedGraphicsDeviceManager />

 9: Application.ApplicationLifetimeObjects>


The pattern to activate XNA rendering is to turn on the so-called sharing mode when the user navigates to a page that contains XNA content, and to turn it off again once the user navigates away. For this, an extension method "SetSharingMode" was added to the GraphicsDevice class.


 1: protected override void OnNavigatedTo(NavigationEventArgs e)

 2: {

 3:     // Set the sharing mode of the graphics device to turn on XNA rendering

 4:     SharedGraphicsDeviceManager.Current.GraphicsDevice.SetSharingMode(true);

 5:  

 6:     base.OnNavigatedTo(e);

 7: }

 8:  

 9: protected override void OnNavigatedFrom(NavigationEventArgs e)

 10: {

 11:     // Set the sharing mode of the graphics device to turn off XNA rendering

 12:     SharedGraphicsDeviceManager.Current.GraphicsDevice.SetSharingMode(false);

 13:  

 14:     base.OnNavigatedFrom(e);

 15: }


It's important to activate sharing mode before you do anything XNA related in your application (like loading content or drawing things), or you will end up with exceptions. 
The "Game Loop"
Speaking of drawing things, you might wonder where you put all your update and drawing logic now that there's no Game class anymore? The solution to this is another core component : the GameTimer class. When you look at the members of that class you should see some familiar faces. It has Draw and Update events, and the GameTimerEventArgs passed into the event handlers has ElapsedTime and TotalTime properties. This is all very similar to the update and draw mechanism of normal XNA games and the information the GameTime class provides. The game timer has additional features though, for example it is also responsible for setting the desired frame rate (corresponds to the TargetElapsedTime property of the Game class). A typical setup of the GameTimer hence looks like:


 1: public GamePage()

 2: {

 3:     InitializeComponent();

 4:  

 5:     // Create a timer for this page

 6:     timer = new GameTimer();

 7:     timer.UpdateInterval = TimeSpan.FromTicks(333333);

 8:     timer.Update += OnUpdate;

 9:     timer.Draw += OnDraw;

 10: }


Like other timers you know from Silverlight and .NET, this one has to be started to actually work too, and it can and also should be stopped in certain situations. Once again the pattern is to activate the timer when the user navigates to an XNA-enabled page, and to stop it when the user navigates away. Combined with the shared graphics devices manager, the code then looks like:


 1: protected override void OnNavigatedTo(NavigationEventArgs e)

 2: {

 3:  

 4:     // Set the sharing mode of the graphics device to turn on XNA rendering

 5:     SharedGraphicsDeviceManager.Current.GraphicsDevice.SetSharingMode(true);

 6:  

 7:     // Start the timer

 8:     timer.Start();

 9:  

 10:     base.OnNavigatedTo(e);

 11: }

 12:  

 13: protected override void OnNavigatedFrom(NavigationEventArgs e)

 14: {

 15:     // Stop the timer

 16:     timer.Stop();

 17:  

 18:     // Set the sharing mode of the graphics device to turn off XNA rendering

 19:     SharedGraphicsDeviceManager.Current.GraphicsDevice.SetSharingMode(false);

 20:  

 21:     base.OnNavigatedFrom(e);

 22: }


In the Update event handler you can place all your update logic like you would in the Update override of the XNA Game class, for example to move your sprites, compute AI moves and similar things. The same is true for the Draw event handler. Here you use the shared graphics device manager to get access to the required GraphicsDevice instance that you need to e.g. clear the screen and draw your primitives. The rest of the method again works like in normal XNA games.
… and the Rest
When you look at the template that we're using, you can find a few additional elements you know from your XNA games here. The App class for example has a ContentManager instance. This central place of definition allows you to access it from anywhere to load your game content. In fact, you are free to load your content at any time you like, as long as you have activated sharing mode before. The recommendation though is to also load the content in the OnNavigatedTo overload of a page where it is safe to do and doesn't interfere with the update and draw events of the timer.
Another thing to note is the "InitializeXnaApplication" method in the App class which creates another GameTimer instance to call the Update method of the FrameworkDispatcher. This is not particularly new to the Mango update. If you wanted to use certain XNA features like the advanced sound playback in your Silverlight application before, you already had to use the FrameworkDispatcher manually to make this work. The template only uses the new GameTimer class to set this up. It's nice to know though that everything's already prepared to also use sound and other XNA features in your mixed XNA/Silverlight app.
Rendering Silverlight and XNA on the Same Page
Without writing any code, the new templates already show how you can mix Silverlight and XNA pages in the same application. But wait, there's more! You can also mix Silverlight content with XNA on the same page. This brings us to another important new class in the Mango update, the UIElementRenderer. This class has only one purpose: to render a Silverlight UIElement into a texture. The texture in turn can then be used in your draw method to be used and rendered in any way you like. To demonstrate this feature, I add the following code to the "GamePage.xaml", which didn't contain any elements until now:


 1: <Grid x:Name="LayoutRoot">

 2:     <TextBlock HorizontalAlignment="Center"

 3:                 VerticalAlignment="Center"

 4:                 Text="Silverlight and XNA"

 5:                 FontSize="36"

 6:                 RenderTransformOrigin="0.5, 0.5">

 7:         <TextBlock.RenderTransform>                 

 8:             <RotateTransform x:Name="Rotate" />

 9:         TextBlock.RenderTransform>

 10:         <TextBlock.Triggers>

 11:             <EventTrigger RoutedEvent="FrameworkElement.Loaded">

 12:                 <BeginStoryboard>

 13:                     <Storyboard>

 14:                         <DoubleAnimation Storyboard.TargetName="Rotate"

 15:                                             Storyboard.TargetProperty="Angle"

 16:                                             From="0"

 17:                                             To="360"

 18:                                             Duration="0:0:2.0"

 19:                                             RepeatBehavior="Forever" />

 20:                     Storyboard>

 21:                 BeginStoryboard>

 22:             EventTrigger>

 23:         TextBlock.Triggers>

 24:     TextBlock>

 25: Grid>


As you can see this looks like normal Silverlight content. I added a grid and a text block. The latter one has a rotate transform and a storyboard that changes the rotation angle so the text does a whole 360 degrees spin in two seconds. Would you run the application at this point, you could not see anything; although the content is defined in the Xaml, rendering of this page is handled by XNA, so the Silverlight bits don't affect what's visible on the screen. To make this work, I have to use a UIElementRenderer:


 1: UIElementRenderer uiElementRenderer;

 2:  

 3: ...

 4:  

 5: protected override void OnNavigatedTo(NavigationEventArgs e)

 6: {

 7:     ...

 8:  

 9:     // create the UI element renderer that covers the whole page

 10:     uiElementRenderer = new UIElementRenderer(LayoutRoot,

 11:         SharedGraphicsDeviceManager.Current.GraphicsDevice.Viewport.Width,

 12:         SharedGraphicsDeviceManager.Current.GraphicsDevice.Viewport.Height);


The constructor of the UIElementRenderer expects the element to render, and the dimensions of the texture to use as a target. In my case I'm simply using the root element and a texture the size of the screen. Of course you can optimize this and only render the actual required parts of the visual tree to the screen, but that's not necessary in this example.
The fact that the UIElementRenderer is fixed to a certain width and height should give you a clue that you need to recreate it e.g. once the layout changes (screen orientation or similar) – you cannot change its texture dimensions after you created it. The important part is that any existing renderer needs to be cleaned up using the Dispose method before you throw it away and recreate it. The same is true if e.g. the user navigates away from the page. Just make sure you be nice and free the resources used by the renderer when necessary.
The last thing to do is to actually render the Silverlight content, first into the UIElementRenderer's internal textures, and then (using that texture) onto the screen. For the first part the renderer has a Render method, and for the second part you can use a normal sprite batch and access the renderers Texture property.


 1: // let the UI element renderer render the current state

 2: // of the Silverlight content to its texture

 3: uiElementRenderer.Render();

 4: spriteBatch.Draw(uiElementRenderer.Texture,

 5:     Vector2.Zero,

 6:     Color.White);


To draw 2D Silverlight elements on top of your other game content, you would make drawing this texture the very last thing in your Draw event handler (so it is rendered on top of everything else). The result is something like this:

The red square is completely handled by XNA (it's actually a red texture from the XNA content project that is moved around in the Update event handler), whereas the text is the Silverlight content rendered on top. The animation of that text is taken care of by Silverlight's animation system. Once again there's potential for optimization – e.g. if you know the Silverlight content's visual appearance has not changed, you do not re-render the texture in each frame.
Even though it looks simple, for other scenarios handling the Silverlight rendering can become more complex. Nick Gravelyn has made a nice helper for full-screen scenarios that deals with some of these difficulties.
Advantages
This feature of integrating XNA with Silverlight has some obvious and some not so obvious advantages and creates new possibilities. One of the obvious uses is to create user interfaces. As we have learned in part 10 of this series creating even simple controls in XNA is tedious and requires a lot of work compared with Silverlight. Some more advanced features like text input can even require a tremendous amount of code on your side if you're trying to integrate it nicely into your game. The possibility to use existing Silverlight UI features to create menu pages for XNA games, or even to create HUD overlays or similar on top of your game content is a great improvement and will speed up those parts of game development a lot. 
Not so obvious improvements are that this feature now enables scenarios that previously simply were not possible with XNA, like using the WebBrowser control or embed video directly in your game. To read more about the revised decision process of choosing between XNA and Silverlight, click here.
Drawbacks
There are also some potential drawbacks of this new feature. One is that if you are a developer who targets all "three screens" (desktop, console, phone) and try to share as much code as possible between those platforms, mixing Silverlight and XNA can even become a handicap, because it is a feature unique to the phone and doesn't port very well.
Another issue is that if you have already invested some time in developing your game in XNA, you may now have to spend some more time to migrate to the new concept. For example, as I mentioned some elements like game components cannot be used in hybrid applications, so you have to at least partly rewrite those and/or change your game code structure. More information and tips on moving from the Game class to XNA/Silverlight can be found in this migration guide.
Conclusion
Even though it has some drawbacks and it's not perfect in every detail (yet), the possibility to mix XNA and Silverlight content has been received extremely well by most developers. I hope that this article has provided some insights into the basic ideas and concepts, and also sparked some ideas how you can use that feature to speed up your development or create exciting new things. Let me if you have any questions or feedback in the comments below, or by contacting me directly. You can download the sample project here:
Download source code


XNA for Silverlight developers: Part 11 - Tombstoning
editorial@silverlightshow.net (Peter Kuhn ) — Wed, 25 May 2011 00:00:00 GMT
Are you interested in creating games for Windows Phone 7 but don't have XNA experience? 

Watch the recording of the recent intro webinar delivered by Peter Kuhn 'XNA for Windows Phone 7'.



Don't miss...

    What is Windows Phone series 
    XNA article by Levente Mihály 
    WP7 series by Andrea Boschin 
    The XNA series is now available as a fully offline resource 


     All SilverlightShow Ebooks 

This article is compatible with Windows Phone "Mango". 

Latest update: Aug 1, 2011.
An often discussed topic on Windows Phone 7 is that of “tombstoning”, which describes the process of your application being suspended and removed from the running processes (think hibernate) to free resources on the phone. The application can be “revived” later when the user navigates back to it. It’s the developer’s responsibility to create a user experience that gives the appearance of a seamless transition between applications even when tombstoning happens. For games, the basic concept is the same as for other applications; however, the available possibilities seem slightly different. In this article, we learn about how to handle the application life cycle in conventional Silverlight applications, and how we can properly do the same in games developed with XNA.
Tombstoning in Silverlight
In a Silverlight application, what you do to handle tombstoning is use the PhoneApplicationService class. This class has a number of events that are raised at different times of the application lifecycle: Launching, Deactivated, Activated and Closing. The logic behind these events is pretty straight forward:

One of the interesting details is that your application might not get reactivated at all after deactivation (see the red arrow). If the user never navigates back to your application and instead e.g. launches a new instance using the start menu, or if your application is completely removed by the memory management at a later point, the Activated event will never occur. This is why you should make sure that all vital data is persisted in the Deactivated event handler, as your application may silently be fully terminated later, without being given another chance to store unsaved data.
Another important thing to know is that deactivation actually is not the same as tombstoning. When an application gets deactivated, it may also get tombstoned, but in certain situations it may not. The documentation mentions that e.g. if the user hits the start and back buttons in quick succession, tombstoning might not happen. It is also known that tombstoning either does not occur or is less likely to occur for certain choosers and launchers. And of course, if your application runs on a device that has the Windows Phone "Mango" update applied, not getting tombstoned right away even is the default behavior. Instead, on this updated platform your application is first put in a new state named "dormant", where it stays fully intact in memory (but without being granted any processing cycles). Only when the operating system needs to free memory for other tasks and applications later is your application eventually tombstoned. If the user returns to your dormant application before actual tombstoning happened, your application will be (almost) as if they never left, without the need to restore it manually for a persisted state.
Tombstoning in XNA
At first look, the Game class in XNA seems to have similar events for the application life cycle: Activated, Deactivated and Exiting. Since you create a game by inheriting from that class, it’s likely that instead of using the events you will override the corresponding methods instead: OnActivated, OnDeactivated and OnExiting. In the following paragraphs, I only talk about the events, but of course everything applies to the use of these overrides too. In addition, the game has an Initialize method that is called at the beginning and hence can be considered as a counterpart to the Launching event.
The problem with this is that the game class events work differently from the events of the PhoneApplicationService, making it much more difficult to handle tombstoning by using them. The sequence and combination the game class events are used also seems a bit confusing on Windows Phone at first. For example, the Activated and Deactivated events are not limited to situations of activation and deactivation; they’re also used when the game launches (Activated) and is shut down (Deactivated), in addition to the Initialize method and Exiting event. Even more confusing, the order these events happen in seems partly illogical. In my tests on both the emulator as well as on real devices, the Deactivated event happened after the Exiting event when the game was actually exited. For "normal" deactivation though the order of events was as expected.
Things become even more problematic with Windows Phone "Mango". When the user navigates away from the game, it is not tombstoned right away anymore, but put into the new dormant state I mentioned above. For the game class events this results in a different behavior with regards to the Deactivated and Exiting events. In RTM, both the Deactivated and Exiting events happen when the user navigates away (tombstoning situation), in Mango only the Deactivated event is used, but not the Exiting event (dormant state situation). Even if the application is tombstoned later, the Exiting event will never occur on Mango.

    
        
                            
            
            Initialize
            
            
            Activated
            
            
            Deactivated
            
            
            Exiting
            
        
        
            Game is started
            
            x
            
            
            x
            
            
             
            
             
        
        
            Game is deactivated/tombstoned (RTM)
                            
            
             
            
            
            x
            
            
            x
            
        
        
            Game is deactivated/dormant (Mango)
             
             
            
            x
            
             
        
        
            Game is reactivated
            
            x
            
            
            x
            
            
             
            
             
        
        
            Game is exited
                            
            
             
            
            
            x
            
            
            x
            
        
    

The reason for this seemingly messy behavior is that these events are not a specific feature of XNA on Windows Phone. In particular, these events were not made to handle the application life cycle on the phone. The original intention of these features on other platforms like the PC and XBox was to provide hooks for when the game gains and loses focus. Also, these other platforms don't have concepts like tombstoning or dormant states, which is why events like Exiting also cannot do justice to the Windows Phone platform down to every detail. The consequence of all this is that these events are not suitable to detect tombstoning or handle deactivation and activation reliably, as the behavior does not allow to distinguish between the different possible causes for the events. 
Now, instead of trying to work around these limitations and somehow arrange with what we are offered by the game class, my recommendation is simple: make use of the PhoneApplicationService class in your games too, and do not rely on the respective events of the game class at all. This is a perfectly legitimate thing to do (it's actually even required for detecting the dormant state of Mango, see below), and we’ll look at that in more detail in a moment.

A note on the Guide class
As we’ve seen in previous articles, the Guide class can be used in XNA for simple dialogs, like message boxes and situations where the user has to provide user input. When you use this class and its dialogs, it’s important to know that they also trigger the Activated and Deactivated event of the game class, even though no tombstoning happens when the game is obscured by the dialogs. Once again the reason for this is that these events originally were meant to detect a focus loss, which of course indeed is what happens here. The corresponding events of the phone application service class are not raised in this case.
Some sample code
Let’s finally dive into a sample to see how all of the above translates into code. To be able to use the phone application service in your XNA game, you first need to add references to the following assemblies to your project:

Microsoft.Phone          

System.Windows

From there, everything is pretty straight-forward. In your game's constructor, you can hook the events of the PhoneApplicationService class as you would in a conventional Silverlight application:


   1: // hook the events of the phone application service

   2: // to reliably detect launching, closing, and 

   3: // activation/deactivation/tombstoning

   4: PhoneApplicationService.Current.Launching += PhoneApplicationService_Launching;

   5: PhoneApplicationService.Current.Activated += PhoneApplicationService_Activated;

   6: PhoneApplicationService.Current.Deactivated += PhoneApplicationService_Deactivated;

   7: PhoneApplicationService.Current.Closing += PhoneApplicationService_Closing;


The actual event handlers then can be used to execute your logic. Just like for other applications, you would make sure that you store all vital data persistently (e.g. to isolated storage) in the Deactivated and Closing event handlers. Temporary data that is only relevant for the current session can be stored to the available transient storage places like the PhoneApplicationService's state property in the Deactivated event handler too. In the Activated event handler, you can restore your game state and also retrieve any temporary data from the transient storage. Finally, the Launching event handler is what replaces the Initialize method of the game and where you execute all the logic required to provide a "new instance launched" experience to your users.


   1: private void PhoneApplicationService_Launching(object sender, LaunchingEventArgs e)

   2: {

   3:     // here you would execute any logic required when the game launches

   4:     Debug.WriteLine("Launching.");

   5: }

   6:  

   7: private void PhoneApplicationService_Activated(object sender, ActivatedEventArgs e)

   8: {

   9:     // execute any logic required after activation

  10:     // => for example, restore from isolated storage, 

  11:     //    and retrieve temporary data from the transient state

  12:     Debug.WriteLine("Activated.");

  13: }

  14:  

  15: private void PhoneApplicationService_Deactivated(object sender, DeactivatedEventArgs e)

  16: {

  17:     // deactivation detected (may or may not result in tombstoning)

  18:     // => make sure all vital data is persisted, and all temporary 

  19:     //    data is stored to the transient state

  20:     Debug.WriteLine("Deactivated.");

  21: }

  22:  

  23: private void PhoneApplicationService_Closing(object sender, ClosingEventArgs e)

  24: {

  25:     // exit detected

  26:     // => make sure all vital data is persisted

  27:     Debug.WriteLine("Closing.");

  28: }


This is a very simple solution to the above mentioned problems that allows you to reliably handle the involved events of the application life cycle for your game too, without having to fight the limitations of the corresponding game class events. The much simpler and more consistent behavior of the PhoneApplicationService is shown by the following table:

    
        
            
            
            
            Launching
            
            
            Deactivated
            
            
            Activated
            
            
            Closing
            
        
        
            Game is started
            
            x
            
            
             
            
            
            
            
             
        
        
            Game is deactivated/tombstoned (RTM)
            
            
            
            x
            
            
            
             
        
        
            Game is deactivated/dormant (Mango)
             
            
            x
            
            
            
             
        
        
            Game is reactivated
            
            
            
            
            
            x*
            
             
        
        
            Game is closed
             
             
             
            
            x
            
        
    

 
Going dormant
In the above table, I marked the Activated event with a small asterisk to remind you that this is the once place where the involved code and logic is different for the RTM and Mango releases of Windows Phone. In particular, the event arguments for this event (ActivatedEventArgs) have been extended in the Mango release, where they contain a new boolean property named IsApplicationInstancePreserved. You should use this property to determine whether your game was actually tombstoned (false), or if it is simply activated after returning from the new dormant state (true).
In the latter case, you do not need to re-create the game's state and retrieve your data from e.g. isolated storage, like you usually would when the game is activated from tombstoning. All the state has been preserved, the game only was put into a frozen state in memory ("dormant"). So, the improved code for the Activated event handler in a Mango compatible game would look like this:


   1: private void PhoneApplicationService_Activated(object sender, ActivatedEventArgs e)

   2: {

   3:     // execute any logic required after activation

   4:     if (e.IsApplicationInstancePreserved)

   5:     {

   6:         // we are only returning from dormant state

   7:         // => no need to re-create any state, it has been preserved

   8:         Debug.WriteLine("Activated after dormant state.");

   9:     }

  10:     else

  11:     {

  12:         // we are returning from being tombstoned

  13:         // => restore from isolated storage, 

  14:         //    and retrieve temporary data from the transient state

  15:         Debug.WriteLine("Activated after being tombstoned.");

  16:     }

  17: }



With this small additional check, you have added support for the new fast application switching feature in Mango, and returning to your game when it hasn't actually been tombstoned will be much faster and smoother for your users – another great improvement of the user experience on Windows Phone which you get almost for free as a developer!

Testing dormant state and tombstoning
A quick note on how to test the new dormant state vs. real tombstoning. By default, when you have the Mango development tools installed, the emulator will behave like real devices and only put your application in the new dormant state upon deactivation during debugging. Sometimes however, you want to explicitly test the code and logic of your game that is executed when it was actually tombstoned. To simplify this, a new feature has been added on the property pages of your game project (tab "XNA Game Studio"):

 This allows you to switch between testing tombstoning and the dormant state in the emulator. I talk a bit more about the new fast application switching feature in part 13 of this series.
Additional considerations and resources
This article doesn’t specifically talk about how to persist and restore data when deactivation and tombstoning happens. If you are interested in that, you can find quite some resources on the web about how to make your life easier with more generic approaches and mini-frameworks for this problem. I’ve written an article on the topic myself which in turn links to additional resources too. Also, even though this is a seemingly straight-forward topic, a lot of not so obvious problems can surface quickly. I’ve talked about the requirements and pitfalls in serializing data for tombstoning in detail in a separate article. This of course also all applies to games.
What we’ve learned here, and especially that last article I’ve just linked to, makes it obvious that tombstoning and properly saving and restoring your data is a topic you should plan ahead thoroughly. In fact, it is one of the crucial points that can make the difference for a great user experience. Even if your users don’t move away from your game deliberately, on the phone there are several unexpected situations that might lead to deactivation and/or tombstoning, for example incoming phone calls. Unfortunately, a lot of the games in the market place today force the player to e.g. restart a level from the beginning after tombstoning. In my eyes this is bad design; what you want to avoid in any case is punish your users for using their phone’s features. Of course it is ok to return to the menu or pause the game on reactivation, and offer an option to continue. But make sure that your game state is persisted and restored as accurately as possible, and users will love the experience.
Summary
I hope this article helped you learn about handling deactivation and tombstoning in XNA, and how to work around the limitations introduced by the built-in features of the Game base class by simply using the PhoneApplicationService in XNA too. We've also seen the new dormant state in Mango, and how easily you can support the new feature of fast application switching in your game.
The very small code samples you can download here only demonstrate the behavior of the built-in features of the Game class for both the RTM release and Mango, as well as the behavior of the PhoneApplicationState events that we’ve looked at in the second part of the article.
Download source code
About the author
Peter Kuhn aka "Mister Goodcat" has been working in the IT industry for more than ten years. After being a project lead and technical director for several years, developing database and device controlling applications in the field of medical software and bioinformatics as well as for knowledge management solutions, he founded his own business in 2010. Starting in 2001 he jumped onto the .NET wagon very early, and has also used Silverlight for business application development since version 2. Today he uses Silverlight, .NET and ASP.NET as his preferred development platforms and offers training and consulting around these technologies and general software design and development process questions.
He created his first game at the age of 11 on the Commodore 64 of his father and has finished several hobby and also commercial game projects since then. His last commercial project was the development of Painkiller:Resurrection, a game published in late 2009, which he supervised and contributed to as technical director in his free time. You can find his tech blog here: http://www.pitorque.de/MisterGoodcat/


Pencho Popadiyn on N-puzzle WP7 application
editorial@silverlightshow.net (Silverlight Show ) — Mon, 09 May 2011 04:04:00 GMT

Don't miss...

    Pencho's 'WP7–Creating Custom Keyboard' article 
    WP7 for iPhone and Android Devs series 
    Cocktail Flow WP7 Application 
    WP7 Development book: 

          
              Show more books...

Next in our WP7 showcase apps comes N-puzzle – a new, free gaming app developed by CompletIT and Pencho Popadiyn. Pencho is also a recognized article author at SilverlightShow (check his contributions). 
Q1. Pencho - please introduce yourself briefly (experience, interests, key projects, etc) and tell us more about the application you created - what are the key functionalities, major differences from other similar applications on the market, why do you think people would want to install this app on their phone?
A. Hello! I’m Pencho Popadiyn, I live in Sofia, Bulgaria and work as a .NET Developer for CompletIT. I am developing Silverlight/WPF since the very beginning. I enjoy programming WP7 in my free time. In fact this is not my first WP7 game. Last month I released my first app, it was a mahjong based game (search for Shisen-Sho in the marketplace). And I received a lot of positive feedback from the users, and that encouraged me to move on. About the puzzle. Well, it is based on the classic and extremely popular N puzzle game, where you have a frame of numbered square tiles in random order with one tile missing. The object of the puzzle is to place the tiles in order by making sliding moves that use the empty space. The game offers a number of built-in images; also the user can choose a custom image from the phone gallery or even to use the today’s Bing image as a source. If you don’t like images, you can play the classic modes with numbers or letters. You can save a game in progress and complete it later; there are four different board sizes and many other features. Here are the links to the game: 

    http://www.windowsphoneapplist.com/n-puzzle_game-a16302.html 
    http://social.zune.net/redirect?type=phoneApp&id=9b99ba3f-2377-e011-9210-002264c2fb72 

                                                                   
Q2. Why a puzzle? How did you get the idea to create this app?
A.Well I developed the same application for Silverlight a long time ago. And now I decided to port it for WP7. By the way, the original Silverlight application is available on SilverlightShow. Check out here.
Q3. Which features were most challenging to develop in this game, and why?
A. Maybe the logic for downloading and using the today’s Bing image feature was most interesting. But generally as I said I had a Silverlight version of the puzzle, so it was relatively easy to port the project to WP7. 

However, since this is my second game, I am trying to take a more general look at the things. I am trying to extract common functionality and build something like an own framework (for internal usages of course). As I come to my code from time to time I am seeing a lot of repeating code and patterns. Besides the standards utilities and helper classes, I and my colleagues are spending some time in discussing and analyzing how to design some more complex stuff. So we could use it in our future projects.
Q4. Could you reveal some tip, some solution you used to work around a specific problem faced during the development of your application?
A. Hmm, that’s interesting question. The game is not complex, so I didn’t have any big challenges. However, during the development I hit several problems. Here are some of them. Let’s take a look at the PhotoChooserTask. It took me four hours to understand that navigating to another page directly from the Completed event is wrong. It leads to unbelievable behavior of the application, e.g. events are not firing, other are fired twice and something similar. 

I found other issues (bugs) with the tombstoning. For example, the Remove method of the application state dictionary is not working correctly, e.g. after the application activation event is raised, the entry is still there. 

One of the biggest challenges was related with the ApplicationBar. The ApplicationBarButton and MenuItem does not allow you data binding and attaching commands to the click events. Since I am a MVVM guy, having code for calling view model’s methods in the code-behind of the view is real pain in the a**. 

What I could advice the developers who are planning to start developing WP7 applications is to make their first steps with caution. There are a lot of unexpected obstacles. Also having WP7 device for testing is almost mandatory. I could tell you for sure, that testing on the emulator is not the same as testing on a real device (mainly in terms of performance and graphics).
                                                                   
Q5. Which technology did you used for your games, Silverlight or XNA?
A.Well, as a developer having experience with Silverlight and WPF, I used Silverlight for developing my first games. But right now I am getting started with XNA and it is not far the moment when I’ll release something written on XNA.
Q6. Do you plan to upgrade the game with any new functionality later on?
A. Yes I’ll definitely do it; furthermore I am planning to do it in the next 2 weeks’ time frame. I have a lot of ideas in my mind. For example, I am planning to add a video puzzle. So, instead of image, the user will be able to select a video for puzzle source. I think it will be really interesting. Also I’ll add history functionality. But first, next week I’ll release a small update for the Shisen-Sho game.
                                      
Q7. How do you see the future of WP7, and applications for WP7?
A. “The future is so bright”, as in the song of C-Block. Ok, now seriously, I think WP7 will transform in a great platform not only for games but for business applications too. We have to be just more patient. Remember what was the situation with Silverlight at the very beginning – lack of features and functionality, bugs, etc. Today Silverlight is a complete platform. The same is the situation with Windows Phone 7. It is just at the beginning of its way. Just wait till the end of the year, when the next major players - Nokia and Mango will enter the gameJ. 
Q8. What other ideas for next WP7 applications do you have? 

A. I haven’t decided yet what will be my next application, whether it will be a game or some application. I have several ideas and I am still discussing them with my colleagues. I am planning to release several apps and games in the next few months. Although they will be relatively simple, I am trying to make each next game much more complex than the previous one, adding more features and logic. I am still not planning to enter deep inside into the muddy water of the game development (for example, to create some complex shooter or action game). I want to build more confidence and experience (to pave the way, so to say)J. I want learn all specifics of the WP7 programming model in great, great details and try different programming approaches first, and then I’ll think for something more complex.
Thank you, Pencho! Wish lots of people would enjoy your game!


Simulating rain in Silverlight Part 2 - Optimization
editorial@silverlightshow.net (Lazar Nikolov ) — Thu, 05 May 2011 00:00:00 GMT

Don't miss...

    Free SilverlightShow Webinars 
    Getting ready for Silverlight Exam 70-506 series 
    ClassifiedCabinet: A Quick Start 
    Pro Business Apps with SL4 book: 

          
           Show more books

This article is compatible with the latest version of Silverlight.



Introduction
Following my first article in this series, Simulating rain in Silverlight, I tried to optimize the algorithm that generates the rain. After the big interest several weeks ago, in this article this time I made some major changes in the code that eventually result in smoother, faster and non-memory consuming technique to simulate rain effect in Silverlight application.This new solution of the problem is based on the first one that you may get acquainted with in the first part of this series - Simulating rain in Silverlight.Before I begin with the new approach, here is a demo of the same rain, but much more intense, a flood rain...View live demo - 1000 drops per second

Download source code




Changes in a brief
The solution that I present you now will dramatically affect the memory that the rain simulation consumes. One of the major drawbacks in the first attempt was that it eventually turned out that in some moment the Silverlight application tries to use your entire RAM. It may happen after hours pouring, or days, but it will. This increasing usage of memory affected the smoothness and CPU consumption as well. However, the algorithm for generating the drops is pretty well designed and working, but it definitely needs some optimization when it comes to memory usage.

The secret key - reusing the drops!
From this perspective, I directed my efforts to exactly this issue. The main difference in this new idea is that I could reuse the drops that have already finished their storyboard. Imagine the following – you have a storyboard that lasts, for example, M milliseconds, C – drops that must be animated per a single interval and N – the interval duration in milliseconds. Then after M milliseconds you can reuse all drops that have finished their pouring. But how many are these drops? Having N milliseconds for an interval and C drops per interval, you have 1000 / N intervals per second and thus (1000 / N) * C drops in a second in total. Multiplying this by M / 1000, you result in the number of drops that will be poured by the end of the first storyboard. This is exactly the number of drops that you need to infinitely simulate the rain. You just need to track the current drop to reuse in a global collection.


private List sceneDrops;
private int intervalStartIndex;

In the constructor, I initialize the collection and fill it with drops (with no rain effects on them applied – these are added in the algorithm):


int dropsCount = Convert.ToInt32(Constants.ANIMATION_DURATION * Math.Ceiling((double)1000 * (double)this.DropsPerInterval / (double)this.DropsInterval));
this.sceneDrops = new List(dropsCount);
             
this.intervalStartIndex = 0;
for (int i = 0; i < this.sceneDrops.Capacity; ++i)
{
    Drop drop = new Drop(this.DropSettings);
    this.sceneDrops.Add(drop);
}

The new algorithm looks like this:


if (this.intervalStartIndex >= this.sceneDrops.Count)
{
    this.intervalStartIndex = 0;
}
 
Random rand = new Random();
 
for (int currentDrop = this.intervalStartIndex; currentDrop < this.intervalStartIndex + this.DropsPerInterval; ++currentDrop)
{
    // Add the drop to the scene
    if (!this.Scene.Children.Contains(this.sceneDrops[currentDrop]))
    {
        this.Scene.Children.Add(this.sceneDrops[currentDrop]);
    }
 
    // Generate the drop depth and scale it appropriately
    double depth = rand.NextDouble();
    this.sceneDrops[currentDrop].RenderTransform = new ScaleTransform
    {
        ScaleX = depth,
        ScaleY = depth,
    };
 
    // Generate angle for the falling drop
    double angle = rand.NextDouble() * 10;
    this.sceneDrops[currentDrop].RenderTransform = new RotateTransform
    {
        Angle = angle,
    };
                 
    // Generate the drop distance from most left border
    this.sceneDrops[currentDrop].Margin = new Thickness(Convert.ToInt32(rand.NextDouble() * this.Width), 0, 0, 0);
 
    // Animate the drop falling
    this.sceneDrops[currentDrop].Animate();
}
 
this.intervalStartIndex += this.DropsPerInterval;


Using GPU Acceleration
So, that was for the memory optimization. There is one more thing that can be done to improve the smoothness. Caching. To enable composition caching at the plug-in level you must set the value of an EnableGPUAcceleration param element to true as part of the object tag that declares the Silverlight plug-in. 


<param name="enableGPUAcceleration" value="true"/>

This allows you to take advantage of the hardware acceleration in the GPU. All this can yield in significant performance improvements in some specific scenarios. To specify that the drop should be cached and benefit from GPU acceleration, I use a BitmapCache object.


<Grid.CacheMode>
    <BitmapCache RenderAtScale="4"/>
Grid.CacheMode>


You can read more about CacheMode in MSDN.

Conclusion



After all above, the first rain simulation I made several weeks ago now looks like a polished one. Thanks to your feedback I was encouraged to spend some time searching for a better approach. As a conclusion, it, again, as it always happens, is obvious and straightforward to realize, just waiting for you to discover it, escaping from the boundaries that you build in front of you...






About the author
Lazar Nikolov is a software developer at CompletIT - the company behind SilverlightShow.net and leader in Silverlight related technologies in Bulgaria. His main interests are focused on Silverlight rich applications and Windows Phone 7 development.
In addition to authoring Silverlight articles (his series on ‘Simulating rain in Silverlight’ became one of the most popular articles on SilverlightShow!), Lazar is involved in the verification of all SilverlightShow articles, making sure that all content is consistent and in-line with the latest Silverlight/WP7 release updates.


XNA for Silverlight developers: Part 10 - UI Elements and Menus
editorial@silverlightshow.net (Peter Kuhn ) — Wed, 27 Apr 2011 00:00:00 GMT
Are you interested in creating games for Windows Phone 7 but don't have XNA experience? 

Watch the recording of the recent intro webinar delivered by Peter Kuhn 'XNA for Windows Phone 7'.



Don't miss...

    What is Windows Phone series 
    XNA article by Levente Mihály 
    WP7 series by Andrea Boschin 
    The XNA series is now available as a fully offline resource 


     All SilverlightShow Ebooks 

This article is part 10 of the series "XNA for Silverlight developers".
This article is compatible with Windows Phone "Mango". 

Latest update: Aug 1, 2011.
Games inherently have a different UI and user experience concept compared to business applications. Where you scroll through endless lists of items and enter data in greyish forms on one side, you use a game pad or touch input to control a character through a thrilling fantasy world on the other side. In some situations however, you suddenly find yourself to be in need of all these boring controls of normal desktop applications for your game too. Whenever you want to create a menu or request certain data from the user for example, you need the same kind of UI in one way or another: text boxes, combo boxes, buttons. In this article, we'll evaluate the options you have in XNA, compare this to Silverlight, and take a quick look at the future.
The situation with Silverlight
Desktop Silverlight has a strong background in business applications, and its little brother on the phone has inherited a lot of the powerful features to create rich user interfaces. Not only do we have a built-in set of all kinds of controls that offer options for almost all scenarios, things like data binding, styles and templates also make it very easy to create appealing interfaces quickly without giving up a clear separation of data and views. A sophisticated event model helps us interact with these controls and react to user input easily, and additional containers and features allow us to create nice screen layouts and dynamic arrangements within minutes. When you are coming from this background, the situation in XNA will be – gently said – shocking.
What we have in XNA
Simply put, nothing of all this. In previous parts, we have talked about some of the involved differences regarding UI elements and user input in both worlds already. I very much encourage you to read Part 1 if you haven't done yet. I explain the difference between Silverlight's event-driven programming model and XNA's polling-oriented design in detail there. In Part 5, when we were talking about touch input for the first time, I also reviewed Silverlight's concept of controls and contrasted that with XNA's much more low-level approach. I won't go into further details regarding these difference in this article again. 
So, what do we have in XNA? The good news is that we have all the tools and possibilities to create a similar user experience at hand. The bad news of course is that we have to do all this manually, and depending on what your requirements are, this may result in a lot of effort and code up to a level where it is advisable to look for other options, like third-party libraries.
A look at a working sample
If you recall the sample we used in the last article you may remember that it already had an options menu that allowed the user to change some (bogus) parameters of the game:

If you inspect the code for this menu, you will see that it actually tries to modularize the involved parts. There are base classes for the menu screen, a derived class for this options menu (all of which are inherited game screens from the last part), and a separate class for the menu entries on the screen that even works with events when the user selects one. The logic to determine whether a menu entry has been selected by the user or not is contained in the "MenuScreen" class and looks like this:


 1: // look for any taps that occurred and select any entries that were tapped

 2: foreach (GestureSample gesture in input.Gestures)

 3: {

 4:     if (gesture.GestureType == GestureType.Tap)

 5:     {

 6:         // convert the position to a Point that we can test against a Rectangle

 7:         Point tapLocation = new Point((int)gesture.Position.X, (int)gesture.Position.Y);

 8:  

 9:         // iterate the entries to see if any were tapped

 10:         for (int i = 0; i < menuEntries.Count; i++)

 11:         {

 12:             MenuEntry menuEntry = menuEntries[i];

 13:  

 14:             if (GetMenuEntryHitBounds(menuEntry).Contains(tapLocation))

 15:             {

 16:                 // select the entry

 17:                 OnSelectEntry(i, PlayerIndex.One);

 18:             }

 19:         }

 20:     }

 21: }


The approach used here is that the input is handled on the screen level. The screen iterates over all controls and uses the available information about the current user input and control dimensions to decide whether a menu entry is affected by the user input or not. Here is a flow chart of how the logic works:

What the sample implementation does when a 'click' is detected is tell the menu entry to raise it's "Selected" event. This may seem a bit convoluted at first, but it actually enables derived classes (like the options menu) to do something meaningful with this event. 
A different approach would be to not have any logic in the screen class itself, but simply pass through the request to handle user input to each one of the controls on the screen. Then every menu entry could decide itself what to do with the input, which would be more flexible. Not matter what alternative or variation you use, this is basically how you would create the core logic for any custom UI concept: Since there is no built-in concept of UI elements in XNA, let alone a mechanism to inform you a particular one has been selected, it really comes down to creating your own elements, and then simply iterating over all of them to see if one is affected by the current user input.
Of course all the menu entries in the example only cycle through a given set of values (including an on/off switch) or implement only a simple increment logic. But based on this rather simple structure you could already build a set of controls that is able to handle a lot of the most common requirements. The "MenuEntry" class is designed very openly for this. By overriding the "Update" and "Draw" methods you are able to change and extend the logic as well as the visual appearance of the entries.
Text input
Things are a bit different for text input you need to request from the user. While it would be possible to design and display a textbox-like control, the problem with this is the input method on the phone device. Apart from few exceptions with hardware keyboards, Windows Phone 7 relies on a SIP (Soft Input Panel). At the moment, there is no way to bring up the SIP to interact with your game, which means you would have to create your own on-screen keyboard. This is something far from being trivial (think different cultures etc.) and would most likely result in a user experience different from the rest of the phone. It also doesn't scale once additional languages are supported by the system and therefore needs adjustments once updates for this are rolled out by Microsoft.
The solution to this once again is the Guide class. It has a method "BeginShowKeyboardInput" that brings up a simple data input screen with a customizable title, description and a text box. It handles all the SIP logic for you, and once the user has finished entering their data, a callback will be invoked to notify you about the result, which you then can use for whatever you want.
This limitation has been heavily discussed in the community. It means that you cannot have a consistent design for the data input screen and your game (you cannot change its appearance), and you also don't have any direct control over the functionality (e.g. you cannot restrict input to certain characters or do other sorts of validation on that screen etc.). We'll see how this will be changed in the future below.
As an example I've extended the sample from the last article and added text input to it. For this, I simply switch to the high scores list when the user taps the game play screen to simulate a successfully finished game. In this case (coming from the game play instead of the main menu) the user is prompted for their name to create an entry in the high scores list:


 1: // is the user supposed to enter their name?

 2: if (EnterHighscore)

 3: {

 4:     // start showing the input screen

 5:     Guide.BeginShowKeyboardInput(ControllingPlayer.Value,

 6:                                  "High Score!",

 7:                                  "Please enter your name",

 8:                                  string.Empty,

 9:                                  KeyboardInputFinished,

 10:                                  null,

 11:                                  false);

 12:  

 13:     // set the flags we need

 14:     EnterHighscore = false;

 15:     _userInputInProgress = true;

 16:     return;

 17: }


The most important argument of the method is the "KeyboardInputFinished" callback, a method which is invoked automatically when the user closes the input screen. The second flag is used to pause our custom update and draw logic as long as the input screen is visible. This is necessary because the keyboard input screen works asynchronously, which means that the game continues to run in the background. The callback implementation looks like this:


 1: private void KeyboardInputFinished(IAsyncResult ar)

 2: {

 3:     // reset flag

 4:     _userInputInProgress = false;

 5:  

 6:     // get the result

 7:     string result = Guide.EndShowKeyboardInput(ar);

 8:     if (!string.IsNullOrEmpty(result))

 9:     {

 10:         // add a bogus highscore entry

 11:         string entry = string.Format("11. {0} - {1}", result, 10);

 12:         _highScores.Add(entry);

 13:     }

 14: }


As you can see, by invoking the "EndShowKeyboardInput" method on the Guide class you will receive the string the user has input. In our case this string is only used to create a bogus additional high score entry, but you should get the idea how you can use this mechanism to query input from the user.

Further resources
Apart from the game state sample that we've used here, Microsoft has also published another example in the App Hub Education section that covers UI elements and menus in XNA. It is named "User Interface Controls" and can be found here. This example contains a set of base classes for the control itself as well as a panel. Derived from this it has an image control, a page flip control to flick through items and scrolling controls to display lists of items. Even if you don't use the code as-is, it should also be possible to get some ideas from the samples to develop your own controls.
In the past there have also been some attempts to create UI frameworks for XNA, some of which looked very promising. Unfortunately a lot of them were discontinued after a while, a few even disappeared completely. One that is still actively developed (and brings a lot more than just UI elements) is the Nuclex Framework which can be found on Codeplex.
Another interesting framework is XPF, which has some strong layout features. It has not yet reached production level quality, but it has nightly debug builds you can use for testing. Apparently the licensing will include a free version for non-commercial and open source development.
Integrating XNA and Silverlight
An obvious solution to all of XNA's lacking UI features on Windows Phone 7 would be to allow mixing Silverlight with XNA graphics in the same application, so a game can make use of Silverlight's powerful features too. In fact, some people started to investigate this very early on, but of course application certification requirements of the RTM version explicitly forbid doing this, so any success with it was futile. 
Things very much change with Windows Phone "Mango", where you have the chance and are allowed to do exactly that. The general application structure is significantly different when you make use of this, because then Silverlight needs to take the leading role, and using XNA is achieved by switching to it from Silverlight using a feature named "sharing mode". I discuss and demonstrate all the technical details in part 12 of this series, which of course also comes with full source code for you to explore this.
The important thing is that you can decide what parts of your game you want to implement with Silverlight, and what parts should be handled by XNA. You can use all of Silverlight's UI features to create and design your menus and other data-centric screens like highscore lists, and then switch to XNA for the actual gameplay and game content rendering. The following diagram shows a logical screen structure for such a setup, with each rectangle representing a phone application page:

But the good news doesn't stop here. You are even able to mix Silverlight and XNA content on the same page if you want. This allows you to e.g. use the more sophisticated Silverlight text rendering directly on your XNA gameplay screen. HUD overlays or other things can be handled with default Silverlight UI elements more easily, and then used in your XNA rendering process with the help of the new UIElementRenderer class. 
The beauty of this approach is that Silverlight elements are not forced into a passive role by this. User input can be routed to these elements, and with a little bit of work you can even use elements like text boxes on XNA-controlled pages, and have the user enter data using the SIP. And of course all the dynamic goodies of Silverlight, for example it's excellent animation features, can be used in this scenario too.
Again, part 12 of this series shows how to do most of this by demonstrating the UIElementRenderer in combination with Silverlight animations on an application page that is rendered by XNA.
Summary
In this article we once again learned that the more low-level nature of XNA (which has a lot of advantages in game programming) comes at the cost of a lot less comfort. Especially when it comes to creating user interfaces like menus things can easily become complex and result in a lot of work, to a point where it absolutely makes more sense to use some already available commercial or free third-party libraries. However, we've also seen that the first major update to the platform ("Mango") brings exciting news about the future of XNA and Silverlight integration, which will make a lot of these things much easier. If you are interested in the updated sample code that contains the user text input code, you can get it here:
Download source code
As always, feel free to add your comments below or provide feedback to me directly.
About the author
Peter Kuhn aka "Mister Goodcat" has been working in the IT industry for more than ten years. After being a project lead and technical director for several years, developing database and device controlling applications in the field of medical software and bioinformatics as well as for knowledge management solutions, he founded his own business in 2010. Starting in 2001 he jumped onto the .NET wagon very early, and has also used Silverlight for business application development since version 2. Today he uses Silverlight, .NET and ASP.NET as his preferred development platforms and offers training and consulting around these technologies and general software design and development process questions.
He created his first game at the age of 11 on the Commodore 64 of his father and has finished several hobby and also commercial game projects since then. His last commercial project was the development of Painkiller:Resurrection, a game published in late 2009, which he supervised and contributed to as technical director in his free time. You can find his tech blog here: http://www.pitorque.de/MisterGoodcat/


XNA for Silverlight developers: Part 9 - Navigation and structure
editorial@silverlightshow.net (Peter Kuhn ) — Mon, 11 Apr 2011 00:00:00 GMT
Are you interested in creating games for Windows Phone 7 but don't have XNA experience? 

Watch the recording of the recent intro webinar delivered by Peter Kuhn 'XNA for Windows Phone 7'.



Don't miss...

    What is Windows Phone series 
    XNA article by Levente Mihály 
    WP7 series by Andrea Boschin 
    The XNA series is now available as a fully offline resource 


     All SilverlightShow Ebooks 

This article is part 9 of the series "XNA for Silverlight developers".
This article is compatible with Windows Phone "Mango". 

Latest update: Aug 1, 2011.
Until now, we have looked at individual features of game programming on the phone in an isolated manner. We learned about graphics, animations, input, audio and others, and for each of these samples, we created new empty game projects and put the logic in the main game screen and few helper classes. In a real world scenario, your game will combine various different aspects and features, and you naturally would want to structure your game a lot more. Once again some of these details are also subject to restrictions given by the certification requirements. In this article, we will take a look at the concept of "places" and game screens that can be used to create a navigational structure for your game. As always you can download the source code at the end of the article.
Certification requirements
In the official guidelines and certification documents from Microsoft games are treated separately in a lot of ways, and they in fact are at liberty to do things normal applications are not allowed or able to do. One particular noteworthy statement can be found in the UI Design and Interaction Guide in the section about game UI design:

For full-screen games, developers are free to implement whatever in-game UI elements they see fit.

This pretty much gives you the freedom to create any UI concept you want for your game as long as it is not an integrated part of a normal application (i.e. not full-screen). If you look through some of the games available in the market place today you can see that developers actively make use of this. Aside from "classic" menu systems that resemble normal Silverlight application design you will notice that there are quite a few that go new ways in terms of user interaction.
The Application Certification Requirements on the other hand make some clear statements on games though. In particular, section 5, which describes the actual requirements, is prefaced with the following note:

These requirements apply equally to an application that implements game functionality,        

commonly referred to as a game.

The decisive part for navigational concepts is located in section 5.2.4 which describes the use of the back button. So, even though your game is free in its UI design and pretty much has to implement navigation manually, you have to follow basic requirements when it comes to navigation, like that pressing the back button on the first screen must exit the game. In addition, there is a requirement specific to games in that section:

d.  For games, when the Back button is pressed during gameplay, the game can choose to present a pause context menu or dialog or navigate the user to the prior menu screen. Pressing the Back button again while in a paused context menu or dialog closes the menu or dialog.  

This is an interesting exception to the normal rules for applications: instead of navigating back to the previous page, you are actually allowed to open a new dialog when the user presses the back button during game play. 
The concept of places
Even though XNA games do not integrate with the built-in concept of pages and the back stack of Windows Phone 7 applications, and you have to create your navigation concept manually, it's well worth taking a look at how this is normally done in Silverlight. After all you will run into many similar questions as with normal apps, and you likely want to offer your users an experience that is similar to what they find on the rest of the phone. Peter Torr has posted an interesting article on something he calls "places" within an application. You can find it here, and if you don't know it you should definitely read it. It deals with some common problems and solutions around the navigation concept on Windows Phone 7. While the default stack behavior of the navigation works well in a lot of situations, there are some situations where this inevitably causes problems. Many of these points also apply to games. Let me give you some examples:

    You don't want to take the user all the way back to your game's splash screen when they use the back button. The main game screen or menu should be the starting point of your game, and pressing back from there should exit the game, even if you initially showed a splash screen before the main menu on startup. 
    You don't want certain dialogs to appear again if the user navigates back. For example, imagine you prompt the user to enter a name for a high score list. If they decide to navigate back from the high score list later, you want to skip over that dialog. 
    If your game is segmented into levels, it's likely that once the user has finished one, you prompt them to start the next one or show some intermediate/summary information in between levels. If the user navigates back from the main game screen, you however want return to the menu of course, and not back to those intermediate level transition screens. 

So it's obvious you need to think about the navigation flow through your game and what screens you want to make distinct "places". Peter's above linked post assists and tries to give you some clues how to make this task easier, for example by asking questions like: "Would the user explicitly want to visit this screen? Would the user remember they were on this screen, and want to return to it?" This is the conceptional work you have to do before you actually start implementing your game's architecture.

This is a sample of what paths a user could take through the different screens of a game. As you can see there are a lot of situations where a stack concept works very well (the whole options section, for example). In other places sub-elements need to be left out of the stack (individual levels of the gameplay). And then there are situations where you need to find a way to break out of the stack concept completely (splash screen, from a finished game to the high scores and back to the main menu).
Game screens and a Screen Manager
Individual game screens and having some sort of manager that controls the currently active screens is something common in games, and I have used it for many years. It was in fact something I already described in my first game programming tutorial ten years ago. For Windows Phone 7 Microsoft provides its own sample for that, and it's really worth investigating because it's well thought-out and a good start to build upon. That sample is named "Game State Management" and can be found in the App Hub:
http://create.msdn.com/en-US/education/catalog/sample/game_state_management
When you download and simply run that example you can see that it has most of the above already covered: you see a main menu with some entries that take you to an options screen or to the actual game. The screens use nice transition effects like fade in/out as well as animations. There's an intermediate loading screen for long-running actions which of course is skipped when you navigate backwards, and the back button is fully functional. Let's dissect this sample to see how it works.

The Game Screens
All screens in the game derive from a base class "GameScreen" that handles most of the work required for the transitions, and it provides a bunch of virtual methods you can override to plug-in your own logic for loading and unloading content, processing input as well as update and draw your content. There are additional methods for topics we haven't covered yet, like serializing and deserialization, and some more convenient methods and properties. All other game screens in the sample make use of this base class and override the default behavior and properties to create their own functionality:

The interesting part is that this small example already shows the flexibility of this system. For example, the "BackgroundScreen" is a very static screen that only shows the background image for the menus. It does not participate in transitions at all, thus creating a consistent look between the different menus. The user doesn't really perceive the menu screens as isolated parts because the background acts as a bridging element for all of them. On the other hand, the menus show that this concept includes the ability to have multiple screens visible at once; they are only put on top of the background screen, and together they form the final user experience.
The "LoadingScreen" also is a special screen in that its only purpose is to handle the transition between other screens while displaying a notification to the user. It has some built-in logic to wait for all the current screens to transition off, tell the screen manager to load the follow-up screens and eventually remove itself. In the sample this is used to load the "GameplayScreen", where the actual game itself "happens". This of course is the most important screen of them all, because all your game's logic will be implemented and/or used here. This is the place where we would add what we have learned in all the previous parts of this series so far.
Finally there is the "MessageBoxScreen", which isn't even used in the sample (we'll add it in a minute). It demonstrates how to use the concept of having a "Popup" in the screen management. This is another feature that allows you to build additional overlay screens like notifications or to ask the user for confirmation.
The Screen Manager
The "ScreenManager" class in the project is the workhorse that does everything necessary to maintain the current list of screens, handling user input and similar things correctly. It also offers some convenient properties, like global font and sprite batch objects. Since each screen has a reference to the screen manager, they don't have to bother creating their own fonts for example (which of course they still could). In addition to the properties, it has public methods to add and remove screens which are used by the individual screens to initiate the transitions to different parts of the game.
Note: This design decision may seem odd to some at first, because it means the game screens know each other, and control about the flow through the game is distributed across all involved screens. However, it makes a lot of the other available features much easier. I've seen more generic implementations of this concept, where screens don't know about each other and control of transitions is handled in a central place; what sounds like a good idea at first will quickly result in unnecessary difficulties for certain features and over-complicate things in a lot of ways, which especially on the limited phone platform is very undesirable. The number of screens for a game usually won't grow sky high, and normally a "natural" grouping of screens will evolve automatically too (there's no point in jumping from a network configuration screen to the high scores or the gameplay directly) – which will result in a limited set of transition points and keep the structure maintainable.
The logic of the main menu screen is an example of various possible options to control the game flow:

If the back button is pressed, the game is simply exited (contrary to the situation in Silverlight, it's possible to explicitly exit an XNA game). If the user wants to play a new game, the main menu screen makes use of the loading screen to transition to the gameplay. This is necessary because loading all the game content may take a while and a notification should be presented to the user (the sample simulates this by letting the current thread sleep for a while). Behind the scenes, the loading screen uses the screen manager for the necessary transitions. If the user wants to look at the game's options however, the main menu uses the screen manager directly to transition to the next screen:


 1: void OptionsMenuEntrySelected(object sender, PlayerIndexEventArgs e)

 2: {

 3:     ScreenManager.AddScreen(new OptionsMenuScreen(), e.PlayerIndex);

 4: }


The core of the screen manager is the update mechanism. A list of all currently active screens is maintained and processed in reverse order, which means the screen on top is handled first. The screen manager ensures that only the top most screen gets a chance to process user input, and that all screens further down the stack are notified they are covered by other screens, so they can act accordingly (like pause whatever is happening, for example). The draw mechanism on the other hand is pretty simple. The screen manager only iterates over the current screens and in turn calls their draw methods. 
The last detail is how the screen manager is integrated into the game. When you look at the game class you will see that it contains next to no logic. In fact it doesn't even have an own update method anymore. The crucial part happens in the constructor, where the screen manager is instantiated and added to the game components:


 1: // Create the screen manager component.

 2: screenManager = new ScreenManager(this);

 3:  

 4: Components.Add(screenManager);


This is something we haven't used until now. Game components are a way of modularization. You can create game components by deriving from the base classes provided by XNA, and then adding the components to your game class as shown above. All game components registered like this will then be maintained by the game and have their initialize, update and draw (if applicable) methods called automatically. This is a way of keeping your main game code lean and the overall project design better structured. When you look at the screen manager class in more detail you will realize that it indeed derives from the DrawableGameComponent class to enable this feature.
Sample
To get more accustomed to the principle and structure of the game state management example, and to show you how you can use and extend it for your own games, we're going to add a new screen now: a high scores list. The first thing to do is add a new class to the Screens folder and make it derive from the "GameScreen" base class. If you use the "override" keyword you can take a look at your options:

What we are going to do is create some fake high score data in the "LoadContent" method. In a real game this is where you would hit a web service instead, for example. The "Update" method does the layout of the items, and the "Draw" override will draw the high scores list on the screen. Since none of these steps contain anything new to us, I don't show the code here. 
To integrate the new screen with the game, we extend the "MainMenuScreen" by adding another menu entry. We haven't talked about menu systems yet (that will be part of an upcoming article), so I won't go into details here. If you look at how the other menu items are created it's easy to figure out how to set up a new one though:


 1: // in the "MainMenuScreen" constructor

 2: // add a new entry for the high scores

 3: MenuEntry highscoresMenuEntry = new MenuEntry("High Scores");

 4: highscoresMenuEntry.Selected += HighscoresMenuEntry_Selected;

 5: MenuEntries.Add(highscoresMenuEntry);

 6:  

 7: ...

 8:  

 9: void HighscoresMenuEntry_Selected(object sender, PlayerIndexEventArgs e)

 10: {

 11:     ScreenManager.AddScreen(new HighscoresScreen(), e.PlayerIndex);

 12: }


When the new entry is selected, we use the screen manager to add a new instance of the high scores screen. In the following, we'll look at two more interesting aspects with game screens.
Input and a Message Box
To deal with user input, you can override the "HandleInput" method. The argument to that method is an "InputState" object that is a convenient wrapper of the sample project around the currently pressed keys and current gestures. One thing you need to do is handle the back key. When the user presses this key, we simply exit the high scores screen. If the user however taps anywhere on the screen, we want to show a message (to put the included MessageBox screen to some use). 


 1: public override void HandleInput(InputState input)

 2: {

 3:     base.HandleInput(input);

 4:  

 5:     // if the user presses the back button, we exit from the high scores

 6:     // this will re-activate whatever screen was active before (=> main menu)

 7:     PlayerIndex player;

 8:     if (input.IsNewButtonPress(Buttons.Back, ControllingPlayer, out player))

 9:     {

 10:         ExitScreen();

 11:     }

 12:  

 13:     // look for any taps that occurred and show a message box as response

 14:     foreach (GestureSample gesture in input.Gestures)

 15:     {

 16:         if (gesture.GestureType == GestureType.Tap)

 17:         {

 18:             // a very simple message box

 19:             var messageBox = new MessageBoxScreen("A message!", false);

 20:             ScreenManager.AddScreen(messageBox, ControllingPlayer);

 21:         }

 22:     }

 23: }


This code snippet demonstrates how to use the screen manager to add a new screen to the stack. It also shows that we don't need to bother what happens after we exit the current screen. The screen manager will handle this situation for us and transition the underlying screen back in (the main menu). 
The final step to make this work is to define that we are interested in processing tap gestures. This can be controlled for each screen separately by setting a corresponding property in its constructor (again the screen manager will do the rest for you):


 1: public HighscoresScreen()

 2: {

 3:     // we are interested in receiving tap gestures

 4:     EnabledGestures = GestureType.Tap;

 5: }


When you run the sample you can see that pressing the back key returns to the main menu, and tapping the screen opens a message box.
Transitions
At the moment the main menu uses nice transitions when it becomes active or inactive, but the high scores just suddenly appear and disappear. Especially when the screen appears it's overlapping with the fading content of the main menu which doesn't look nice. Let's see how we can make use of the built-in transition features to improve this.
First of all, similar to enabling input gestures, you can tell the screen manager what duration you want for the screen's transitions by setting some properties in the screen constructor:


 1: TransitionOnTime = TimeSpan.FromSeconds(0.5);

 2: TransitionOffTime = TimeSpan.FromSeconds(0.5);


With this in place, you can then make use of base class properties like the "ScreenState" and "TransitionPosition". With the first one you can do a basic check to see if the screen is currently transitioning (on or off), and the second value ranges from 0.0f to 1.0f to describe how far you're into the transition, with 0.0f describing an active screen and 1.0f being fully transitioned off. You can make use of this value to calculate an animation offset or similar, for example. In addition, "TransitionAlpha" can be used to create a (linear) alpha fade effect based on the current transition position.
In our sample, we calculate the offset from the top of the screen depending on the transition position in the "Update" method of the high scores screen. In addition, in the "Draw" method we control the alpha value of the drawn text by the transition alpha value.


 1: // in the Update method:

 2: // top offset

 3: float y = 100.0f;

 4:  

 5: // are we transitioning on/off?

 6: if (ScreenState == ScreenState.TransitionOn || ScreenState == ScreenState.TransitionOff)

 7: {

 8:     var screenHeight = ScreenManager.Game.GraphicsDevice.Viewport.Height;

 9:     var distance = screenHeight - y;

 10:  

 11:     // calculate a new offset depending on the transition value

 12:     y += distance * TransitionPosition;

 13: }

 14:  

 15: ...

 16:  

 17: // in the Draw method:

 18: // determine color

 19: Color color = new Color(255, 255, 255) * TransitionAlpha;


The result is that the high scores list now slides in and out from and to the bottom, and at the same time the transparency of the high score entries is varied.

Summary
By structuring your game using a concept of "places" and screens, you achieve a lot in terms of both user experience and maintainability of your project when it grows. With the Game State Management sample Microsoft already provides a pretty sophisticated mini-framework you can use to built upon or at least to get some ideas for your own implementation. With little work you can extend these classes and – by moving them to a class library – even easily reuse them for future projects. Download the source code below to get the additions we've seen in the last parts of the article. If you have any questions or feedback, please feel free to post your comments or contact me directly.
Download Source Code
About the author
Peter Kuhn aka "Mister Goodcat" has been working in the IT industry for more than ten years. After being a project lead and technical director for several years, developing database and device controlling applications in the field of medical software and bioinformatics as well as for knowledge management solutions, he founded his own business in 2010. Starting in 2001 he jumped onto the .NET wagon very early, and has also used Silverlight for business application development since version 2. Today he uses Silverlight, .NET and ASP.NET as his preferred development platforms and offers training and consulting around these technologies and general software design and development process questions.
He created his first game at the age of 11 on the Commodore 64 of his father and has finished several hobby and also commercial game projects since then. His last commercial project was the development of Painkiller:Resurrection, a game published in late 2009, which he supervised and contributed to as technical director in his free time. You can find his tech blog here: http://www.pitorque.de/MisterGoodcat/


XNA for Silverlight developers: Part 8 - Music and sound effects
editorial@silverlightshow.net (Peter Kuhn ) — Fri, 25 Mar 2011 00:00:00 GMT
Are you interested in creating games for Windows Phone 7 but don't have XNA experience? 

Watch the recording of the recent intro webinar delivered by Peter Kuhn 'XNA for Windows Phone 7'.



Don't miss...

    What is Windows Phone series 
    XNA article by Levente Mihály 
    WP7 series by Andrea Boschin 
    The XNA series is now available as a fully offline resource 


     All SilverlightShow Ebooks 

This article is part 8 of the series "XNA for Silverlight developers".
This article is compatible with Windows Phone "Mango". 

Latest update: Aug 1, 2011.
What would a game be without sound effects and music? Naturally Windows Phone 7 offers enough possibilities to add a rich acoustic experience to your apps and games. However, due to the nature of the device, there are some things to keep in mind. Even with the lack of real multi-tasking, you don't have the whole platform at your disposal exclusively. The user may already listen to music from the media library when they start your game, for example. In addition, a mobile device may also be used in an environment where noise is not welcome. These are things you have to consider when you add audio to your game. Some of these aspects are even regulated in the certification requirements for Windows Phone 7 applications and are a potential source for certification failure if implemented incorrectly. In this article, we'll take a look at how audio can be integrated in your games and what the implications are for playing sound and music in Silverlight and XNA. As always, the source code is available at the end of the article.
Silverlight
In Silverlight, there is a dedicated element for audio and video playback: the MediaElement. This component easily enables playback of audio in your Silverlight application. Simply add an instance of it to your page, point it to the source file (needs to be embedded as "Resource") or an Uri, and set some basic values:


 1: "Media"

 2:               Source="Song.mp3"

 3:               Volume="0.9"                          

 4:               AutoPlay="True" />


Of course you can control the playback through various methods like Play, Pause and Stop, and properties like Position allow to implement seeking and similar features. In addition, the media element has events to notify you about e.g. when the media has finished playing. All in all it's a quick way to add media to your application or Silverlight game.
However, one huge limitation of the media element is that only one is supported at a time. It is not possible to play multiple media files simultaneously, and even having multiple elements that don't play at the same time on the same page is not supported. To overcome this limitation, you can use the XNA libraries for audio playback. XNA's audio features are one of those parts which are allowed and safe to use from Silverlight. In addition this approach opens the door to a whole set of features and parameters that aren't accessible through the media element and allow to create even more interesting sound effects. If you are interested in doing that, I strongly recommend downloading the simple "Silverlight Sound Sample" from the Windows Phone 7 code samples page on MSDN. It demonstrates how to use the XNA features that we will learn about below in a Silverlight project. All of the following applies to both XNA and Silverlight if you're doing that.
Differentiation and certification requirements
Regarding audio on Windows Phone 7, especially the certification requirements differentiate between music and sound effects. Sound effects are played through the XNA class named alike (see below). Those sounds are mixed with music that is played by the media player automatically and it is allowed to play them at any time, even simultaneously to already running music. For background music on the other hand you are supposed to use a different method (the requirements explicitly state that the sound effects class should not be used for that), and your app needs to be aware of already running music. In particular (section 6.5.1, Initial Launch Functionality):

When the user is already playing music on the phone when the application is launched, the application must not pause, resume, or stop the active music [...]

And:

If the application plays its own background music or adjusts background music volume, it must ask the user for consent to stop playing/adjust the background music (e.g. message dialog or settings menu).

Additionally, the requirements state that if your application plays background music, you must provide a user interface that allows configuration of the settings for that.
To many developers the wording of this section is confusing, and working with these requirements can be quite tricky and cause certification failure easily. So what does all this mean?

Sample startup procedure
When your game starts, you can use the media player's static property "GameHasControl". If it returns true it means that there's no currently playing music and you can start your own background music right away. If it returns false, you are not allowed to manipulate the currently playing music (like stop or pause it) without asking the user first. So what you need to do is present the user a message where they confirm that it is ok to stop the currently running music. Only if that request is confirmed by the user you are allowed to replace it with your own. You can use the message box functionality of the Guide class for the dialogs.

There is a full example with additional details available in the education section of the App Hub, named Music Management for Windows Phone 7. If you think about adding background music to your game, I recommend downloading and working with that sample. The included helper class is a good starting point and can easily be extended to fit your needs.
Background music
Now that we have clarified the dos and don'ts of background music, let's see how to implement it. The central element for this is XNA's Song class. Like with any other media, the standard procedure for music and sound effects in XNA is to import it through your content project. When you add an MP3 file (or any other of the supported audio formats) you can choose "Song – XNA Framework" as content processor to turn it into a song:

Playing the song then is a matter of only a few lines of code:


 1: // load the song

 2: _backgroundMusic = Content.Load("Song");

 3:  

 4: // try to start the music if we are allowed to do that

 5: if (MediaPlayer.GameHasControl)

 6: {

 7:     try

 8:     {

 9:         // start playing the music

 10:         MediaPlayer.Play(_backgroundMusic);

 11:  

 12:         // set some parameters

 13:         MediaPlayer.Volume = 0.9f;

 14:         MediaPlayer.IsRepeating = true;

 15:  

 16:         _message = "You should hear the background music now.";

 17:     }

 18:     catch (InvalidOperationException)

 19:     {

 20:         // you cannot play songs if the device is connected to Zune 

 21:         _message = "Playing the background music failed.";

 22:     }

 23: }

 24: else

 25: {

 26:     _message = "Already playing music detected.";

 27: }


Important requirement
The above sample code already incorporates some changes that will be introduced by the first minor update to Windows Phone 7 ("NoDo") which is coming soon to existing devices and already used by some of the currently sold new phones. The problem: the media player on the phone does not have a separate volume control on a per-song basis or mute functionality. That means that if you used parameters like the above "Volume" property while music from the media library was playing, you were able to make changes that the user could not undo later through the media player controls anymore.
To overcome this problem, changing any of these parameters is ignored when the currently playing music source is located in the media library. Here is an example:


 1: MediaPlayer.Play(new MediaLibrary().Songs);

 2:  

 3: // setting this has no effect;

 4: // Volume is 1.0f after this line!

 5: MediaPlayer.Volume = 0.5f;


So it is important to remember and/or get used to the following recommended pattern of actions:

    First start playing your own music. 
    Then adjust the necessary parameters like volume etc. 

If you follow this recommendation, playing your music will work as expected in both the RTM and updated version of Windows Phone 7. The topic is described in more detail in this recent blog post by Nick Gravelyn.
Sound effects
Sound effects, just like music, are imported into your game through the content project. This time however, select "Sound Effect – XNA Framework" as content processor:

Loading the sound effect also is nothing new to us:


 1: // load sound effect

 2: _soundEffect = Content.Load("ShotEffect");


When you look at the properties and methods the sound effect class offers for a second, you can see that it in fact has a "Play" method that can play the sound in a "fire and forget" fashion. This is somewhat similar to what we have seen for the Song type above. An overload of that method allows you to pass in values for various parameters, like volume, pitch and pan.


 1: // play sound 

 2: var pan = (float)((_rnd.NextDouble() - 0.5) * 2.0);

 3: var pitch = (float)((_rnd.NextDouble() - 0.5) * 2.0);

 4: var volume = (float)((_rnd.NextDouble() / 2.0) + 0.5);

 5:  

 6: _soundEffect.Play(volume, pitch, pan);


It's noteworthy that this method also allows you to play the same sound multiple times simultaneously.
Modifying sounds as they play
A more interesting approach to play sound effects however is to create a sound effect instance. The great thing is that by doing this you have a reference to the sound that currently plays and can change its properties on the fly. For example, let's create a sound that pans from the far left to the far right or vice versa as it goes. First of all we create the sound instance by using the respective method of the sound effect, set some initial values and start playing:


 1: // set the pan speed so a full pan (-1.0 to 1.0 = 2.0)

 2: // is achieved over the duration of the sound

 3: _panSpeed = 2.0f / (float)_soundEffect.Duration.TotalSeconds;

 4:  

 5: // randomly choose panning direction

 6: _panSpeed = _rnd.NextDouble() > 0.5 ? _panSpeed : -_panSpeed;

 7:  

 8: // create the actual effect and play it

 9: _panningSoundEffect = _soundEffect.CreateInstance();

 10: _panningSoundEffect.Pan = _panSpeed > 0.0f ? -1.0f : 1.0f;

 11: _panningSoundEffect.Play();


Then, in the "Update" method of the game, as long as the sound effect instance plays, we update its pan property:


 1: // update panning sound if present

 2: if (_panningSoundEffect != null)

 3: {

 4:     // remove sound if it has finished

 5:     if (_panningSoundEffect.State == SoundState.Stopped)

 6:     {

 7:         _panningSoundEffect.Dispose();

 8:         _panningSoundEffect = null;

 9:     }

 10:     else

 11:     {

 12:         // caluclate new pan value

 13:         var newPan = _panningSoundEffect.Pan +

 14:             (float)(gameTime.ElapsedGameTime.TotalSeconds * _panSpeed);

 15:  

 16:         // make sure the new value doesn't exceed

 17:         // the allowed bounds

 18:         newPan = Math.Max(-1.0f, Math.Min(newPan, 1.0f));

 19:  

 20:         // update pan value

 21:         _panningSoundEffect.Pan = newPan;

 22:     }

 23: }


An important detail to note here is the use of the "Dispose" method. When you're done using a sound effect instance, let it clean up its unmanaged resources that way and remove all references in your code so the garbage collector can do the rest.
3D Sounds
The above example tries to mimic positioning a sound in the coordinate space around the player by manipulating the pan value in real-time. The sound effect instance class actually offers a more sophisticated feature to accomplish this for more complex scenarios: 3D sounds. You can turn any sound effect into a 3D sound by calling the "Apply3D" method at least once before you call Play. To make use of the 3D features, you have to repeat this frequently, for example call the method in the Update method of your game.


 1: // create a new sound effect

 2: _3dSoundEffect = _soundEffect.CreateInstance();

 3:  

 4: // set looping and make it a 3D sound

 5: _3dSoundEffect.IsLooped = true;

 6: _3dSoundEffect.Apply3D(_audioListener, _audioEmitter);

 7: _3dSoundEffect.Play();


As you can see, the method takes an audio listener and an audio emitter as arguments. Both of these are entities that are located in 3D space and share the following properties of interest:

    Position: A Vector3 that describes the current position. 
    Velocity: A Vector3 that describes the current movement (= speed + direction) of the entity. 
    Up: A Vector3 that points upward in the entity's space. 
    Forward: A Vector3 that is the direction the entity is facing at. 

This allows to set up pretty complex scenarios, where entities are tilted and move sideways, with relative speed to each other. The sound mixing reacts accordingly; the sound is ought to come from the emitter and will be distorted to match what the listener would hear in its current position (using things like attenuation and the doppler effect). 
A lot of games conceptionally work in a way that the player (the listener) stays positioned in the origin, with the forward and up vectors axis-aligned to the y- and z-axes, and never actually moves around. Instead, the emitter (and the rest of the world) is moved around the player. I have added a sample for this kind of a 3D positioned sound in the source code for this article. It moves an emitter around the player in an ellipse to demonstrate how the sound mixing applies not only panning, but also adjusts the volume as the emitter is moving away from and back towards the player.


 1: // calculate the new position

 2: var emitterPosition = new Vector3(

 3:     (float)Math.Cos(gameTime.TotalGameTime.TotalSeconds),

 4:     0,

 5:     (float)Math.Sin(gameTime.TotalGameTime.TotalSeconds) * 3);

 6:  

 7: // update the audio emitter position

 8: _audioEmitter.Position = emitterPosition;

 9:  

 10: // update the 3D sound

 11: _3dSoundEffect.Apply3D(_audioListener, _audioEmitter);


The question of course is whether that level of sophistication is needed on a mobile device (and in 2D games). However, it adds interesting new possibilities to the use of audio, something a lot of games tend to ignore a bit. And when the player wears headphones it can actually create quite a nice acoustic environment.
Summary
Adding sounds and music to your game is pretty straight forward, and as long as you follow a few rules certification for the market place should not become a problem. Audio is one of the areas where XNA has clear advantages regarding the feature set, and luckily Silverlight developers can make use of that easily too. Even on the limited mobile platform the sound libraries have pretty sophisticated support for advanced audio scenarios, including the use of 3D sounds. I hope I was able to demonstrate some of those possibilities in this article. Feel free to leave any feedback or comments.
Download source code
About the author
Peter Kuhn aka "Mister Goodcat" has been working in the IT industry for more than ten years. After being a project lead and technical director for several years, developing database and device controlling applications in the field of medical software and bioinformatics as well as for knowledge management solutions, he founded his own business in 2010. Starting in 2001 he jumped onto the .NET wagon very early, and has also used Silverlight for business application development since version 2. Today he uses Silverlight, .NET and ASP.NET as his preferred development platforms and offers training and consulting around these technologies and general software design and development process questions.
He created his first game at the age of 11 on the Commodore 64 of his father and has finished several hobby and also commercial game projects since then. His last commercial project was the development of Painkiller:Resurrection, a game published in late 2009, which he supervised and contributed to as technical director in his free time. You can find his tech blog here: http://www.pitorque.de/MisterGoodcat/


XNA for Silverlight developers: Part 7 - Collision detection
editorial@silverlightshow.net (Peter Kuhn ) — Wed, 16 Mar 2011 02:58:00 GMT
Are you interested in creating games for Windows Phone 7 but don't have XNA experience? 

Watch the recording of the recent intro webinar delivered by Peter Kuhn 'XNA for Windows Phone 7'.



Don't miss...

    What is Windows Phone series 
    XNA article by Levente Mihály 
    WP7 series by Andrea Boschin 
    The XNA series is now available as a fully offline resource 


     All SilverlightShow Ebooks 

This article is part 7 of the series "XNA for Silverlight developers".
This article is compatible with Windows Phone "Mango". 

Latest update: Aug 1, 2011.
Detection of and reaction to collisions is a very fundamental element in games. As soon as it has moving components of some sort, it is likely that collisions are of concern. For example, the player character may collide with the scenery of the game. The player may also collide with other characters (enemies, monsters etc.), and of course many games work with projectiles that can hit various other parts on the game screen. But what exactly are collisions in a game, and what are good ways to detect and handle them? This article tries to give answers.
What collisions are
The definition of collisions in our sense is pretty simple: a collision is the state of two or more objects that intersect. But at second glance, we will see that it can become pretty difficult to translate this seemingly simple definition to the context of a game. 
We have learned that in XNA, all sprites are actually textures, or parts of textures, which are drawn on the screen. In both cases, the shape of a sprite is a rectangle. This is the only option available; we can either draw a whole texture on the screen (which is rectangular per se), or define a portion of a texture that should be drawn using the "source rectangle" mechanism. So apparently, working with collisions comes down to detecting the intersection of rectangles:

Of course it's not as simple as that. We already have used ways to work around the rectangle restriction in former parts of this series and know that we are very well able to create irregularly shaped sprites in XNA, using the instrument of transparency. For example, if we wanted to create a round object, like a ball, we'd simply make those parts that don't belong to the ball transparent:

And this inevitably leads to potential problems:

So a better definition of collisions for 2D games would be: a collision is the state of two or more objects that intersect in their non-transparent parts. In the following paragraphs, we will look at different approaches to optimize the detection of collisions in both accuracy and performance.

Pixel-perfect collision detection
If we take the above mentioned extended definition and translate it into an algorithm, then it would read like this:

    Check whether the rectangle bounds of two sprites intersect. 
    If they do, check whether any pair of pixels within the intersection are non-transparent on both sprite textures. 
    If we found at least one pair of non-transparent pixels, we have detected a "real" collision. 


How does XNA help us with this approach?
Retrieving and accessing the texture data
In XNA you can get access to the raw texture data by using the "GetData" generic method of the Texture2D class. If you think about it, a texture really is only a huge array of color values – each pixel in that texture is made of the red, green, blue and alpha values in that place. That is why you can retrieve the raw texture values as color array:


 1: var texture = content.Load(textureName);

 2: Color[] textureData = new Color[texture.Width * texture.Height];

 3: texture.GetData(textureData);


After loading the texture, you have to create an array that is big enough to hold all color values of the texture and then pass it into the "GetData" method. You will notice that the result actually is a one-dimensional array of color values, whereas the texture itself is a two-dimensional structure. This is by design because it is faster and offers more flexibility than a multi-dimensional structure. If you want to access the texture data in a more "natural" way using x and y coordinates, you have to calculate the offset in the one-dimensional array as x + y * textureWidth.

In the above example, the texture width is 5 pixels, and if you wanted to access the pixel at position (3, 2) in the one-dimensional array you retrieve by calling "GetData", you would calculate the index as 3 + 2 * 5 = 13.
Note: When you are using a sprite sheet (e.g. multiple sprites or sprite animation frames on a single texture), you have to take the current source rectangle your sprite uses into account too. The calculation then would look like:


 1: public Color GetColorAt(int x, int y)

 2: {

 3:     // we need to take the source rectangle into account

 4:     var transformedX = x + SourceRectangle.X;

 5:     var transformedY = y + SourceRectangle.Y;

 6:  

 7:     // calculate the offset and return the color from

 8:     // the one-dimensional texture data returned by the "GetData" method

 9:     return TextureData[transformedX + transformedY * Texture.Width];

 10: }


This demonstrates the extra step involved to get the correct offset in the sprite texture, depending on the source rectangle.
Calculating the intersection
Using the location and dimensions of two sprites, we can calculate the intersecting rectangle fairly easily. To this end, we first calculate the bounds of the sprite in screen coordinates, which I once again have made a method of my custom sprite class:


 1: public Rectangle GetScreenRectangle()

 2: {

 3:     // calculate the rectangle from the current location

 4:     // and the current source rectangle

 5:     var rectangle = new Rectangle(

 6:         (int)Location.X,

 7:         (int)Location.Y,

 8:         SourceRectangle.Width,

 9:         SourceRectangle.Height);

 10:  

 11:     return rectangle;

 12: }


If your sprite only uses a whole texture, you can use that texture's width and height for this. I used the source rectangle my custom sprite class defines, which can potentially be different from the texture dimensions, e.g. when a sprite sheet is used.
Given two of those screen space rectangles, the intersection can be calculated as:


 1: public static Rectangle Intersect(this Rectangle rectangleA, Rectangle rectangleB)

 2: {

 3:     // get the top, bottom, left and right coordinates

 4:     // of the intersection

 5:     int top = Math.Max(rectangleA.Top, rectangleB.Top);

 6:     int bottom = Math.Min(rectangleA.Bottom, rectangleB.Bottom);

 7:     int left = Math.Max(rectangleA.Left, rectangleB.Left);

 8:     int right = Math.Min(rectangleA.Right, rectangleB.Right);

 9:  

 10:     // do the rectangles intersect at all?

 11:     if (top > bottom || left > right)

 12:     {

 13:         return Rectangle.Empty;

 14:     }

 15:     else

 16:     {

 17:         return new Rectangle(left, top, right - left, bottom - top);

 18:     }

 19: }


Again this is pretty straight-forward, but some people have problems picturing it. It really helps to use a piece of paper and draw a few possible cases to realize that this actually creates the intersection rectangle (unless there is no intersection, which results in the static "Empty" rectangle as a result).
Comparing pixels
It's now time to put those pieces together to compare the pixel colors of the intersection rectangle of two sprites. To this end, we first get the intersection rectangle and then inspect every pixel in it. To retrieve the color values of a certain pixel for a sprite, we need to transform these coordinates back to the respective sprite's space. We can then use the "GetColorAt" method we've created above to retrieve both color values and compare their alpha values:


 1: public static bool IsPerPixelCollidingWith(this Sprite spriteA, Sprite spriteB)

 2: {

 3:     // get the bounds in screen coordinates

 4:     var rectangleA = spriteA.GetScreenRectangle();

 5:     var rectangleB = spriteB.GetScreenRectangle();

 6:  

 7:     // find the bounds of the rectangle intersection in screen space

 8:     var intersection = rectangleA.Intersect(rectangleB);

 9:     if (intersection == Rectangle.Empty)

 10:     {

 11:         return false;

 12:     }

 13:  

 14:     // Check every point within the intersection bounds

 15:     for (int y = intersection.Top; y < intersection.Bottom; y++)

 16:     {

 17:         for (int x = intersection.Left; x < intersection.Right; x++)

 18:         {

 19:             // to retrieve the color of a pixel

 20:             // we need to transform the coordinates back

 21:             // to the sprite's local space

 22:             int xA = x - rectangleA.Left;

 23:             int yA = y - rectangleA.Top;

 24:             Color colorA = spriteA.GetColorAt(xA, yA);

 25:  

 26:             int xB = x - rectangleB.Left;

 27:             int yB = y - rectangleB.Top;

 28:             Color colorB = spriteB.GetColorAt(xB, yB);

 29:  

 30:             // If both pixels are not completely transparent,

 31:             if (colorA.A != 0 && colorB.A != 0)

 32:             {

 33:                 // then an intersection has been found

 34:                 return true;

 35:             }

 36:         }

 37:     }

 38:  

 39:     return false;

 40: }


The transitions between different coordinate systems may seem confusing at first, but you should be able to get accustomed to it quickly once you understand the chain of involved actions required to retrieve the actual color value:

A sample application
The first sample you can find in the download package creates some balls with random initial positions and velocities that move around the screen. In each frame, collisions are detected using the above described approach, and if one is found, the involved sprites are tinted red. Running in the emulator, it looks like this:

When you observe the balls, you can see that indeed no collisions are detected if their transparent corners overlap.
Performance considerations
A collision detection algorithm like this is not only very accurate, it is also pretty expensive. Especially when you have sprites with large amounts of transparency you can easily end up with thousands of individual pixels to compare in each frame. Also, the number of collision checks that need to be performed obviously raises with the number of objects. The above screenshot includes that number, and as you can see, 15 objects on the screen already require 105 checks. The first ball is compared to all the 14 others, the second one to the remaining 13, the third one to 12 and so on. More accurately:

I was wondering when this would become a problem and did some tests on my phone. Interestingly I was able to raise the number of balls to 100 without any problems. 4950 of these collision checks are performed in this case in each frame update. Performance declined quickly after that. 150 balls (11175 collision checks) are pretty horrible, and depending on the random distribution of the sprites reached frame rates as low as 2 per second. Again the question is whether you will really ever need and have more than 100 objects on the screen that need collision detection. But still let's talk about possible improvements and alternatives.
Please note that a rule of thumb for the following actions is that you shouldn't put too much effort into preliminary performance optimization until you actual start seeing problems, or unless it's low hanging fruits you know will pay off. 

Working with bounding geometries
Instead of working with pixel perfect collision detection, an often used alternative is to use some sort of bounding geometry, like a rectangle or a circle. In more sophisticated scenarios, even multiple geometries can be used. For example, a concept borrowed from 3D games is to use three circles for a human-like character (head, torso, legs). In almost all cases this means losing precision regarding the detection of collisions, but it can result in quite a performance gain.
In our sample, the obvious improvement is to use a circle as bounding geometry, which in this special case results in the same perfect collision detection, because we do use, well, circles as sprites. A modified collision detection in this case can use a custom circle structure, like:


 1: public class Circle

 2: {

 3:     public Vector2 Center;

 4:     public float Radius;

 5:  

 6:     public bool Intersects(Circle other)

 7:     {

 8:         // calculate the minimum distance of the centers

 9:         // the circles are not intersecting at

 10:         var minCenterDistance = Radius + other.Radius;

 11:  

 12:         // calculate the actual distance and compare

 13:         var distanceVector = Center - other.Center;

 14:         if (distanceVector.Length() < minCenterDistance)

 15:         {

 16:             return true;

 17:         }

 18:         else

 19:         {

 20:             return false;

 21:         }

 22:     }

 23: }


A sprite can then create its bounding circle depending on its current position and size:


 1: public Circle GetBoundingCircle()

 2: {

 3:     // create a new bounding circle

 4:     Circle result = new Circle();

 5:  

 6:     // the center is the location + half the size

 7:     result.Center = new Vector2(Location.X + SourceRectangle.Width / 2.0f,

 8:         Location.Y + SourceRectangle.Height / 2.0f);

 9:  

 10:     // use half the width as radius

 11:     result.Radius = SourceRectangle.Width / 2.0f;

 12:  

 13:     return result;

 14: }


With this approach and the same sample as above, the demo was able to provide a decent frame rate for almost twice as much balls: 190, which require 17955 collision checks in each frame. This illustrates how much more expensive the pixel-perfect check actually is.
Unfortunately, no general recommendation can be made with regards to bounding geometries. In some cases you can achieve very good results using them (like in this case), but in other situations you may really see that a bounding box or similar cannot stand up to your requirements and deliver the desired accuracy. Often using bounding geometries requires fine-tuning, and customizing the detection algorithms for your particular game to a point where you even differentiate between collisions of certain game object types (e.g. treating player-monster collisions differently from player-projectile etc.).

Tiling your game
If you look at the above numbers, you can see that 10 times the balls (150 instead of 15) resulted in more than 100 times more collision checks (11175 compared to 105). Reducing the number of checks by additional tricks is therefore highly desired. An often used technique you may be able to take advantage of for this is to tile your game. What this means in this context is to divide the screen into multiple areas that are treated independently from each other. At the moment, we are checking each sprite on the screen against all the others, even if they are located on opposite ends and obviously cannot collide. So the idea is to separate your sprites into groups depending on their rough location. This makes perfect sense for example for platformers, where monsters often cannot leave certain areas and it wouldn't make sense to check these against the player when they are not even near that area. Each of those groups can be inspected separately which can save a lot of the required checks.
Of course this can also be contradictory, for example if your sprites can move between multiple tiles/areas and you need to determine what area they are currently in very often. Once again no general recommendation can be made and the decision should be based on your scenario.

Potential problems
Scale and rotate
If you are using a pixel-perfect collision detection algorithm like the one above, you will inevitably run into some problems if you use scaling and rotation with the involved sprites. In our sample, when we are only using translations, there is a one-to-one relationship between the pixels on the screen and the pixels on the involved textures (texels), and we have a very simple geometry to check (an intersection rectangle). This makes these checks relatively easy.
Now when you zoom and/or rotate your sprites, you will find that a texel suddenly can span multiple pixels on the screen (or the other way round: one pixel's final color is determined by multiple texels), and that the involved geometries are not axis-aligned anymore. How to overcome this problem?
Once again the solution is to use coordinate transforms. In particular, what you'd typically do is create a transformation matrix that transforms coordinates from the one sprite's local space to the other sprite's local space. This allows you to iterate over the pixels in one sprite like we did above and get the corresponding pixel color value in the other sprite, whilst taking into account the involved rotate and scale transforms. The education section of Microsoft's App Hub site actually has an example for this that shows how to handle rotations (link), but unfortunately it only includes source code for the desktop and Xbox version of XNA. For your convenience, I have converted the sample to Windows Phone 7, cleaned it up a bit and added the code for scaling. Since a full discussion of the required steps is beyond this article, I strongly recommend downloading the source code package below if you are interested in it. I hope the extensive comments in the code help understand the concepts. Here is what the sample looks like in the phone emulator:

You can use the arrow keys to move around the small player character at the bottom; to enable keyboard input in the emulator, you have to press the "Pause" key on your keyboard first. The sample demonstrates how pixel-perfect collision detection still works even for the rotated and scaled elements on the screen.
The a posteriori bug
The approach we are using here (and that is used in most games) is named "a posteriori", which means we are first updating the scene and move all objects, and then check for collisions afterwards. If a collision is detected, the game logic reacts accordingly. Whether that is a simple color tint change like in our example or an attempt to simulate physical laws (bouncing off etc.) depends on the game. In a lot of cases this works surprisingly well, but in some situations you may come across the "a posteriori bug". The problem with this technique in general is that it always only looks at a current snapshot of the game situation instead of considering a continuous analysis. This is easy to implement and provides good performance, however it can actually lead to collisions that are missed, for example when objects are moving very fast, if very thin or small objects are involved, or both. Let's look at an example:

In the above picture, we see two successive frames. The green ball is moving very fast to the right and is supposed to bounce off the orange wall. However, due to the high velocity the update process has moved the ball so far to the right that it traveled past the wall within one frame. In neither of the two frames the collision detection is able to do its job, because there never is an actual intersection. In real world scenarios, this often happens with projectiles because usually they're pretty small and move around much faster than other objects.
If you identify such situations and are not able to find a simpler workaround, you indeed have to do a temporal analysis for these cases. In the above example, you would always look at two successive frames, for example by comparing the current position to the previous one, and use that information to check if collisions happened "in between" the frames. From a mathematical point of view, this involves intersecting a line (through the previous and current position) with another line or geometry (the wall) and checking whether the intersection point (if existent) lies between the previous and current position of the object.
What about Silverlight?
In all the articles so far I've started with an evaluation of how people would implement the respective features in Silverlight, and then make the transition to XNA. The reason there is no such analysis in this article simply is that Silverlight has no built-in features and support for collision detection in games. When you are creating a game in Silverlight you will find that you have to think about the same concepts we were exploring in XNA here, and then manually implement the required code.
Of course others have done this already; you can find a nice sample implementation by Christophe Geers here (which in turn is based on an implementation of Andy Beaulieu). When you look at the code you can see that it's quite similar to what we did: first bounding rectangles are checked for performance optimization, and then every pixel in the intersection rectangle is inspected separately using the FindElementsInHostCoordinates method of the visual tree helper. And just like in XNA, this is a very expensive operation that should not be used excessively.

Summary and further readings
Collision detection is a complex topic, and even though we have learned a pretty good method to detect collisions accurately in this article, it only scratches the surface of it. For example, a completely different issue is how to actually react to collisions once they are detected. In simple cases you are just interested in the hit itself ("shoot at monster"). But sooner or later you may also want to create more sophisticated features that involve simple or complex physics ("bouncing ball") which adds a whole new set of problems to solve, and a whole new world of interesting things to do (think physics engines etc.).
A good place to find additional material on the topic is the App Hub education section about collision detection. It has some articles specific to Windows Phone 7 and even some full games you can dissect and learn from. Another example from that site which is not explicitly mentioned in the collision section is the Platformer code sample. That game uses bounding boxes for collision detection and achieves some pretty good results with it. It also shows how to handle simple physics like gravity and common situations with collision detection like characters standing on the floor.
The source code package this time contains three solutions: the pixel-perfect approach we learned about in the first part of the article, a different solution using bounding circles, and the reworked Microsoft sample that shows how to handle collisions of transformed objects on the phone.
Download source code
About the author
Peter Kuhn aka "Mister Goodcat" has been working in the IT industry for more than ten years. After being a project lead and technical director for several years, developing database and device controlling applications in the field of medical software and bioinformatics as well as for knowledge management solutions, he founded his own business in 2010. Starting in 2001 he jumped onto the .NET wagon very early, and has also used Silverlight for business application development since version 2. Today he uses Silverlight, .NET and ASP.NET as his preferred development platforms and offers training and consulting around these technologies and general software design and development process questions.
He created his first game at the age of 11 on the Commodore 64 of his father and has finished several hobby and also commercial game projects since then. His last commercial project was the development of Painkiller:Resurrection, a game published in late 2009, which he supervised and contributed to as technical director in his free time. You can find his tech blog here: http://www.pitorque.de/MisterGoodcat/


Simulating rain in Silverlight
editorial@silverlightshow.net (Lazar Nikolov ) — Mon, 14 Mar 2011 10:58:00 GMT
This article is compatible with the latest version of Silverlight.


Don't miss...

    Free SilverlightShow Webinars 
    Getting ready for Silverlight Exam 70-506 series 
    ClassifiedCabinet: A Quick Start 
    Pro Business Apps with SL4 book: 

          
           Show more books


Introduction

In this article I will try to simulate rain in Silverlight application that can be programmatically configured to meet your expectations. Although Silverlight at the time being is very CPU consuming, rain effect may be a common challenge for a developer or designer.
I believe that there are many computer graphics techniques, such as Particle system, to simulate realistically processes that involve tiny particles interacting with each other. However, in this article I will show you how to simulate rain with almost no effort with some very simple algorithm.
Here is a little demo and source code of what we will have done at the end in just a few minutes:
View live demo - with a small amount of raindrops to avoid performance issues
Download source code
Also check the second part of this series - "Simulating rain in Silverlight Part 2 - Optimization"!


The idea

Before looking at the algorithm, let me make the main flow clear. As I wrote a few lines above, the designer adjusts programmatically the rain on his own. That is – the height and width of the scene, the interval of falling drops and the amount of drops animated at a time. This all is achieved with a couple of classes that form the rain nature:

    Drop – holds the drop view 
    DropSettings – describes a drop and its settings; currently only the height that the drop pours is implemented; this act as a view-model as I use it to bind in the drop view when animating the motion from top to bottom part of the scene 
    Rain – this is my main object to maintain the rain process; it uses a simple algorithm, I will next describe, to simulate drops falling randomly through scene 



The algorithm

Now it’s time for the algorithm. It, actually, is really very simple one. What determines the average rain? Yes, you are right and this is what I was looking for – direction and intensity.
First, to simulate the rain, we need to perform the algorithm exactly as many times, as we had previously defined to be the amount of drops to fall simultaneously. Furthermore, this should be done exactly as many times as we have specified to be the interval between the raindrops. 
We start with the following:

for (int i = 0; i < this.DropsPerInterval; ++i)
{
}

To distinguish between UI elements in the scene, when constructing the Rain object, a canvas is specified, and this panel is where the rain will be simulated in. Every drop that we create should be a child of this panel.

Drop drop = new Drop(this.DropSettings);
this.Scene.Children.Add(drop);

Next step is to generate the depth in which the drop is shown in the scene. Depth visually controls the scale and further you go deep in the scene, drops become smaller.

double depth = rand.NextDouble();
drop.RenderTransform = new ScaleTransform
{
    ScaleX = depth,
    ScaleY = depth,
};

The direction of the rain affects directly on the angle which drops fall the ground in. In the demo this angle is fixed to be between 0 and 10 degrees clockwise rotation.

double angle = rand.NextDouble() * 10;
drop.LayoutRoot.RenderTransform = new RotateTransform
{
    Angle = angle,
};

So far we had spread the drops randomly in depths and directions between 0 and 10 degrees. To put the finishing touches, we need to randomly scatter the raindrops in the two dimensional perspective of the scene.

drop.Margin = new Thickness(Convert.ToInt32(rand.NextDouble() * this.Width), 0, 0, 0);

This will set gratuitously from 0 to the right most corner the gap between the drop and most left corner.
Finally, the last thing to do is to start the animation.

drop.Animate();


That's it!
Designing the drop
To design the raindrop view I use Expression Blend. Here is the XAML for it (for clarity I have omitted the Data attribute):

<Path Stretch="Fill" Data="..." VerticalAlignment="Stretch" RenderTransformOrigin="0.5,0.5"
    Margin="1.222,-2.518,-4.94,-7.559" UseLayoutRounding="False" >
    <Path.Fill>
        <LinearGradientBrush EndPoint="1.420529961586,0.976535022258759"
            StartPoint="0.331510990858078,0.976535022258759">
            <LinearGradientBrush.RelativeTransform>
                <TransformGroup>
                    <SkewTransform AngleY="0" AngleX="17.4704" CenterY="0.976535" CenterX="0.331511"/>
                    <RotateTransform Angle="-61.3206" CenterY="0.976535" CenterX="0.331511"/>
                TransformGroup>

            LinearGradientBrush.RelativeTransform>

            <GradientStop Color="#FE739EAD"/>
            <GradientStop Color="#FFD3E9F9" Offset="1"/>
        LinearGradientBrush>

    Path.Fill>

Path>


It is nothing more than a path with some gradient brush on it. This results in the following, magnified about 20 times:

To simulate the drop falling I use a storyboard that:

    animates the height the drop is in each moment 
    animate the visibility to collapsed when the desired height is reached, that is the drop has fallen through the whole scene 


<Storyboard x:Name="Pour">
    <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" Storyboard.TargetName="drop"
Storyboard.TargetProperty="(UIElement.RenderTransform).(TransformGroup.Children)[3].(TranslateTransform.Y)">
        <SplineDoubleKeyFrame KeyTime="00:00:00" Value="0"/>
        <SplineDoubleKeyFrame KeyTime="00:00:00.6" Value="{Binding FallHeight}"/>
    DoubleAnimationUsingKeyFrames>

    <ObjectAnimationUsingKeyFrames BeginTime="00:00:00" Storyboard.TargetName="drop"
Storyboard.TargetProperty="(UIElement.Visibility)">
        <DiscreteObjectKeyFrame KeyTime="00:00:00.6" Value="Collapsed" />
    ObjectAnimationUsingKeyFrames>

Storyboard>


To obtain the scene height I use binding to the DropSettings object that is injected in the constructor when the raindrop is created.


Let’s start raining!

This was all you need to simulate rain. To actually start it you have to call the classes we created in a manner that satisfies our expectations.

DropSettings dropSettings = new DropSettings(300);
Rain rain = new Rain(dropSettings, this.Scene, 40, 3, 400);
rain.Start();



Conclusion

Although Silverlight is still very CPU consuming, in this article I’ve shown you how to use a simple algorithm to simulate rain. For all that we still should not expect miracles when it comes to real time particle simulations. But I hope soon we shall have what we wish to make our application look and behave really realistic.
About the author
Lazar Nikolov is a software developer at CompletIT - the company behind SilverlightShow.net and leader in Silverlight related technologies in Bulgaria. His main interests are focused on Silverlight rich applications and Windows Phone 7 development.
In addition to authoring Silverlight articles (his series on ‘Simulating rain in Silverlight’ became one of the most popular articles on SilverlightShow!), Lazar is involved in the verification of all SilverlightShow articles, making sure that all content is consistent and in-line with the latest Silverlight/WP7 release updates.


XNA for Silverlight developers: Part 6 - Input (accelerometer)
editorial@silverlightshow.net (Peter Kuhn ) — Wed, 09 Mar 2011 07:31:00 GMT
Are you interested in creating games for Windows Phone 7 but don't have XNA experience? 

Watch the recording of the recent intro webinar delivered by Peter Kuhn 'XNA for Windows Phone 7'.



Don't miss...

    What is Windows Phone series 
    XNA article by Levente Mihály 
    WP7 series by Andrea Boschin 
    The XNA series is now available as a fully offline resource 


     All SilverlightShow Ebooks 

This article is part 6 of the series "XNA for Silverlight developers".
This article is compatible with Windows Phone "Mango". 

Latest update: Aug 1, 2011.
Last time we learned about touch input and gestures, which probably is the first choice for user input in most games on the phone. However, the hardware of Windows Phone 7 devices offer more possibilities in the form of additional sensors that can be used for input, in particular the accelerometer. Starting with "Mango", this will even be extended to sensors like the compass and gyroscope (if supported by the phone's hardware).
For example, Microsoft's game "Kombo" that was available on the phone very early proved that using the accelerometer as primary input for a game is very well possible (give it a try, it's free). In this part of the series we will learn how you can use this type of data for input and take a peek at advanced topics and further resources. As always, you can download the source code at the end of the article.
Preface
With the accelerometer, for the first time in this series we are in the situation that we're working with something XNA does not have built-in support for. This is the reason there won't be a separate inspection of how you would do the same in Silverlight in this article, because it really is identical. For the XNA developer the result is that for once they got to work with events in conjunction with input data and can enjoy the comfort of being notified instead of having to poll. 
Theory...
When you read values from the accelerometer, you will receive X, Y and Z values that correspond to the the following axes:

That means: if you tilt the phone so the top edge comes up (like in the drawing), you will receive negative Y values. If you tilt it so the edge that holds the buttons comes up, the Y will become positive. Tilt it to the right, so the left side comes up, and you will receive positive X values, and finally if you tilt it to the left so the right side comes up, the X values will become negative. The Z axis provides negative values when the phone's front is facing up, and the values will be positive if you flip the phone so the front is facing down. 
All those values are provided as G-forces, which means that a value of 1.0 equals 9.81 m/s². This is the conventional standard value for gravitational acceleration on Earth (you can read more about it on Wikipedia if you're are not familiar with this). Ideally, if your phone lies flat on a leveled surface, you would receive values of zero for both X and Y, and -1.0 for the Z value. If the phone stands on its left edge, you would receive X = -1.0 and Y and Z both as zero. And finally if it stands on the edge where the buttons sit, the values should be Y = -1.0 and zero for both X and Z.
... and practice
In practice, you will see that the accelerometer is a very sensitive source of input. Even the slightest change produces instant reaction, and due to the nature of the sensor hardware and physics, even if the phone is not moved at all it is likely that you will see a constant noise level of changing values.
In addition, the reported values also depend on your location, in particular your current location's latitude (because the Earth is not a sphere but an ellipsoid) and the height above sea level. You'll most likely never see the ideal steady value of (-)1.0. For example, when I lie my phone down on what seems a perfectly leveled table, I see a Z value that constantly jumps between -0.97 and -0.99. Both the X and Y values jump equally in the range of 0.02-0.03. This is something you must accommodate for in your applications and games, for example by using a threshold or smoothing of the values (see below).
Setup
To use the accelerometer, an additional assembly reference is needed for your project, because it is not included by default when you create a new game solution. In particular, Microsoft.Devices.Sensors is required:

The next step is to create an instance of the Accelerometer class that can be found in the same namespace. This class has a single event ReadingChanged that is raised when new data is available. This event is raised 50 times a second, so it produces a lot of data. Because of this there's also a mechanism to turn reporting of the input data on and off, so you have the possibility to only activate it when you really need it. For example, if your game is paused or currently displaying a menu screen or similar, you should pause the accelerometer input. This can be done using the Start and Stop methods of the class.
The whole setup then looks like this:


 1: // fields for the accelerometer

 2: private Accelerometer _accelerometer;

 3: private Vector3 _lastAccelerometerData;

 4:  

 5: ...

 6:  

 7: // create the accelerometer instance,

 8: // e.g. in your game's constructor;

 9: // hook the ReadingChanged event

 10: _accelerometer = new Accelerometer();

 11: _accelerometer.ReadingChanged += 

 12:     new EventHandler(Accelerometer_ReadingChanged);

 13:  

 14: ...

 15:  

 16: private void Accelerometer_ReadingChanged(object sender, AccelerometerReadingEventArgs e)

 17: {

 18:     // simply store the reading as new vector

 19:     _lastAccelerometerData = new Vector3((float)e.X, (float)e.Y, (float)e.Z);

 20: }

 21:  

 22: ...

 23:  

 24: // for example in your game's Initialize method,

 25: // start the accelerometer data collection

 26: try

 27: {

 28:     _accelerometer.Start();

 29: }

 30: catch (Exception)

 31: {

 32:     // this can fail if the sensor is not available etc.

 33: }


Aside from the X, Y and Z values, the AccelerometerReadingEventArgs also have a property "Timestamp" that is a DateTimeOffset and indicates the time at which the reading was taken. This can be of interest if you are analyzing the change of these values over time instead of taking a momentarily snapshot.
Some important notes about "Mango"
The above mentioned ReadingChanged event is marked as obsolete in the Windows Phone "Mango" release. A new event named CurrentValueChanged has been added to replace the old one. The reason for this change is that the class hierarchy for sensor classes has been changed by the update. In the RTM release of Windows Phone, the accelerometer was a stand-alone class with no base class. In Mango, we now have a generic SensorBase class that is the base class for all other sensor classes of the phone (also the compass, gyroscope etc.). The new hierarchy looks like this:  

    public abstract class SensorBase : IDisposable where TSensorReading : ISensorReading
    
        public sealed class Accelerometer : SensorBase
        public sealed class Compass : SensorBase
        public sealed class Gyroscope : SensorBase
        public sealed class Motion : SensorBase
    

The SensorBase class now is the place that provides general methods, properties and an event for the data retrieval, in particular:


   1: virtual void Start();

   2: virtual void Stop();

   3: TSensorReading CurrentValue { get; }

   4: bool IsDataValid { get; }

   5: TimeSpan TimeBetweenUpdates { set; get; }

   6: event EventHandler> CurrentValueChanged


In this process of refactoring, the existing accelerometer API has been streamlined to fit these changes. Make sure you start using the new event when you target the Mango release with your game or application. Consequently, the received arguments for this event also are slightly different too. But they still provide the same data as in the RTM release; after all, the nature of the sensor hasn't changed.
Another thing that is worth noting is the above listed TimeBetweenUpdates property of the SensorBase class. In Mango you have the possibility to influence the interval at which values are reported by changing that property. A limitation of this is that there might be differences in the capabilities of different sensors and devices. Your desired interval may not be possible to achieve, and the actual value used may be different from what you set this property to. You can query the property after you set an interval to see if changing the value actually worked.
Making use of the data
In this short example, I want to move a ball around the phone screen by using the accelerometer input. To achieve that, I add the X and Y values from the sensor to the current velocity of the ball. To work around the problem of the basic noise level that is always present even when the phone lies still, I'm using a threshold the values need to exceed to actually be considered for processing. For all this, I declare the following fields:


 1: // the ball and its location + velocity

 2: private Texture2D _ball;

 3: private Vector2 _location;        

 4: private Vector2 _velocity;

 5:  

 6: // some limits to keep the ball on screen

 7: // and to not let it become too fast

 8: private Vector2 _ballMaxLocation;

 9: private Vector2 _ballMaxVelocity;

 10:  

 11: // the threshold for the accelerometer readings

 12: // all values lower than that are ignored

 13: private const float Threshold = 0.1f;


The limit for the location of course are the screen bounds, and for the maximum velocity I simply chose an arbitrary value. Now let's take a look at the "Update" method of the game that simply takes the last sample from the accelerometer to modify the velocity:


 1: // update the ball's velocity with the accelerometer values

 2: if (Math.Abs(_lastAccelerometerData.Y) > Threshold)

 3: {

 4:     _velocity.X -= _lastAccelerometerData.Y;

 5: }

 6:  

 7: if (Math.Abs(_lastAccelerometerData.X) > Threshold)

 8: {

 9:     _velocity.Y -= _lastAccelerometerData.X;

 10: }

 11:  

 12: // limit the velocity to the maximum

 13: _velocity = Vector2.Clamp(_velocity, -_ballMaxVelocity, _ballMaxVelocity);

 14:  

 15: // add some "friction" to the ball's movement

 16: _velocity = _velocity * 0.95f;


There's something really important to note about the first lines of code here. If you inspect them carefully, you can see that I'm subtracting the Y value of the accelerometer data from the X value of the velocity, and similarly use the X value for the Y component.
The reason for this is that in the sample I'm using landscape orientation (LandscapeLeft to be more precise). As my initial graphic shows, the accelerometer coordinate system uses a certain alignment of the axes relative to the device. Unlike the coordinate system of your game, which actually is aligned with respect to the current screen orientation, not the hardware of the phone, the accelerometer's coordinate system is fixed and always stays the same. This means that as long as you are using portrait mode your game's coordinate system axes and the accelerometer's axes are aligned in the the same way, but when you switch to landscape mode, you actually have to swap X and Y coordinates. Even more, you also have to perform a reversal of the sign on the retrieved values, depending on whether you are in left or right landscape mode.
A potentially cleaner solution probably would be to make this distinction in the reading changed event handler already. You could encapsulate the reading in a helper class or similar and swap the values dynamically depending on the current orientation there. That way you'd have a single point where this logic is implemented and could work with consistent values throughout the rest of your application to avoid confusion.
The last line of the above update code adds an artificial slowdown of the ball over time to simulate friction as it moves over the virtual surface. It's just an attempt to add a bit of realism to the behavior, because without that the ball would feel like moving on ice or a mirror.
Let's take a look at the rest of the Update method:


 1: // clamp the location

 2: var clampedLocation = Vector2.Clamp(_location, Vector2.Zero, _ballMaxLocation);

 3: if (clampedLocation != _location)

 4: {

 5:     // reset the velocity if the ball has hit a wall

 6:     if (clampedLocation.X != _location.X)

 7:     {

 8:         _velocity.X = 0.0f;

 9:     }

 10:  

 11:     if (clampedLocation.Y != _location.Y)

 12:     {

 13:         _velocity.Y = 0.0f;

 14:     }

 15:  

 16:     // set the corrected location

 17:     _location = clampedLocation;

 18: }


All we do here is make sure the ball doesn't move off-screen and reset the velocity if any of the edges is hit.
The "Draw method" draws the ball at the current location and also outputs the last accelerometer readings as well as the ball's velocity to visualize how everything works together.


 1: _spriteBatch.Begin();

 2:  

 3: // draw ball

 4: _spriteBatch.Draw(_ball, _location, Color.White);

 5:  

 6: // draw readings

 7: string readings = string.Format("Accelerometer readings: X:{0}, Y:{1}, Z:{2}",

 8:     _lastAccelerometerData.X.ToString("0.00"),

 9:     _lastAccelerometerData.Y.ToString("0.00"),

 10:     _lastAccelerometerData.Z.ToString("0.00"));

 11: _spriteBatch.DrawString(_font, readings, Vector2.Zero, Color.White);

 12:  

 13: // draw velocity

 14: Vector2 readingsSize = _font.MeasureString(readings);

 15: string velocity = string.Format("Ball velocity: X:{0}, Y:{1}",

 16:     _velocity.X.ToString("0.00"),

 17:     _velocity.Y.ToString("0.00"));

 18: _spriteBatch.DrawString(_font, velocity, new Vector2(0.0f, readingsSize.Y), Color.White);

 19:  

 20: _spriteBatch.End();


And here is what the final result looks like on the device:

Possible problems and pitfalls
The emulator
When you are working with the RTM release of Windows Phone, the sensor is not present in the emulator. In that case you are either forced to use a real device whenever you want to test an application or game, or revert to a custom solution to simulate the sensor, for example by mapping some keys to accelerometer input. Over time people also came up with a lot of clever external tools for this problem, including hardware solutions that make use of other accelerometer devices and route the data to the phone. There are some software projects available that use more comfortable client applications to simulate the accelerometer input and let the phone retrieve that simulated input through a web service or similar. One of these projects is the WP7 Accelerometer Emulator project, and a similar one can be found on Codeplex as the Simulator Kit. These solutions can speed up and simplify your development process if you don't have access to a real device all the time or don't want to plug it in for each test.
If you are developing for Windows Phone "Mango", things get a lot more easier and you don't have to use third-party solutions anymore. The improved emulator of the new development tools now has built-in support for the accelerometer and allows you to easily simulate and generate that kind of input data in a nice way:

As you can see a visual representation of the phone is used, and by moving around the red dot you can change the orientation of the device in space, which produces accelerometer data accordingly, without the need to change anything in your code. That is a comfortable and easy way to test your code in the emulator too:

Data noise
As I've mentioned multiple times, the data received from the sensor is really noisy. Here is a sample reading of me tilting the phone to the left, first slowly, then in a sudden movement and back:

In our example we could accommodate for that by using a simple threshold that filtered all the "ambient noise". Once the threshold was exceeded, the noise didn't hurt anymore. However, in other scenarios you might want to react to changes of the sensor values over time rather than process the momentarily values as we did here. This often requires to determine a trend in these values that ignores temporary spikes, for example. In these cases you will most likely want to perform some smoothing on the data, which in turn can introduce a new set of problems, like latency. Luckily you don't have to fight through those basics of signal processing from scratch all by yourself again. Dave Edson and Greg Hogdal from the Windows Phone 7 Applications Platform team have written an excellent article on the topic and introduce some helper classes that do the heavy lifting for you.
Screen saver
For power saving reasons, the Windows Phone 7 devices turn off the screen after a while when no user input happens. In this sense, accelerometer input is not considered user input. Obviously the device cannot distinguish between deliberate tilting of the phone in a game and e.g. changes in orientation that happen because the user carries the phone in their pocket or because they gesticulate in a discussion and are not actually using the phone. You can turn off the screen saver using the IsScreenSaverEnabled property of the Guide class to avoid that:


 1: // disable automatic turning off

 2: // due to no user touch input

 3: Guide.IsScreenSaverEnabled = false;


Further accelerometer resources
An interesting sample application with free source is the "Level Starter Kit" that can be found in the education section of the app hub. It has the same helper classes in it as the source code of the article on data smoothing linked above and creates a virtual bubble level to demonstrate the use of the accelerometer.
Another cool library is the recently released Shake Gesture Library that provides a high-level abstraction of "shake flicks" performed by the user. This post on the Windows Phone Developer Blog gives a short introduction and explanation of the concept.
Additional sensors and combined motion API
With Windows Phone "Mango", developers will have access to additional sensors, in particular the compass and gyroscope. Unlike with the accelerometer, which was a requirement for all devices for the RTM release of Windows Phone, not all devices in the market will have a gyroscope, for example. So if you build an application or game that relies on a gyroscope, some users won't be able to use your application (they will receive a warning in the market place when they browse to your application). This is something you need to accommodate for – make sure the sensor you're trying to use is actually available on the current device to avoid errors.
Since the API for sensors has been streamlined in Mango (see above), all of them work in a similar way. For example, making use of the compass very much resembles what has been written above for the accelerometer:


   1: // make sure we have a compass

   2: if (Compass.IsSupported)

   3: {

   4:     // create a new compass

   5:     Compass _compass = new Compass();

   6:  

   7:     // set the desired interval for value readings

   8:     _compass.TimeBetweenUpdates = TimeSpan.FromMilliseconds(100.0);

   9:  

  10:     // use the new event for value readings

  11:     _compass.CurrentValueChanged += new EventHandler>(Compass_CurrentValueChanged);

  12:  

  13:     // start reading

  14:     _compass.Start();

  15: }

  16:  

  17: ...

  18:  

  19: private void Compass_CurrentValueChanged(object sender, SensorReadingEventArgs e)

  20: {

  21:     // the actual data is in the "SensorReading" property,

  22:     // which is a "CompassReading" object in this case

  23:     var data = e.SensorReading;

  24:  

  25:     // do something with the read data...

  26: }


A special feature of the new sensor API is the Motion class. This class combines the data of the compass, the accelerometer and gyroscope to accurately perform an analysis of the device location and its orientation in space. This is a convenient wrapper around some sophisticated math to compute that data, so you don't have to do this manually. The beauty of this is that the Motion class also inherits from the SensorBase class and hence can be used like any other sensor – this makes it very easy to get complete sensor data information on the phone. 
Summary
I hope this article has made your mouth water for this alternative input method. Already existing games and applications in the market place that use this technique prove that using it in real world scenarios is not only feasible but can be a valuable addition and even create a completely new user experience. The performance and quality of the returned data even make sophisticated features like the recognition of shake patterns possible. If you have any questions or requests, feel free to leave a comment or contact me directly.
Download source code
About the author
Peter Kuhn aka "Mister Goodcat" has been working in the IT industry for more than ten years. After being a project lead and technical director for several years, developing database and device controlling applications in the field of medical software and bioinformatics as well as for knowledge management solutions, he founded his own business in 2010. Starting in 2001 he jumped onto the .NET wagon very early, and has also used Silverlight for business application development since version 2. Today he uses Silverlight, .NET and ASP.NET as his preferred development platforms and offers training and consulting around these technologies and general software design and development process questions.
He created his first game at the age of 11 on the Commodore 64 of his father and has finished several hobby and also commercial game projects since then. His last commercial project was the development of Painkiller:Resurrection, a game published in late 2009, which he supervised and contributed to as technical director in his free time. You can find his tech blog here: http://www.pitorque.de/MisterGoodcat/


XNA for Silverlight developers: Part 5 - Input (touch + gestures)
editorial@silverlightshow.net (Peter Kuhn ) — Mon, 28 Feb 2011 00:22:00 GMT
Are you interested in creating games for Windows Phone 7 but don't have XNA experience? 

Watch the recording of the recent intro webinar delivered by Peter Kuhn 'XNA for Windows Phone 7'.



Don't miss...

    What is Windows Phone series 
    XNA article by Levente Mihály 
    WP7 series by Andrea Boschin 
    The XNA series is now available as a fully offline resource 


     All SilverlightShow Ebooks 

This article is part 5 of the series "XNA for Silverlight developers".
This article is compatible with Windows Phone "Mango". 

Latest update: Aug 1, 2011.
User input on a mobile device is always an interesting topic, because it's usually so much different from normal desktop applications on a conceptual level already. You have no pointing device like a mouse, which eliminates some possibilities altogether (hovering or right-click, for example), but on the other hand an all new class of features is added through modern technology, like multi-touch gestures and additional sensors (like accelerometers). 
I've already talked about the theory and reasons of "event-driven vs. polling" regarding input in the first part of the series, and I encourage you to take another look at this paragraph to brush up on the topic once again. This article will mostly skip over these theoretical parts and take a closer look at how you actually make use of user input and dive into the involved code.
Silverlight
A Silverlight app on the phone very much works like the desktop version regarding input. You usually have some sort of control that exposes various user interaction events. You then add event handlers to those events you're interested in, and when the user action happens, your event handler is invoked automatically by the runtime. The following shows the button click event as an example.

The crucial part is not the way you add your event handlers, i.e. whether you use XAML to do that or code-behind. You might even use a completely different approach, for example in an application designed with the MVVM pattern where you use commands instead of events. The important detail is that your application is in the passive role here. It just sits there, waits and does nothing until something of interest happens. It reacts to events the runtime manages and pushes towards you.
This is even true if you are not interested in input events for a certain control, but want to integrate with e.g. gestures. To do this you would use the gesture listener provided by the Silverlight Toolkit for Windows Phone. It raises events you can listen to whenever gestures are detected, hence it features the same programming model for this scenario too. If you want to learn more about the gesture listener in Silverlight, you can read one of my blog posts were I give more explanations and a sample with source code.
XNA
In XNA the fundamental concept of how you acquire user input is completely different. All of a sudden, your code is in the active role and has to ask the runtime about user input. If you don't ask, you'll never take notice. One of the central classes for input in XNA on the phone is TouchPanel. It is a static class that only has a hand full of properties and methods which basically let you set up the input features as well as retrieve all input data that is available through the touch screen of a device. The required steps are:

    Tell the touch panel what kind of input you are interested in (this is a one time thing or needs only be changed when you want to be notified of different input data in different contexts, see below). 
    Ask the touch panel if input data is available (you have to do this regularly/in each frame). 
    Retrieve and process the data. 

Additionally you can ask the touch panel for its capabilities, but since all Windows Phone 7 devices report the same feature set, that currently is of little use on this platform. Let's see how this translates into code:
Enabling gestures
Enabling gestures is very simple. There is a gesture type enumeration with the different types of gestures that are supported on the device, and you can pass one or more of these values to the static "EnabledGestures" property of the touch panel. This is something you typically do in your game class constructor for simple games; in most projects however you will work with a concept of different "screens" (for example for menus, the actual game, supplementary content like high-scores etc.). In these cases you can re-initialize this property for each screen that is shown to the user to optimize for only those gestures that you actually need in a particular context.


 // enable gestures

 TouchPanel.EnabledGestures = GestureType.Tap | GestureType.Flick;


Tap is the simplest gesture available and denotes that the user briefly touches a single point on the screen. You can think of it as the touch counterpart of a mouse click. When you look at the other enumeration values you can see that all of the common gestures are available:

    Tap, DoubleTap, Hold: involve touching a single point on the screen and are usually used to invoke some action like "clicking" or selecting something. 
    HorizontalDrag, VerticalDrag, FreeDrag, DragComplete: These are the gestures that are a combination of touching and dragging on the screen. You can use these to move objects around the screen, or for scrolling, panning and similar actions. 
    Pinch, PinchComplete: Explained as "two-finger dragging" in the documentation. This is normally used for features like zooming. 
    Flick: A special gesture that is positionless. It describes quick swipes on the screen that often are used for flipping through items or pages etc. 


Reading gestures
You have to check for available gesture data in each call of the "Update" method in your game, or you might miss gesture data. The following code shows how to do this to retrieve individual GestureSample objects which contain the actual details about the detected gesture:


 // check whether gestures are available

 while (TouchPanel.IsGestureAvailable)

 {

     // read the next gesture

     var gesture = TouchPanel.ReadGesture();

  

     // has the user tapped the screen?

     if (gesture.GestureType == GestureType.Tap)

     {

         // move the sprite to the tap position 

         _position = new Vector2(gesture.Position.X - _sprite.Width / 2.0f,

             gesture.Position.Y - _sprite.Height / 2.0f);

     }

     else if (gesture.GestureType == GestureType.Flick)

     {

         // add a fraction of the flick delta (= velocity) to the position

         _position += gesture.Delta * 0.1f;

   

         // make sure the sprite doesn't move off screen

         var viewPort = _graphics.GraphicsDevice.Viewport;

         var min = new Vector2(-_sprite.Width / 2.0f, -_sprite.Height / 2.0f);

         var max = new Vector2(viewPort.Width - _sprite.Width / 2.0f, viewPort.Height - _sprite.Height / 2.0f);

         _position = Vector2.Clamp(_position, min, max);

     }

 }


You can ask the touch panel for available gestures using the "IsGestureAvailable" property. Please note that multiple gesture samples can be available, which is why I'm using a while loop here to make sure I retrieve all of them. Next you retrieve the gesture sample by calling "ReadGesture" on the touch panel. From there, you simply check for the gesture type that was detected and process the data accordingly. 
As you can see, all the different gestures work with the same data structures. But not all the properties of a gesture sample are meaningful for every gesture type. You have to refer to the above linked documentation to decide what pieces of information really make sense for a certain gesture. For example, in the above code I use "Position" for the tap and the "Delta" property for flicks; since flicks are positionless, you cannot use the "Position" property with them.
Conclusion
This sample shows how the major difference between XNA and Silverlight regarding input translates to code, and how your game actively has to ask for input data instead of receiving that information through events.


The attentive reader notices another detail here. Where you can target a particular element in Silverlight and have notifications send to your application only for this element, the XNA approach is way more generic. The filtering for useful information has to happen in your application. That means that once you have the information that the user has touched the screen, you have to decide yourself if this is of any use for you, for example if the location the touch panel has reported belongs to some element on the screen that should react to user input. In Silverlight, if a click event like above happens, you already know that it belongs to the button and what action to invoke as a result, and you also will never receive that button click event when the user clicks outside the button bounds.
A simplified approach
What surprisingly many XNA developers do not know is that there's a simpler way to get access to input touch data for simple scenarios through the Mouse class. Even though there's no such thing as a mouse on the phone, the library developers have mapped the primary touch point data to what corresponds to the left mouse button on the desktop. This means that if you're only interested in tap data, you can use something like this in your Update method:


 // get the "mouse" state

 var mouseState = Mouse.GetState();

   

 // the left button press is equal to touching the screen

 if (mouseState.LeftButton == ButtonState.Pressed)

 {

     // move the sprite to the "mouse click" position 

     _position = new Vector2(mouseState.X - _sprite.Width / 2.0f,

         mouseState.Y - _sprite.Height / 2.0f);

 }


Note that the "Pressed" state of the left mouse button is the only constellation where this class returns meaningful data for the X and Y coordinates. More details on this can be found here. Since this data is also updated when the user moves their fingers around the screen, you can even create simple dragging functionality using this approach.
Taking a deeper dive
Working with gestures already is an abstraction of what actually happens with the touch panel. Flicking or dragging is only an interpretation of a series of low-level touch samples that happen over time to make it easier for developers to work with these common gestures. I you want, you can make use of these low-level samples for your own scenarios. Why would you want to do that? Well, every Windows Phone 7 touch screen is capable of handling up to four touch points at the same time. The built-in convenience wrappers for gestures only make use of up to two points (pinching). So digging deeper into the touch input features allows you not only to create your own gesture types, but also to make use of this fact and create new and innovative input concepts that go way beyond the usual. Let's see how that works.
In your "Update" method, call the "GetState" method on the touch panel to retrieve a collection of touch locations. Each of these locations has the following properties:

    Id: This value is very important for the tracking of successive samples that belong to the same logical touch action. Each time a finger touches the screen, a new id is generated. This id will stay the same for all of the following touch samples of this finger until the user removes it from the screen. Because you will retrieve multiple touch locations when the user puts multiple fingers on the screen, this is the value to determine which touch locations belong to the same finger over a period of time. 
    Position: This obviously is the position of the touch point as 2D vector. 
    State: One of the possible touch location state enum values. New touch locations have a state of "Pressed", locations that were existing before have "Moved". Please note that you'll receive "Moved" location info even if the finger has not really moved physically. "Released" happens when the finger is removed, and "Invalid" should only occur when you try to use the TryGetPreviousLocation method and there is no such previous location. 

Here is some sample code that makes use of touch locations. First the "Update" method:


 // clear previous locations

 _touchLocations.Clear();

  

 // get the raw state of the touch panel

 var touchCollection = TouchPanel.GetState();

  

 foreach (var touchLocation in touchCollection)

 {

     // we are only interested in pressed (= new)

     // and updated (= moved) locations

     if (touchLocation.State == TouchLocationState.Moved

         || touchLocation.State == TouchLocationState.Pressed)

     {

         // store this location for the draw method

         _touchLocations.Add(touchLocation);

     }

 }


Then, in the draw method, I simply output the number of recognized touch locations and one sprite for each of them (including a text overlay that prints out the id).


 // draw number of touch locations

 _spriteBatch.DrawString(_font, "Number of touch locations: " + _touchLocations.Count, Vector2.Zero, Color.White);

   

 foreach (var touchLocation in _touchLocations)

 {

     // calculate position of sprite

     var position = new Vector2(touchLocation.Position.X - _sprite.Width / 2.0f,

         touchLocation.Position.Y - _sprite.Height / 2.0f);

  

     // draw sprite

     _spriteBatch.Draw(_sprite, position, Color.Blue);

   

     // draw id

     _spriteBatch.DrawString(_font, touchLocation.Id.ToString(), position, Color.White);

 }


Of course working with multiple touch locations makes most sense on a real device, not in the emulator.
If you want to develop your own gestures, you have to collect these samples and try to interpret them as they occur, according to your requirements. This however is way beyond the scope of this article.

Summary
In this part we have learned about the various possibilities of touch input on Windows Phone 7 in XNA. You can use the simplest method of the mouse analogon for simple situations, like menu screens, or go all the way down to collecting low-level touch samples to create a multi-touch input application. In between those extremes, you have access to pre-built gestures that allow a more comfortable access to most common input requirements. You can download the source code to the three above demonstrated samples here:
Download source code
Please feel free to add your comments and thoughts, or contact me directly with any questions you have. 
About the author
Peter Kuhn aka "Mister Goodcat" has been working in the IT industry for more than ten years. After being a project lead and technical director for several years, developing database and device controlling applications in the field of medical software and bioinformatics as well as for knowledge management solutions, he founded his own business in 2010. Starting in 2001 he jumped onto the .NET wagon very early, and has also used Silverlight for business application development since version 2. Today he uses Silverlight, .NET and ASP.NET as his preferred development platforms and offers training and consulting around these technologies and general software design and development process questions.
He created his first game at the age of 11 on the Commodore 64 of his father and has finished several hobby and also commercial game projects since then. His last commercial project was the development of Painkiller:Resurrection, a game published in late 2009, which he supervised and contributed to as technical director in his free time. You can find his tech blog here: http://www.pitorque.de/MisterGoodcat/


XNA for Silverlight developers: Part 3 - Animation (transforms)
editorial@silverlightshow.net (Peter Kuhn ) — Wed, 09 Feb 2011 02:20:00 GMT
Are you interested in creating games for Windows Phone 7 but don't have XNA experience? 

Watch the recording of the recent intro webinar delivered by Peter Kuhn 'XNA for Windows Phone 7'.



Don't miss...

    What is Windows Phone series 
    XNA article by Levente Mihály 
    WP7 series by Andrea Boschin 
    The XNA series is now available as a fully offline resource 


     All SilverlightShow Ebooks 

This article is part 3 of the series "XNA for Silverlight developers". 
This article is compatible with Windows Phone "Mango". 

Latest update: Aug 1, 2011.
Animation is a word of Latin origin and means "make alive/bring to live" (animare) or "spirit" (animus). It describes the technique of using a series of single images to create the illusion of movement for the beholder. We all know that concept from the movies and television where the rapid display of a sequence of frames results in the impression of natural motion. In computer graphics and especially games, we use the same technique to bring characters and other elements to life, give the player feedback about their input commands and create a more interesting overall experience. In this article, we'll learn more about animation in general and how it is done in XNA in particular.
Two kinds of animations
When I work with computer games, I like to distinguish between two kinds of animations: transformations and frame-based animation. We have already seen a few glimpses of transformations in the previous parts; when we drew the first sprite onto the screen and moved it around, we have used a translation to create a circular motion in part 1. In part 2 we talked about scaling, which is another simple transformation. These transformations will be part of this article.
The other type of animation that can frequently be found in 2D games is frame-based, which means that the actual content of an element on the screen (i.e. the bitmap that forms the sprite) changes over time. This technique is used when a certain effect cannot be achieved by using the mentioned transformations. For example, imagine a player character that moves its feet when it is walking. There is no way of achieving this animation by applying a transformation or a set of transformations like translations, rotations and scaling to the whole sprite. Instead, you use multiple different images that are shown on the screen in succession to create this animation – just like in a movie. We'll take a deeper look at those animations in the second article about animations.
Transformations Theory
From a mathematical point of view, a transformation defines how to map points from one coordinate space to another one using transformation matrices. All of the basic transformations we have shortly talked about so far are so-called affine transformations, which simply put means that after you apply such a transformation, points that were on a line before are still on a line, lines that were parallel before are still parallel afterwards, and ratios of distances are preserved. Samples for these transformations are:

    Scale 
    Skew 
    Rotate 
    Translate 

You most likely already guessed that there also are non-affine transformations that are more complex. Silverlight's perspective transforms (projections) that allow you to apply 3D-like effects to 2D elements are an example for that.
Luckily for us the frameworks we are working with make things easier when we need to use most of those common transformations, so we don't have to dig deeper into the mathematical theory at this point. They are supported by pre-configured shortcuts, helper classes and simplifications, so chances are high you won't ever see a transformation matrix or have to do the involved computations manually when you're writing a 2D game.
The situation in Silverlight
In Silverlight, there are multiple factors that determine the position and final appearance of an object on the screen. It has in fact two different concepts that influence this: the layout process and render transforms. The layout process is the mechanism that is used to position an element with respect to its size, container and siblings. Of course the key component in that process is what layout container is used to hold the element. Some containers, like the stack panel for example, position their children automatically, whereas others like the canvas don't. In addition, properties like the margin affect the final layout position too.
Separately from that, you have the possibility to change the visual appearance of an element by using render transforms. Those transformations are applied after the measure and arrange passes of Silverlight's layout process and hence do not affect the positioning of other elements on the screen. This makes them considerably cheaper to use than manipulating properties that trigger a layout update (so if you're able to achieve the same effect using both layout properties and render transforms, use the render transform). Render transforms cover pretty much all the transformations we've discussed above. They enable an extremely simple usage where you only need to set the required parameters (like an angle for a rotation), and the rest is done for you automatically behind the scene. The Silverlight documentation on MSDN actually provides a very sophisticated explanation of transforms and the involved classes and properties. 

When it comes to actually animating these transforms, Silverlight has the very powerful tool of storyboards. They can contain one or more animations that are used to manipulate an object's properties over time. Of course the mentioned render transforms are suitable targets for these animations. If you combine all these tools and make use of some further helpers like triggers and actions, you can create complete animations without writing a single line of code. Especially if you're using a software like Expression Blend, that is a matter of only a few minutes. Here is an example of an image declaration in XAML:


 <Image x:Name="image"

        Source="Block.png">

     <Image.RenderTransform>

         <TranslateTransform />

     Image.RenderTransform>

     <i:Interaction.Triggers>

         <i:EventTrigger>

            <ei:ControlStoryboardAction Storyboard="{StaticResource DemoStoryboard}" />

         i:EventTrigger>

     i:Interaction.Triggers>

 Image>


What we can see here is how transforms are attached to an element in XAML (line 3-5). Lines 6-10 contain the magic of an event trigger that starts a storyboard named "DemoStoryboard" when the image is loaded. Such a storyboard can look like this:


 <Storyboard x:Name="DemoStoryboard"

             RepeatBehavior="Forever">

     <DoubleAnimationUsingKeyFrames Storyboard.TargetProperty="(UIElement.RenderTransform).(TranslateTransform.X)"

                                    Storyboard.TargetName="image">

         <LinearDoubleKeyFrame KeyTime="0"

                                 Value="0" />

         <LinearDoubleKeyFrame KeyTime="0:0:1"

                                 Value="170" />

         <LinearDoubleKeyFrame KeyTime="0:0:2"

                                 Value="340" />

         <LinearDoubleKeyFrame KeyTime="0:0:3"

                                 Value="200" />

         <LinearDoubleKeyFrame KeyTime="0:0:4"

                                 Value="0" />

     DoubleAnimationUsingKeyFrames>

     <DoubleAnimationUsingKeyFrames Storyboard.TargetProperty="(UIElement.RenderTransform).(TranslateTransform.Y)"

                                    Storyboard.TargetName="image">

         <LinearDoubleKeyFrame KeyTime="0"

                                 Value="0" />

         <LinearDoubleKeyFrame KeyTime="0:0:1"

                                 Value="440" />

         <LinearDoubleKeyFrame KeyTime="0:0:2"

                                 Value="200" />

         <LinearDoubleKeyFrame KeyTime="0:0:3"

                                 Value="50" />

         <LinearDoubleKeyFrame KeyTime="0:0:4"

                                 Value="0" />

     DoubleAnimationUsingKeyFrames>

 Storyboard>


This storyboard shows several concepts: it contains two separate animations, one that targets the "X" property of the translate transform that is attached to the image, and a second one that targets the "Y" property. Both animations work with multiple values and time stamps to move the image element around on the screen. We can also see that the "RepeatBehavior" property of the storyboard is set to "Forever" so the animation starts over once it is finished.

The beauty of all this is not only that we've created an animation without writing a single line of code. The great amount of built-in animation types which in turn often have a variety of properties (for example different kinds of key frames that could be used in the above example) make it possible to tune those animations with extremely little effort. Furthermore, since version 3 Silverlight offers so-called easing functions that allow you to apply custom mathematical formulas to animations. And again it already provides a variety of built-in functions that let you create bounce or spring animations and others without custom code. The Silverlight sample code gallery on MSDN has a nice playground you can use to explore those features. All in all Silverlight's animation system in combination with render transforms is really powerful and simple to use.
... and in XNA
We've already learned that XNA has no layout engine like Silverlight does. On the one hand that means that you lose a lot of comfort which Silverlight's layout containers offer, on the other hand this kind of simplifies the process of using transformations, as you don't have to cope with multiple concepts in parallel when you're using XNA. There's basically one single place where all the parameters for the final visual appearance of a sprite on the screen can be set at once, and that is when you draw it using the sprite batch class (of course there are other factors that influence the final looks in XNA too, but for now this explanation is sufficient).


 public void Draw (

          Texture2D texture,

          Vector2 position,

          Nullable sourceRectangle,

          Color color,

          float rotation,

          Vector2 origin,

          float scale,

          SpriteEffects effects,

          float layerDepth

 )


As you can see the draw method of the sprite batch class has the possibility to pass in various arguments that allow manipulation of the rendering, including the position, rotation and scale values as well as the origin for transformations, a SpriteEffects enumeration value for mirroring features and a layer depth value for z-ordering. As you can see, there's no counterpart for Silverlight's skew transform in XNA. If you want to achieve such an effect, you have to create the matrix transform for it yourself.
The other huge limitation in XNA is that there is no built-in feature like the storyboards in Silverlight. Where you create animation descriptions declaratively in Silverlight and behind the scenes all the computations are done for you at runtime automatically, you have to perform most of that work in XNA manually. It's still not that hard for simple animations, but if you try to mimic something like the easing functions of Silverlight for example, you'll quickly find yourself spending quite some time programming mathematical formulas. In the following paragraphs we'll take a look at basic and more advanced transforms and animations.
Translation
This is probably the most simple form of animation you can do in your game. It only involves manipulation of the position where an object will be drawn on the screen.

As you can see, translating an object requires changing the x- and y-coordinates of its position. By doing so you can move the object to any place on the screen and even off-screen. We had seen an example for that in Part 1 of the series already. In the Update method of our game class, we calculated the position (a 2-dimensional vector) like this:


 // take the screen width

 var screenWidth = graphics.GraphicsDevice.Viewport.Width;

  

 // calculate the new rotation agle

 angle -= gameTime.ElapsedGameTime.TotalSeconds;

  

 // update the x and y coordinates

 position.X = (float)(screenWidth / 2.0 - block.Width / 2.0 + 200 * Math.Cos(angle));

 position.Y = (float)(screenWidth / 2.0 - block.Height / 2.0 + 200 * Math.Sin(angle));



This resulted in a circular motion around a central point of the screen with the circle having a radius of 200 pixels. The important part we had learned was that you need to update the position (and every other value as we'll see in a moment) dependent on the amount of time that has elapsed since the last call to the update method. In the above sample, the elapsed seconds were added to the rotation angle. Since 2*pi describes a full circle (remember, we are using radians here) that means that the sprite ("block") finished a full turn after 2*pi ~= 6.28 seconds. If you wanted to make the sprite take 10 seconds to finish one circle, you would have calculated the angle as:


 // target a duration of 10 seconds for a full circle

 // full circle = Math.PI * 2

 // => (Math.PI * 2) / 10.0 units per second

 angle -= ((Math.PI * 2) / 10.0) * gameTime.ElapsedGameTime.TotalSeconds;


When you play around with this, you'll quickly get used to the following pattern: 

    Determine how far you want to move an object per second (here: 1/10th of a circle) 
    Multiply that by the amount of elapsed seconds (which usually will be a small fraction of one second) 

In the Draw method of the game class, we used that calculated position to actually draw the sprite on the screen:


 spriteBatch.Begin();

 spriteBatch.Draw(block, position, Color.Red);            

 spriteBatch.End();


Scale
Scaling describes the method to change the size of an object. In XNA, there are two methods for scaling sprites; the more common on is a uniform scale factor you can pass to the draw method of the sprite batch (we'll learn about the second one in the next section). Let's jump right into a sample. First of all, we define the two class fields we need for this:


 float scale = 1.0f;

 float scalingPerSecond = 0.5f;


The first one holds the current scale factor (in the beginning this will be 1.0f which is the original size of the sprite). The second variable describes the change of the scale factor per second we want to achieve. Once again we determine the amount of change for the transform dependent on the elapsed time and a target value per second. To this end, I've changed the Update method of the game class to calculate the scaling:


 // calculate the scaling

 scale += scalingPerSecond * (float)gameTime.ElapsedGameTime.TotalSeconds;

 if (scale > 1.5f)

 {

     // if the block has grown to 150%,

     // reverse the scaling process

     scale = 1.5f;

     scalingPerSecond *= -1.0f;

 }

 else if (scale < 0.5f)

 {

     // if the block has shrunk to 50%,

     // reverste the scaling process

     scale = 0.5f;

     scalingPerSecond *= -1.0f;

 }


The content of line 2 is crucial. It adds the fractional change in scaling to the current scale factor, depending on the elapsed seconds. The rest of the code simply reverses the scaling (from growth to shrinking and vice versa) when the sprite size exceeds certain limits (the desired target values). When we draw the sprite, the code will look like this:


 // draw a second block that is scaled

 spriteBatch.Draw(block,

     Vector2.Zero,

     null,

     Color.Yellow,

     0.0f,

     Vector2.Zero, // this is the origin

     scale, // pass in the current scaling

     SpriteEffects.None,

     0.0f);


You can ignore most of the arguments for now, but please note how the scale factor is passed in in line 8. Also take notice of the argument on line 7 which is the origin used for all transformations. In the above code, we use the constant Vector2.Zero here. In this case this means that the upper left corner of the sprite will be the center of scaling and hence a fixed point.

You can pass in a different vector here, for example the center of the sprite, like this:


 spriteBatch.Draw(block,

     Vector2.Zero,

     null,

     Color.Yellow,

     0.0f,

     new Vector2(block.Width / 2.0f, block.Height / 2.0f), // this is the origin

     scale, // pass in the current scaling

     SpriteEffects.None,

     0.0f);


This will result in a scaling behavior that has the center of the sprite as origin:

This hopefully reminds you of similar properties we have in Silverlight's transforms, for example the CenterX and CenterY properties of the ScaleTransform. XNA's origin parameter however affects all the transforms equally; in that it behaves similar to Silverlight's RenderTransformOrigin, except that it does not use relative coordinates. This behavior is noteworthy, because the change in the above code snippet not only results in a different scaling, but it also moves the object to a different position compared to the previous code:
Before, the Vector2.Zero position described the location of the upper left corner of the sprite. Now that the origin has been set to the center of the sprite, the Vector2.Zero position describes the location of that center, thus effectively moving the sprite to the upper left by half its size.
Tip: you should be thoughtful regarding the origin parameter. In some situations it might be necessary to handle the origin differently on a case to case basis, depending on what you want to achieve in a particular situation. However my experience is that inexperienced XNA developers tend to lose track of this, especially when different developers working on the same project use different methods. The result then sometimes is very unpleasant situations where you have to track down "bugs" that surface as objects showing in the wrong places and are amazingly hard to analyze.

Using the destination rectangle
The second method you can use for scaling in XNA is to use a destination rectangle when you draw your sprite. The destination rectangle is actually a combination of both the translate and scale transforms: the X and Y properties determine the position, whereas the width and height of the rectangle determine the size of the final sprite. Using this method has two advantages:

    You don't have to know the source size of a sprite to achieve a certain target size. That means that your code will continue to work and result in the same visual dimensions even when the size of the source texture changes at a later point. 
    You can use the rectangle to stretch the sprite in a non-uniform way, which is not possible with the scale factor method. 



 // draw a block with the destination rectangle parameter

 Rectangle destination = new Rectangle(10, 40, 100, 50);

 spriteBatch.Draw(block,

     destination,

     Color.Yellow);


Here you see that the sprite is drawn at position (10,40), and has a width of 100 pixels and a height of 50 pixels. Since the source texture is square, this will squeeze the result to something like this:

And again, no matter what size the source is, these absolute dimensions will stay the same, which would be different when you use the previous scale method.
Please note that when you use the overload of the draw method that takes both a destination rectangle and an origin parameter, the result will behave as described before, i.e. the X and Y coordinates of the rectangle will determine the location of the origin.
Rotate
Rotating a sprite is pretty straight forward. The draw method of the sprite batch class takes an angle argument for this. All you have to remember is that this must be radians. In Silverlight when you are rotating an element using a rotate transform the Angle property takes degrees. If you are more comfortable using degrees then you can easily convert between both units:
radians = degrees * (pi / 180)
and
degrees = radians * (180 / pi)
XNA also has a MathHelper class which has methods to convert between degrees and radians you can use instead.
Once again the origin argument plays a crucial role in how your rotation is actually performed. The default value (Vector2.Zero) uses the upper left corner as fixed point which results in a rotation like this:

When you want to rotate around the center of an object you need to set the origin accordingly:

In our sample game, we already have calculated an angle for the movement of the block on the screen. We'll use that very same angle to rotate the block at the same time it does its circular motion, so the same side always faces the center of the circle. Since we also change the origin parameter so the block rotates around its center, we need to adjust the position calculation too - this is actually a good example of how fiddling around with the origin for your transformations can require changes in other places of your calculations. The new code looks like this:


 // take the screen width

 var screenWidth = graphics.GraphicsDevice.Viewport.Width;

  

 // target a duration of 10 seconds for a full circle

 // full circle = Math.PI * 2

 // => (Math.PI * 2) / 10.0 units per second

 angle -= ((Math.PI * 2) / 10.0) * gameTime.ElapsedGameTime.TotalSeconds;

  

 // update the x and y coordinates

 // we are now using the center of the sprite as origin,

 // which means we do not have to take the sprite size into account

 // for the position calculation

 position.X = (float)(screenWidth / 2.0 + 180 * Math.Cos(angle));

 position.Y = (float)(screenWidth / 2.0 + 180 * Math.Sin(angle));


As you can see the code to calculate the position actually got simpler in this case, as we do not need to take the sprite's size into account now that the origin is set to the center of the sprite.
The draw method now also takes the calculated angle as rotation value (line 6):


 // draw the first block that moves

 spriteBatch.Draw(block,

     position,

     null,

     Color.Red,

     (float)angle,

     Vector2.Zero,

     scale,

     SpriteEffects.None,

     0.0f);


Advanced topic: easing functions
Linear movement often isn't very pleasing to the eye and doesn't model reality very accurately. For example, when an object starts moving, then it looks a lot more natural when it starts off slow and gains speed as it goes. People are used to this kind of movement from the real world (inertia), and even if they don't know the physics behind it, they feel that something isn't quite right when your animated objects don't account for this. In this example, I'll show you how to make use of the built-in math helper class to create non-linear movement of an object. The idea is the following:

    Take the current position of your object and use it as start position 
    Determine the target position 
    Determine the time you want to take the object to go from the start to the target position 
    Depending on the elapsed time, use a mathematical formula to interpolate the new position 

This will work for a lot of easing functions, but of course there are endless possibilities, so some behave differently and may need less or more parameters to work. First of all, define the required class fields for this:


 Vector2 currentPosition;

 Vector2 sourcePosition;

 Vector2 targetPosition;

 double cycleTime = 3.0;

 double currentCycleTime = 0.0;


We keep track of the current position of the object and need the source and target position for the calculation. We also keep track of the elapsed time and how long we want the whole movement to take. The next thing we need to do is initialize the position values. I wanted to move the sprite from the upper left corner to the lower right corner, so I put the initialization code into the LoadContent method of the class, because I need the sprite dimensions for this:


 block = Content.Load("Block");

  

 // initialize the source positions

 sourcePosition = new Vector2(10, 10);

  

 // initialize the target position

 var screenWidth = graphics.GraphicsDevice.Viewport.Width;

 var screenHeight = graphics.GraphicsDevice.Viewport.Height;

 targetPosition = new Vector2(screenWidth - block.Width - 10,

                              screenHeight - block.Height - 10);

  

 // initialize the current position

 currentPosition = sourcePosition;


Nothing spectacular here. We just calculate the source and target positions with some margin, and set the current position to the start point. The interesting part is the code in the Update method, which looks like this:


 // first of all we sum the elapsed time

 currentCycleTime += gameTime.ElapsedGameTime.TotalSeconds;

  

 // now we calculate the weight

 var weight = (float)(currentCycleTime / cycleTime);

   

 // the math helper provides the actual position

 var currentX = MathHelper.SmoothStep(sourcePosition.X, targetPosition.X, weight);

 var currentY = MathHelper.SmoothStep(sourcePosition.Y, targetPosition.Y, weight);

   

 // set the new position

 currentPosition = new Vector2(currentX, currentY);

   

 // check whether we've arrived at the target position yet

 if (currentPosition == targetPosition)

 {

     // swap source and target

     var oldSource = sourcePosition;

     sourcePosition = targetPosition;

     targetPosition = oldSource;

   

     // reset cycle time

     currentCycleTime = 0f;

 }


First we sum the elapsed seconds and determine how far into the targeted duration for a full cycle we are. This will usually result in a value between zero and one, but might also exceed one slightly in certain cases. You should either clamp the value to zero and one or make sure that your mathematical function takes care of this (as it does in our sample).
The crucial part is located in lines 8 and 9. We use the SmoothStep helper function to do a cubic interpolation between the source position and target position values, depending on the amount of cycle time that has passed. This will result in a motion that starts off slow and accelerates over time, just to decelerate and become slower again when it approaches the target position, much like a pendular movement. This is the place where you could also plug a custom function. The rest of the code just swaps the source and target position when the cycle has finished to make the object move back to the previous position, which results in an periodic movement. You can take a look at the final result in the included sample applications below.

Summary
In this part of the series we have learned about the three most common basic transforms: translate, rotate and scale and how to use them in XNA. We have also seen how we can animate objects using these transforms, and how this requires more manual work in XNA compared to Silverlight's really powerful animation system. The last part gave you a glimpse of more complex and advanced animations, which can become more challenging but often are well worth the effort when you look at the results they make possible. You can download the source code to the various samples above here:
Download source code
While these animations are sufficient for simple games (think Spacewar! or Tetris) the next part of the series will take the concept of animations to the next level and introduce the frame-based approach which opens the door to really unlimited possibilities and most likely better suits what you associate with "animation" these days. 
About the Author
Peter Kuhn aka "Mister Goodcat" has been working in the IT industry for more than ten years. After being a project lead and technical director for several years, developing database and device controlling applications in the field of medical software and bioinformatics as well as for knowledge management solutions, he founded his own business in 2010. Starting in 2001 he jumped onto the .NET wagon very early, and has also used Silverlight for business application development since version 2. Today he uses Silverlight, .NET and ASP.NET as his preferred development platforms and offers training and consulting around these technologies and general software design and development process questions.
He created his first game at the age of 11 on the Commodore 64 of his father and has finished several hobby and also commercial game projects since then. His last commercial project was the development of Painkiller:Resurrection, a game published in late 2009, which he supervised and contributed to as technical director in his free time. You can find his tech blog here: http://www.pitorque.de/MisterGoodcat/


A classic memory game: Part 3 - Porting the game to Windows Phone 7
editorial@silverlightshow.net (Levente Mihály ) — Fri, 04 Feb 2011 09:29:00 GMT
This article is compatible with the latest version of Silverlight for Windows Phone 7.

Don't miss...

    XNA for SL developers series 
    Pro Game Design with SL4 book: 

          
             Show more books

This article is Part 3 of “A classic memory game”.
The series is about building the following classic memory game in Silverlight, and porting it to Windows Phone 7. In the first article we started a new MVVM Light project, created the controls and designed the game-states. In the second part we put the logic behind the game, and connected it with the View thus completing the Silverlight version of the game. In this final part we will port the game to Windows Phone 7.
You can download the original Silverlight version of the game here and the phone port from here.
First Steps
As you already know Windows Phone 7’s application platform is Silverlight. The version of Silverlight on the phone is not Silverlight 4, and it’s not Silverlight 3 either, I think we can put it somewhere between version 3 and 4, with some limitations (like the missing sockets API) and with some extras (the phone specific things). 
The tools are totally free, both Visual Studio 2010 Express and Microsoft Expression Blend for Windows Phone, you can download the tools here. For the WrapPanel we will also need the Silverlight for Windows Phone Toolkit. 
Since the Silverlight versions are not so different I just threw my original source code into a new Windows Phone 7 MVVM Light project:

I’ve added the original source (except App.xaml and App.xaml.cs) as already existing items. Of course to get it built I had to make a few modifications mainly in the namespaces. 
The Toolkit’s namespace changes 


from

xmlns:toolkit="http://schemas.microsoft.com/winfx/2006/xaml/presentation/toolkit"

to

xmlns:toolkit="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone.Controls.Toolkit" 


Interactivity and Interactions namespace becomes


from

xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"

xmlns:ei="http://schemas.microsoft.com/expression/2010/interactions"

to

xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"

xmlns:ei="clr-namespace:Microsoft.Expression.Interactivity.Core;assembly=Microsoft.Expression.Interactions"


Only one thing was incompatible with the phone’s version of Silverlight and that was the text formatting in bindings. Once I removed that the project could be built successfully. (A workaround is using a converter.)
The Phone UI
So the projects was built, and it actually ran. Too bad I could only see the edge of my start-menu, some resizing was needed. The display size of the phone is fixed: 480x800 pixels on all phones. This means we can rely on this size and use fixed elements. As well as resizing I converted my Grids to Canvases where it didn’t interfere with the animations. Canvas is a perfect fit for a fixed scenario and also it’s easier on the CPU as it won’t need to do complex calculations about the layout. An easy way to convert grids to canvases in Blend is the Change layout-type function:

I’ve also changed the card sizes to fill the screen better, so it’s 3x4 on easy, 4x5 on medium and 5x6 on hard.
  
After these adjustments the game was working fine in the emulator. And I finished these modifications in about 20 minutes, that’s pretty cool I think! Deploying it to the device is another story though, the game is working on the phone too, but it’s not a great experience yet. 

Adapting the UI to the phone – buttons
First, let’s see the problems with the UI. 
I’ve increased the size of the buttons, but it still felt a little hard to tap on them. It is strange, because the original buttons are smaller than the ones in the game, but they’re still easier to press. Let’s inspect the original button’s style in the phone. I dragged a button on the page, and edited a copy of its style, this is what I got:
  
The UI Design and Interaction Guide states:
“Touch targets should not be smaller than 9 mm or 34 pixels square and provide at least 2 mm or 8 pixels between touchable controls. In exceptional cases, controls can be smaller but never more than 9 mm or 26 pixels square.”
This is achieved by giving the buttons a bigger border which is transparent (highlighted red in the picture). So the actual button is bigger than what you see, and this way it enables you to be less accurate when tapping on them.
I simply copied this behavior in my custom controls. For the RadioButton I set up a fix sized rectangle, increased the size of the button and gave the outer Grid a transparent background. This last part is very important, because without a background the grid wouldn’t accept the input.
  
The end result is an increased touch target, giving a much better experience on the phone:

For the cards I gave a margin to the image to keep the hosting grid bigger.
Adapting the UI to the phone – back button
Currently, pressing the Back button will exit the game immediately. Games on the phone usually pause on the first Back key, exit on second press. I’ve introduced a PauseState and to change the Back button’s behavior I had to override the OnBackKeyPress method:


protected override void OnBackKeyPress(System.ComponentModel.CancelEventArgs e)

{

    if (currentState == "GameState")

    {

        Messenger.Default.Send<string>(Constants.PauseMessage, Constants.PauseMessage);

        VisualStateManager.GoToState(this, PauseState.Name, false);

        e.Cancel = true;

    }

    else

    {

        base.OnBackKeyPress(e);

    }

}

 

void VisualStateGroup_CurrentStateChanged(object sender, VisualStateChangedEventArgs e)

{

    currentState = e.NewState.Name;

}

 

string currentState = "";


If we are in game state, the Back key enters PauseState, otherwise it exists. Here’s the Pause state:

Performance Optimizations
Originally I added the images to the project as “contents”. The game loaded fast, starting the game on easy level was okay, but on hard it was very slow, meaning a 3-4 seconds pause before the cards appeared. That seemed slow even on a pc, but on the phone it felt forever. On a touchscreen the interaction between the user and the software is more direct than on pc using a mouse, so the user expectation is that s/he would immediately see some result when pressing/tapping a button. But the CPU of the phone is of course much less powerful than on a desktop computer so we need to address optimizations.
Databindings and converters in lists are very costly so I removed the converters from the cards’ bindings by adding the specific properties to the MemoryCard model. The Solved property became a Visibility type instead of boolean, and the Image property became an ImageSource instead of just a string pointing to the location of the image.
Jpegs are rendered faster on the phone, but the images of the memory cards are using rounded corners which needs transparency so they remained pngs. Adding the images as content resulted a speedy start for the app but a longer pause when the images needed to load. Adding the images as resources means a slower start for the app – the images load with the application – but better loading times for the images themselves. The LowProfileImageLoader gets the best of two worlds by loading/downloading images in the background without freezing the UI when they are on the web or added as content.
I ended up not using the LowProfileImageLoader, just adding the images as resources to the project:

and creating the BitmapImages on startup:


_imageCache = new List();

for (int i = 0; i < 15; i++)

{

 

    var bi = new BitmapImage();                

    bi.UriSource = new Uri(string.Format("Images/mm{0}.png", i), UriKind.Relative);

    _imageCache.Add(bi);

}


This way and by eliminating the converters, the load-time on hard difficulty went down from 3-4 seconds to 1,5 seconds. 
The pause still felt long so I added some animation to make it look shorter. After opting out adding the images in a BackgroundWorker (in the end it needed much more time, and the images appeared in very unbalanced intervals), I simply added a ProgressBar. I‘ve used Jeff Wilcox’s PerformanceProgressBar which really made my life easy. His version of the progress bar works in a background thread, and lets the animation finish. That meant I didn’t have to worry about working in a background thread, just switching the progress bar on and off  would display the standard indeterminate progress animation:


<extra:PerformanceProgressBar Width="320" Canvas.Top="710" Foreground="White" 

RenderTransformOrigin="0.5,0.5" Canvas.Left="80" IsLoading="{Binding IsBusy}" >

    <extra:PerformanceProgressBar.RenderTransform>

        <CompositeTransform ScaleX="1.5" ScaleY="1.5"/>

    extra:PerformanceProgressBar.RenderTransform>

extra:PerformanceProgressBar>




public void Start()

{

   _gameEnded = false;

   IsBusy = true;

   LoadCards();

   IsBusy = false;

   StartGame();

}


Please note, that the PerformanceProgressBar too costs CPU time, however it wasn’t significant in this case.
Tombstoning
The last phone-specific feature I wanted to add is tombstoning. Basically it means that the game can resume from its last state when it is interrupted by something, e.g a phone call. Every application has to handle interruption itself. Well, it is not obligatory, but if you want to give your users a good experience you should handle it. I really hope it will change in the future, and the OS will give some basic tombstoning out of the box, because it is not easy to handle. It seems easy to implement, in some cases it is easy, but usually it’s not. You really need to plan ahead.
We have four events to help us with implementing tombstoning:

    Application_Launching – occurs when the application starts 
    Application_Activated – occurs when the application resumes 
    Application_Deactivated – occurs when the application is sent to background (e.g. phone call) 
    Application_Closing 

Storing the state we have two options:

    IsolatedStorage – will remain permanent 
    PhoneApplicationService.Current.State – a dictionary which stays in memory for a time when the application is deactivated 

I’ve created an AppState class storing all the info of the game that it needs to resume and used Mike Talbot’s SilverlightSerializer to serialize and save it.
Here’s the AppState class:


public class AppState

{

    public List MemoryCardList { get; set; }

    public int TimeCounter { get; set; }

    public int MoveCounter { get; set; }

    public int PairCounter { get; set; }

    public int CardSize { get; set; }

    public Difficulties Difficulty { get; set; }

    public AppState()

    {

    }

}


Nobody wants to continue a memory game several hours later, so I handled only the activation/deactivation events, and store the state in the temporary Dictionary. You can easily modify the code to do the state saving on the closing event too, and save it to IsolatedStorage instead of the State dictionary.


// Code to execute when the application is activated (brought to foreground)

// This code will not execute when the application is first launched

private void Application_Activated(object sender, ActivatedEventArgs e)

{

    try

    {

        var storage = PhoneApplicationService.Current.State;

        if (storage.ContainsKey(AppStateKey))

        {

            byte[] appStateBytes = storage[AppStateKey] as byte[];

            AppState appState = SilverlightSerializer.Deserialize(appStateBytes);

            MemoryViewModelLocator.SetAppState(appState);                    

        }

    }

    catch { }

}




// Code to execute when the application is deactivated (sent to background)

// This code will not execute when the application is closing

private void Application_Deactivated(object sender, DeactivatedEventArgs e)

{

    var appState = MemoryViewModelLocator.MainStatic.GetAppState();

    if (appState != null)

    {

        var storage = PhoneApplicationService.Current.State;

 

        byte[] stateBytes = SilverlightSerializer.Serialize(appState);

 

        if (storage.ContainsKey(AppStateKey))

        {

            storage[AppStateKey] = stateBytes;

        }

        else

        {

            storage.Add(AppStateKey, stateBytes);

        }

    }

}


We can tell SilverlightSerializer which properties not to serialize with the DoNotSerialize attribute, e.g. the MemoryCard’s Image property:


[DoNotSerialize]

public ImageSource Image { get; set; }


You can try the tombstoning by pressing the windows-key during the game and then press the back-key to resume the game.
Summary
Porting the game to Windows Phone 7 was quite easy, Microsoft did a really great job. In this article we adopted the game to the phone in terms of UI and performance and we implemented tombstoning. With Windows Phone 7 Silverlight is becoming a real multi-platform framework, and I hope it is just the beginning. 
Please, don’t hesitate to drop a comment if you have questions, I hope you enjoyed this project at least half as much I did! 
About the Author
My name is Levente Mihaly. I've entered the .NET world in 2006, and after graduating at Budapest University of Technology (Msc in Computer Science) I started working as a .NET software developer. After meeting technologies like WinForms and ASP.NET, Silverlight quickly became my favourite platform from the early Silverlight 2 beta stages. I was always interested in mobile development and now I'm very happy since with Windows Phone 7 I can easily expand my knowledge to the mobile world. Nowadays beside following Silverlight I'm focusing on WP7 in my free time. I'm also the runner-up of the 2010 Silverlight ecoContest. You can reach me on twitter (@leventemihaly). 

 


XNA for Silverlight developers: Part 2 - Text rendering
editorial@silverlightshow.net (Peter Kuhn ) — Wed, 26 Jan 2011 08:52:00 GMT
Are you interested in creating games for Windows Phone 7 but don't have XNA experience? 

Watch the recording of the recent intro webinar delivered by Peter Kuhn 'XNA for Windows Phone 7'.



Don't miss...

    What is Windows Phone series 
    XNA article by Levente Mihály 
    WP7 series by Andrea Boschin 
    The XNA series is now available as a fully offline resource 


     All SilverlightShow Ebooks 

This article is part 2 of the series "XNA for Silverlight developers".
This article is compatible with Windows Phone "Mango". 

Latest update: Aug 1, 2011.
Rendering text output in a game is not as fundamental as it is in other apps or business applications. However, it still is a very important part because you will need this everywhere: to render statistics like the current player score on the screen, to show messages or help text, and of course also for additional features and parts of your game that are not related to the game play itself, like menus or high score screens. Drawing text is another area with huge differences between XNA and Silverlight, which we will see and learn about in this part of the series. As always, you can download the full source code at the end of the article.
Silverlight
Text in Silverlight is so essential that you barely write it out directly. Instead you use the variety of controls that is available to do this on a higher level: text blocks and labels to show simple text, rich text controls for formatted text, and text boxes to offer the user the ability to edit text. And of course there's a whole set of additional controls that build upon these basic elements. The text rendering itself offers incredibly rich possibilities; for example, you can change fonts and colors on the fly. You can even use gradients and image brushes to create more interesting looks. And of course, if you want to get down to the lower levels of text rendering, there's also the Glyphs class that let's you manipulate advanced properties on character level. Except for the latter one, Silverlight's text controls also handle layout issues for you. Centering text or changing other aspects of the rendering is a simple matter of setting properties to different values. And so something simple as this:


 <TextBlock Text="Silverlight and Text"

         FontFamily="Arial Black" 

         FontStyle="Italic" 

         FontSize="29.333">

     <TextBlock.Foreground>

         <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">

             <GradientStop Color="Black" Offset="0"/>

             <GradientStop Color="Red" Offset="1"/>

         LinearGradientBrush>

     TextBlock.Foreground>

 TextBlock>


Turns out to become a rendered text like this:


    XNA
    Silverlight's text rendering features are not only very sophisticated and comfortable, they're also expensive. In a game, where computing power is a critical resource, you don't want to waste that on calculating gradients and sub-pixel text rendering details. And of course XNA doesn't have a concept of controls with layout containers or a visual tree where text elements could integrate. So – I bet you already expected that – text rendering is more painful and limited. The good news however is that the required steps have been simplified a lot compared to "pure" Direct3D environments, so even if it is not as comfortable, drawing text in XNA still is straight-forward and not hard to accomplish – as long as you plan ahead.
    Fonts basics
    In the last part we've learned about the SpriteBatch class which I said is used for both text and sprite rendering. This already hints at the fact that in XNA, rendering text is actually done using bitmaps. This immediately becomes apparent when you try to do something where bitmaps are bad at. Take the following picture of a short text that was manipulated using a 500% scale transform in Silverlight, for example:
    
    And here is how the same thing looks in XNA:
    
    Where I come from, people like to use the term "suboptimal" for things like this :). Seriously, this is something you simply don't do in XNA. If you need to use fonts at different sizes, you don't use the built-in scaling capabilities, but ideally create separate so-called sprite fonts for each size (or at least start with a bigger size and only scale it down). For example, text rendered with the same sprite font but created at five times the previous size looks pretty nice:
    
    Creating sprite fonts
    Now let's see how these sprite fonts are actually created, what they are and how they are used in practice. Like any other asset, your fonts go through the content pipeline too, so the content project of your game is the right place to start at. 
    
    When you choose to add a new item to a content project you get a set of specific types for XNA, and "Sprite Font" is one of them. After it is created, Visual Studio opens it automatically for you. Surprisingly, it is just an XML file (I've removed the default comments for clarity):
    
    
     xml version="1.0" encoding="utf-8"?>
    
     <XnaContent xmlns:Graphics="Microsoft.Xna.Framework.Content.Pipeline.Graphics">
    
       <Asset Type="Graphics:FontDescription">
    
        <FontName>Segoe UI MonoFontName>
    
         <Size>14Size>
    
         <Spacing>0Spacing>
    
         <UseKerning>trueUseKerning>
    
         <Style>RegularStyle>
    
         
    
         <CharacterRegions>
    
           <CharacterRegion>
    
             <Start> Start>
    
             <End>~End>
    
           CharacterRegion>
    
         CharacterRegions>
    
       Asset>
    
     XnaContent>
    
    
    This file only describes the details of the sprite font that the content pipeline and in particular the sprite font importer and processor will create for you. The result of this import process is a texture that contains images of the individual characters, and when you render your text later, the sprite batch class will internally choose the right parts of this texture to re-create the text on the screen. All the detail information about the individual options you can use are listed in the XML schema reference for sprite fonts on MSDN. I'll list the important parts here:
    
        FontName: This is the friendly name of the font (as opposed to the file name) you can find in the fonts control panel item in your operating system. 
        Size: The size in points the font should be imported at. This is the setting you should tune until you can use the font in your application without using scaling. If you need the same font at different sizes, you should create multiple sprite fonts with this value set to the required values. 
        Style: Allows to use the common font styles like "Regular", "Bold", "Italic" or the combination "Bold Italic". 
        DefaultCharacter: The character to use if you try to render a character that is not contained in the generated sprite font. The meaning of this setting becomes clear after we've looked at the character regions settings. 
        CharacterRegions: see below. 
    
    To understand the concept of character regions, you first need to understand two things: first of all, a font may contain a lot of characters. Especially Unicode fonts can easily contain several thousand characters. And second, each character takes up both storage space and memory when it is converted to and loaded as a texture, a lot more than in its original form. Imagine the waste and probably even problems you would run into if you would let XNA convert the whole font. To get an idea of what we are talking about here: Segoe UI, the font used in Windows Vista/7 and newer versions of Office, contains more than 2800 characters. Arial Unicode MS, a particular heavyweight distributed with earlier Office versions, apparently has almost 40,000 characters in it. For normal English text however, with both numbers and upper/lower case letters plus common special characters, you will barely need 100 of them. 
    To fix this problem, a sprite font only includes those characters which you specify in one or more character region definitions. The "Start" and "End" values of a region depict the first and last Unicode character codes to include in the font. Either specify the characters themselves directly, or their decimal values using the "&#" prefix like the sample above demonstrates. The standard file created for a new sprite font includes the region   to ~. All numbers lower than 128 are identical in Unicode and ASCII, so this means all characters between " " (space) and "~" are included by default (MSDN has a ASCII table you can use to look that up):
    
    If you need to include Unicode characters, make sure the font you want to use has those, and take a look at the code charts provided on Unicode.org to decide what regions you need. Please note that XNA's text rendering is somewhat limited in cases where characters are composed of multiple characters/glyphs, so you might run into problems with some languages.
    Important note on fonts: One important thing to note is that you cannot use any font that is installed on your computer in a game this way. Most fonts require special licenses to be distributed in such a form, and for some such a license might be very expensive or even not be available at all. XNA comes with a set of built-in fonts you can use without getting into trouble. Please check the "redist.txt" file that comes with Game Studio which lists a number of included fonts. For all other fonts you want to use, make sure you have an appropriate license that allows this. The path to the "redist.txt" file should be:
    
    %programfiles%\Microsoft Visual Studio 10.0\Common7\IDE\VPDExpress\1033\redist.txt
    
    Loading and using sprite fonts
    
    You load a sprite font like any other asset in your game by using a content manager. As we've learned in the last part, the game class already has a Content property (which actually is a content manager) we can use to do that. To try out the newly created font, change the LoadContent method of your game class in the following way. Also add a class field that holds the sprite font.
    
    
     SpriteFont sampleFont;
    
      
    
     ...
    
      
    
     protected override void LoadContent()
    
     {
    
         // Create a new SpriteBatch, which can be used to draw textures.
    
         spriteBatch = new SpriteBatch(GraphicsDevice);
    
      
    
         // TODO: use this.Content to load your game content here
    
         sampleFont = Content.Load("SampleFont");
    
     }
    
    
    Once loaded, it can easily be used in the draw method by utilizing the sprite batch. Remember that you have to call the Begin method first before you can start drawing with a sprite batch, and to call the End method when you're finished. 
    
    
     protected override void Draw(GameTime gameTime)
    
     {
    
         GraphicsDevice.Clear(Color.Black);
    
      
    
         // TODO: Add your drawing code here
    
         spriteBatch.Begin();
    
      
    
         spriteBatch.DrawString(sampleFont, // the sprite font to use for the rendering
    
             "Rendering text\r\nin XNA",    // the text to render, can contain line breaks
    
             Vector2.Zero,                  // the position of the text (in relation to the origin)
    
             Color.Green,                   // the text color
    
             0.0f,                          // the rotation angle (radians) 
    
             Vector2.Zero,                  // the origin of the sprite
    
             1.0f,                          // the scale factor, try to keep at or close to 1
    
             SpriteEffects.None,            // allows flipping
    
             0.0f);                         // a depth value for depth sorting
    
       
    
         spriteBatch.End();
    
      
    
         base.Draw(gameTime);
    
     }
    
    
    There are also alternate overloads with less arguments if you don't want or need to specify some of the values. The result is your first rendered text in XNA:
    
    
    Measuring text size
    One problem you will quickly run into is that you need to know the size some text will occupy on the screen. For example, you may want to render right-aligned or centered text, or your texts are dynamic with changing content (think player score, game time etc.) and you want to compensate for that. Luckily, the sprite font class has a method named "MeasureString" that exactly does that. In fact, it's the only method it implements which is not inherited from object. MeasureString takes a string or string builder as argument and returns the size of the rendered text. Since all parameters like font size and font style are static and have been set at compile time when the sprite font was created, they are not of interest or required here. With that, centering a text is a matter of computing the position dependent on the render size (another possibility would be to work with a combination of position and sprite origin of course):
    
    
     protected override void Draw(GameTime gameTime)
    
     {
    
         GraphicsDevice.Clear(Color.Black);
    
      
    
         // TODO: Add your drawing code here
    
      
    
         // calculate the text position
    
         string myText = "Some centered text!";
    
         Vector2 myTextSize = sampleFont.MeasureString(myText);
    
         Vector2 myTextPosition = new Vector2(graphics.GraphicsDevice.Viewport.Width / 2.0f - myTextSize.X / 2.0f, 
    
                                              graphics.GraphicsDevice.Viewport.Height / 2.0f - myTextSize.Y / 2.0f);
    
      
    
         // draw the text
    
         spriteBatch.Begin();
    
         spriteBatch.DrawString(sampleFont, // the sprite font to use for the rendering
    
             myText,                        // the text to render, can contain line breaks
    
             myTextPosition,                // the position of the text (in relation to the origin)
    
             Color.Green,                   // the text color
    
             0.0f,                          // the rotation angle (radians) 
    
             Vector2.Zero,                  // the origin of the sprite
    
             1.0f,                          // the scale factor, try to keep at or close to 1
    
             SpriteEffects.None,            // allows flipping
    
             0.0f);                         // a depth value for depth sorting 
    
         spriteBatch.End();
    
      
    
         base.Draw(gameTime);
    
     }
    
    
    
    This is the basis for all text rendering you will do in XNA. As I said in the beginning, you use this not only for in-game text, but also for your menus, high score lists, about screens and instructions, simply put: whenever you need text. 
    Advanced font rendering/bitmap fonts
    In the beginning, we have seen Silverlight text that uses gradients, and I've talked about other possibilities in Silverlight like using image brushes to create very unique text. In XNA, this is not supported when it comes to dynamically creating those effects. However, since characters are images in XNA, you can use all the possibilities you have with image manipulation and design to make your fonts more unique. However, this requires that you don't use the default import process of sprite fonts. Instead, you use a feature called bitmap fonts. 
    Bitmap fonts are nothing but images of characters which you create yourself (as opposed to let them create automatically). Then, instead of using the sprite font importer and processor in your XNA content project, you import the image you've created by setting the importer to "Texture" (because it's really a texture you're importing) and the processor to "Sprite Font Texture". The result after the import process is the same however. You load a bitmap font as sprite font object and use it exactly like you would use a sprite font created the way we just did.
    
    To make a bitmap font work, your image needs to look like this (this image was taken and enhanced to actually work from the MSDN explanation of this feature):
    
    There are several conventions and restriction your image has to follow:
    
        The upper left character has to match the "First Character" property in the properties window above (in this case it's the space character which also is the default). 
        From there, the runtime expects the following characters left to right and top to bottom, which means if you start with space, the next character has to be an exclamation mark, the third one quotes etc. You cannot skip characters. If you need to provide different ranges, you need to write a custom font processor for the content pipeline that matches indexes to characters as described on the above linked MSDN page. 
        For monochrome fonts (where you add the tint in the draw method of the sprite batch like we did), you are supposed to work with grayscale images. Black means transparent and white full solid. If you want to use colors like the example above does for the digits, you need to provide transparency in the alpha channel of the image instead. 
        You need to fill the space between the characters with a magenta color (ff00ff) or you will receive compilation errors, because the processor needs that color to distinguish the individual characters. Don't worry about wasting space, the characters will be packed as tightly as possible during the import process, so you can set the spacing to a value that allows comfortable working. 
    
    When you're using bitmap fonts, you can design each individual character as you want. You can for example apply effects and distortions your graphic program offers, or even draw the characters by hand. Obviously though, creating such an image manually is tedious work. Most people therefore use some sort of generator that at least creates the basic image from an existing font and work from there. Microsoft has published such a tool too, but unfortunately it doesn't work correctly with XNA 4.0 yet.
    A word on "Mango"
    With the first major update of the Windows Phone 7 platform (code name "Mango") it is possible to mix Silverlight and XNA content not only in the same application, but also on the same page. If you make use of this new possibility, you are able to have the very advanced and comfortable Silverlight text rendering features in your XNA game too. With little effort you can use normal Silverlight text blocks with all their styling possibilities and other advantages mentioned in this article and display them together with your XNA rendered content. Part 12 of this series shows how to do that, and even how to make use of Silverlight's animation features in combination with this.
    
    Summary
    In this article we've learned the differences between text rendering in Silverlight and XNA. We've seen that importing a font into XNA and use it for text output is not that hard if you follow some basic rules, but it's also clear that if nicer fonts and design effects are required, things can quickly become time-consuming. 
    You can download the source code of the sample here. It also includes the bitmap font part, but please note that I've used the above sample image taken from the MSDN article. It doesn't have an alpha channel, so the colored digits will only display as gray scale or tinted in one color.
    Download source code
    As always, feel free to leave any comments and feedback, and of course also suggestions what can be improved or what you want to see in future episodes.
    About the Author
    Peter Kuhn aka "Mister Goodcat" has been working in the IT industry for more than ten years. After being a project lead and technical director for several years, developing database and device controlling applications in the field of medical software and bioinformatics as well as for knowledge management solutions, he founded his own business in 2010. Starting in 2001 he jumped onto the .NET wagon very early, and has also used Silverlight for business application development since version 2. Today he uses Silverlight, .NET and ASP.NET as his preferred development platforms and offers training and consulting around these technologies and general software design and development process questions.
    He created his first game at the age of 11 on the Commodore 64 of his father and has finished several hobby and also commercial game projects since then. His last commercial project was the development of Painkiller:Resurrection, a game published in late 2009, which he supervised and contributed to as technical director in his free time. You can find his tech blog here: http://www.pitorque.de/MisterGoodcat/


A classic memory game: Part 2 - The game logic, connecting the ViewModel and the View
editorial@silverlightshow.net (Levente Mihály ) — Fri, 21 Jan 2011 09:54:00 GMT
This article is compatible with the latest version of Silverlight.

Don't miss...

    XNA for SL developers series 
    Pro Game Design with SL4 book: 

          
             Show more books

This article is Part 2 of “A classic memory game”.
The series is about building the following classic memory game in Silverlight, and porting it to Windows Phone 7. In the first article we started a new MVVM Light project, created the controls and designed the game-states. Now it’s time to put some code behind the game, and finish it.
Here’s the game itself and you can download the source code here.

The Game Logic
MVVM Light template

The MVVM Light project template contains a ViewModelLocator and a MainViewModel in the ViewModel folder. The ViewModelLocator’s job is to hold a reference of the ViewModels and to create them when needed. In the App.xaml there’s an instance of the ViewModelLocator, so the Views can bind to the ViewModel via this instance. 
App.xaml:


<Application.Resources>

   <ResourceDictionary>

    <vm:MemoryViewModelLocator x:Key="Locator"

        d:IsDataSource="True" />

   ResourceDictionary>

Application.Resources>


MainPage.xaml:


<UserControl.DataContext>

   <Binding Path="Main" Source="{StaticResource Locator}"/>

UserControl.DataContext>


Model
To represent the cards, we have a MemoryCard class with the following properties:

    the ID specifies which image is on the card 
    the Upside property indicates if a card is showing it’s face or back 
    the Solved property is set true once the card and its pair are found 

The MemoryCard class implements the INotifyPropertyChanged interface. Classes that implement this interface must have an event delegate PropertyChangedEventHandler. Raising this event enables the View (that’s the MainPage.xaml) to track changes. So we need to raise this event when setting the Upside and the Solved properties. The ID won’t change in a MemoryCard’s lifetime so we don’t need to do anything there.
Here’s the Upside property and the raisePropertyChanged method.


/// 

/// The  property's name.

/// 

public const string UpsidePropertyName = "Upside";

 

private bool _upside = false;

 

/// 

/// Gets the Upside property.

/// Changes to that property's value raise the PropertyChanged event. 

/// 

public bool Upside

{

  get

  {

   return _upside;

  }

 

  set

  {

   if (_upside == value)

   {

     return;

   }

  _upside = value;

 

  // Update bindings, no broadcast

  raisePropertyChanged(UpsidePropertyName);

 }

}




public event PropertyChangedEventHandler PropertyChanged;

 

private void raisePropertyChanged(string propertyName)

{

    if (PropertyChanged != null)

    {

        this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

    }

}


 
The game logic
The logic is simple. In the MainViewModel’s constructor we’re setting up two timers (DispatcherTimers), one to turn back cards after a while and one for tracking the elapsed time. In the Start method we load the selected number of cards (based on the difficulty) and reset the score and start the elapsed timer.
We have a few properties to store the state of the game. The most important one is the list of the cards (MemoryCardList). The MainViewModel derives from BaseViewModel that means we don’t have to explicitly implement the INotifyPropertyChanged interface because it’s already implemented in the base class as well as the RaisePropertyChanged method.
Here’s the LoadCards method:


public void LoadCards()

{

    int cardCount = 0;

    switch (Difficulty)

    {

        case Difficulties.Easy:

            cardCount = 8;

            CardSize = 100;

            break;

        case Difficulties.Normal:

            cardCount = 10;

            CardSize = 78;

            break;

        case Difficulties.Hard:

            cardCount = 15;

            CardSize = 62;

            break;                

    }            

 

    // clear

    MemoryCardList.Clear();

 

    // add cards

    for (int i = 0; i < cardCount; i++)

    {

        MemoryCardList.Add(new MemoryCard(i)

        {

            Upside = false

        });

        MemoryCardList.Add(new MemoryCard(i)

        {

            Upside = false

        });

    }

 

    // shuffle them

    var rand = new Random();

    for (int i = MemoryCardList.Count - 1; i > 0; i--)

    {

        int n = rand.Next(i+1);

        var temp = MemoryCardList[i];

        MemoryCardList[i] = MemoryCardList[n];

        MemoryCardList[n] = temp;

    }

 

    IsGameEnded = false;

}


Note that we are adding two cards with the same ID at a time in the loop so we can pair them. After adding the cards we shuffle them. One last thing to explain: the CardSize specifies the actual size (width and height) of the cards in the View as we have smaller cards when there more. Keeping the CardSize in the ViewModel is not very elegant, it should belong to the View, I’ll probably refactor it.
The heart of the game is the OnSelectionChanged method. First we count the upside cards, if it’s two (which is actually one plus the newly flipped) we compare the IDs. If there’s a match they are solved. We have to check if there are any unsolved cards there to track the end of the game. If two cards are already upside showing their front, the newly selected would be the third card to show it’s front, so we have to flip back everything. Here’s the code:


public void OnSelectionChanged(MemoryCard lastCard)

{

    int upsideNo = MemoryCardList.Count((m) => m.Upside);            

    if (upsideNo == 1)

    {

        // one is upside + lastCard is 2, check IDs

        MoveCounter++;

        var upsideCard = MemoryCardList.First((m) => m.Upside);

        if (upsideCard.ID == lastCard.ID)

        {

            if (MemoryCardList.Count((m) => !m.Solved) == 2)

            {

                _elapsedTimer.Stop();

                EndGame();

            }   

            upsideCard.SetSolved();

            lastCard.SetSolved();

            PairCounter++;                                     

            return;

        }

 

        if (!_timer.IsEnabled)

        {

            _timer.Start();

        }

    }                

    else if (upsideNo == 2)

    {

        // two is already upside, hide them, lastCard will be the only upside

        _timer.Stop();

        hideCards();

    }            

}


 
Connecting the ViewModel and the View
After building the project the MainViewModel properties should show up in Blend’s databinding windows. We bind the MemoryCardList to the ListBox’s ItemSource. Click on the little square next to the ItemSource, choose DataBinding and select the MemoryCardList in the DataContext tab.

Now the ListBox will always display the cards in the ViewModel’s MemoryCardList property.
Converters
Blend’s databinding window shows only the compatible types by default. That means for example an IsVisible property type of bool won’t show up (by default) when you try to bind it to any element’s Visibility property, because the Visibility is type of a Visibility enum. Here enters the IValueConverter interface. When you build a class implementing this interface, you can pass it to the binding to have the data converted to compatible type.
A classic example is the VisiblityConverter for the Solved property (so it’s working the opposite way), note that only one way is implemented, we won’t need the ConvertBack:


public class VisibilityConverter : IValueConverter

{

 

    #region IValueConverter Members

 

    public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

    {

        if (value == null) return Visibility.Visible;

 

        if ((bool)value) return Visibility.Collapsed;

        else return Visibility.Visible;

    }

 

    public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

    {

        throw new NotImplementedException();

    }

 

    #endregion

}


After build, you can set it up in Blend for the MemoryCard’s Solved property. Edit the CardList’s ItemTemplate, select the ToggleButton and bind the Visibility property:
Switch to all properties, select the Solved property, open the dropdown at the bottom of the window, and select the VisibilityConverter as Value converter.

You can bind the Checked property to the Upside property without a converter, because both of them are a type of bool.
Sometimes we need the ValueConverter in both ways, and sometimes we need additional parameters. To set the difficulty I needed both. There is a RadioButton for each difficulty, and we have one Difficulty property in the ViewModel type of an enum. So to make it work I needed to pass which RadioButton is the target. Here’s the code for the DifficultyConverter:


public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

{

    if (System.Convert.ToString(value).Equals(System.Convert.ToString(parameter)))

    {

        return true;

    }

    return false;

}

 

public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

{

    if (System.Convert.ToBoolean(value))

    {

        return Enum.Parse(typeof(Difficulties), System.Convert.ToString(parameter), true);

    }

    return null;

}


And here’s the Binding for the Easy difficulty to the button’s Checked property:

Another converter was needed for displaying the images based on the ID. The ImageConverter takes the ID and converts it to an ImageSource by resolving a naming convention.
Formatting text
Converters are often used to format text, for example converting a number to string in a desired format. Silverlight 4 however introduced the StringFormat extension. Unfortunately I couldn’t find any Blend support here, so we have to dive into code to make it working. The following code formats the move counter to a 2-digit style:

You can find a good summary about StringFormat on DesignerSilverlight.
CallDatacontextMethodAction
We have to connect not just the data in the ViewModel to the View, but user-actions too. The standard way for the View to notify the ViewModel that something is happened is by commands. A simpler and more designer friendly approach is the CallDatacontextMethodAction behavior by András Velvárt. You might have already read the article about it: A Designer-friendly Approach to MVVM.
After adding it to the project and building it we can add it to our Start button to call the Start method on the ViewModel.
    

Delaying an action
For the MemoryCard I had to delay the effect of setting the Solved property to true. What happened is by setting the card to solved it immediately disappeared, even before the control would arrive to the Checked state. This was clearly not okay, the player couldn’t see the card before it was marked as solved and disappeared.  That’s why I introduced the SetSolved method that starts a timer and only after 1.5 seconds sets the Solved property to true thus making the card disappear.
The Messenger class
The ViewModel sends a signal to the View once all of the cards are collected by using MVVM Light Messenger class. The View then moves into the EndState:


Messenger.Default.Register<string>(this, (msg) =>

{

    if (Constants.EndGameMessage == msg)

    {                        

        VisualStateManager.GoToState(this, EndState.Name, true);

    }

});


 
The Messenger is used in the MemoryCard class as well. When the card is flipped it notifies the MainViewModel and that is when the OnSelectionChanged method runs, which is the heart of the game.
Summary
In this article we inspected the development aspects of a game leveraging on MVVM using bindings, visual states, transitions and behaviors. Expression Blend turned out to be a really powerful tool as for the whole game we needed only little coding.
In the final article of the series I will port this game to Windows Phone 7, exploring performance optimizations, phone-specific UI, and tombstoning. Don’t hesitate to drop a comment if you have questions or want to see something specific in the next article.
About the Author
My name is Levente Mihaly. I've entered the .NET world in 2006, and after graduating at Budapest University of Technology (Msc in Computer Science) I started working as a .NET software developer. After meeting technologies like WinForms and ASP.NET, Silverlight quickly became my favourite platform from the early Silverlight 2 beta stages. I was always interested in mobile development and now I'm very happy since with Windows Phone 7 I can easily expand my knowledge to the mobile world. Nowadays beside following Silverlight I'm focusing on WP7 in my free time. I'm also the runner-up of the 2010 Silverlight ecoContest. You can reach me on twitter (@leventemihaly). 

 


A classic memory game: Part 1 - Designing the game
editorial@silverlightshow.net (Levente Mihály ) — Thu, 20 Jan 2011 10:00:00 GMT
This article is compatible with the latest version of Silverlight.

Don't miss...

    XNA for SL developers series 
    Pro Game Design with SL4 book: 

          
             Show more books

This article is Part 1 of “A classic memory game”.
Introduction
My wife has started learning Silverlight and because of my Expression Blend skills are still lacking, we have decided to build the following classic memory game so both of us can learn something new. We kept things simple but we respected basic Silverlight principles. That’s why we used MVVM which might sound an overkill for a simple game but you’ll see that it fits together perfectly. 
Nowadays everything revolves around Windows Phone 7 in the Silverlight world and I am not an exception either. Once I got my phone I quickly ported the game over to WP7 to see that with a few modifications it’s running nicely. 
In this first article I will go around the game’s concepts, designing the controls and the main game-states. In the second article I’ll finish building the game by adding the necessary code and connecting it with the View. The third part will be about porting the Silverlight game to Windows Phone 7.
First things first, here’s the game itself and download link for the source code.

 
Step 0. – creating a new MVVM Light project
For the project we have used my personal favorite and probably the most popular lightweight MVVM framework out there: Laurent  Bugnion’s MVVM Light toolkit. If you haven’t already installed it, you can do it from here: http://www.galasoft.ch/mvvm/installing/manually/
After installing and copying the Blend template in its place, two new ‘New Project’ templates should appear in the Silverlight department:

Of course you can add the MVVM Light toolkit bits later to the project as well, but it is very nice to have a template for an easy start. It’s also important to note that the MVVM Light toolkit is available for Silverlight 3, Silverlight 4, WPF3.5, WPF4 and Windows Phone 7.
Creating a custom ToggleButton Style – the Card
After drawing the different cards, the back of the cards,  and saving them as images, our first step was to create a custom control for the cards. 
In Blend put a Grid in the LayoutRoot and put two Images inside this Grid. One will represent the back of the card, the other will be the front. Right click on the Grid and choose Make into Control..

In the upcoming panel find the ToggleButton control and add the name CardToggleButtonStyle. Select a separate resource file (you may have to create a new one) to define the style in to keep the MainPage.xaml clean.

Delete the ContentPresenter, so you will end up something like this:

Notice the States panel, especially the CheckStates state-group. Every ToggleButton has a checked and unchecked state and we will use these two states to switch between our card’s front and back. So select the Unchecked state and change the front image’s Visibility to Collapsed. Then select the Checked state and do the same with the back image.
Now if you run the application you should be able to switch between the back and front of the card by clicking on it. Let’s add the turning-animation to the switching to make it look better! 
Select the Unchecked state and add a transition to Checked state (1). A good length for the animation is 0.3 secs (2). By selecting the newly created transition we can edit its animation. Forward to 0.2 sec in the timeline, select the front image (3) and click the Record Keyframe button (4). Do this for the back image too (3,4). Set up a 90 degrees Y rotation in the Projection panel for the front image, and a –90 for the back (5). (Don’t worry when Blend automatically overrides the 90 degrees to 89...) Change the Visibility of the images, the front was Collapsed, change it to Visible. The back was Visible, change it to Collapsed (6). Now forward to the 0.3 sec mark and change the front images Y rotation to 0 (7). Now when you press the play button, you should see the card turning from one side to the other.

You’ll have to create the opposite of this animation in the Checked->Unchecked transition.
The cards will be flipped back when a certain time elapsed or a third card is about to turn. That means the logic is responsible for this task not the player. So in the Checked state set the IsHitTestVisible to false. At first I didn’t do this and had this bug where the user could turn back and forth a card without the MoveCounter increasing.
Designing the layout – Creating a WrapListBox
So we have the card control, now we need to place them. The memory game shouts for a WrapPanel, you’ll find that in the Silverlight toolkit. But we wanted a more dynamic solution, having different number of cards for each difficulty. That’s why we used a WrapListBox, a ListBox with WrapPanel’s layout. Here’s how to do it:
Drop a ListBox in the Layout Grid, right click on it and choose Edit Additional Templates –> Edit Layout of Items (ItemsPanel) –> Create Empty..

Give it a name (WrapItemsTemplate) and again place the template in the separate resource dictionary to keep the main xaml clean. The ItemsPanel is responsible for the layout of the ListBox’s items. Here you can override the ListBox’s default layout (which is a StackPanel) and do anything you want. Just check out Bea Stollnitz’s famous solar system example.
We’ll need only a simple WrapPanel now. Delete the default StackPanel and replace it with the WrapPanel (you’ll need the Silverlight toolkit).

Trying it by placing a few Cards inside you’ll see that it doesn’t do exactly what we wanted. The problem is the ScrollViewer.

The quickest solution is to remove it from the ListBox’s template (we wouldn’t want the user to scroll for flipping cards).
Right click on the ListBox, select Edit Template and Edit a Copy.. After giving it a name (MemoryListBoxStyle) and placing it in the separate resource dictionary, move up the ItemsPresenter into the Grid, and delete the unneeded parts: the Border, the ScrollViewer and the ValidationErrorElement. The ItemsPresenter defines where the ItemsPanel (that’s our WrapPanel) is added inside the ListBox template. So we will need just that.

Much better:

Designing the layout – Menu and VisualStates
The game has three main stages: choosing a difficulty (start), playing, score (end). VisualStates are useful not just in (Custom) Control level, but in UserControl level as well. I’ve added three VisualStates to the LayoutRoot after building the menu items.

All the menus are Grids with a rounded Rectangle inside them. The Buttons use a custom style containing a rounded Rectangle and the ContentPresenter. 
The template of the RadioButtons are the ContentPresenter and two Rectangles. One Rectangle behaves as a highlight border, because it doesn’t fill and is visible only when in Checked state.
For the states first we need to add a VisualStateGroup, select the LayoutRoot, switch to the States panel, and add a VisualStateGroup. Now we can add our three states and of course we won’t miss adding transitions as well. The result looks like this:

Note that you can add Easing to transitions (highlighted too) to make a more realistic animation. For example in my case I have an ElasticInOut Easing on the MenuState –> GameState transition.
Switching States using the GoToStateAction behavior
A great and straightforward way to change between states is the GoToStateAction behavior. With this behavior we can easily set up the initial state, the GameState, and the switching from EndState to MenuState. What we can’t do with it, is the switch from GameState to EndState because it’s not trivial, it’s decided by the game logic. So let’s do the trivial ones:
Switch to the Assets panel and find the GoToStateAction behavior in the Behaviors. Put the behavior inside the LayoutRoot and select Loaded for EventName and MenuState for State. Don’t forget to check the UseTransitions box.
  
To switch from MenuState to GameState place another GoToStateAction behavior inside the start button, EventName is Click, StateName is GameState. Put the final behavior inside the new game button to make the switch from EndState to MenuState again (StateName is MenuState).
Summary
In this article we started designing a game, our main tool was Expression Blend. We’ve created a custom control for the Cards, a WrapListBox for laying out them, and we set up the three main states of the game. All of these parts are real, working elements.
In the next part we will put some logic behind the game and connect it with the View, using converters, the CallDatacontextMethodAction behavior and others. We will again rely heavily on Blend.
About the Author
My name is Levente Mihaly. I've entered the .NET world in 2006, and after graduating at Budapest University of Technology (Msc in Computer Science) I started working as a .NET software developer. After meeting technologies like WinForms and ASP.NET, Silverlight quickly became my favourite platform from the early Silverlight 2 beta stages. I was always interested in mobile development and now I'm very happy since with Windows Phone 7 I can easily expand my knowledge to the mobile world. Nowadays beside following Silverlight I'm focusing on WP7 in my free time. I'm also the runner-up of the 2010 Silverlight ecoContest. You can reach me on twitter (@leventemihaly). 

 


XNA for Silverlight developers: Part 1 - Fundamentals
editorial@silverlightshow.net (Peter Kuhn ) — Tue, 18 Jan 2011 02:12:00 GMT
Are you interested in creating games for Windows Phone 7 but don't have XNA experience? 

Watch the recording of the recent intro webinar delivered by Peter Kuhn 'XNA for Windows Phone 7'.



Don't miss...

    What is Windows Phone series 
    XNA article by Levente Mihály 
    WP7 series by Andrea Boschin 
    The XNA series is now available as a fully offline resource 


     All SilverlightShow Ebooks 

This article is Part 1 of the series “XNA for Silverlight developers”. 
This article is compatible with Windows Phone "Mango". 

Latest update: Aug 1, 2011.
For Silverlight developers who want to delve into XNA, the hard part is not learning the new set of classes in the library, but the fundamental difference in programming style for some parts of XNA compared to Silverlight. Especially when you have no experience in game programming, you might find some things confusing or even illogical. In the first part of this article, I want to give an overview and explanation of the biggest differences. You will run across all these topics again in the following articles in more detail. 
Later on, we finally start with some actual code and analyze the structure of an XNA project. We will learn about the concept of content and how to add it to your project. By the end of the article, we will have built a very simple "Hallo World" game that renders some moving content onto the screen. The source code for the sample project can be found at the end of the article.


Some Theory
Event-driven vs. Polling
In Silverlight, when you are interested in any kind of data or information, the common way to get it is to subscribe to some sort of event (I also count callbacks and similar constructs to that). No matter if it is user actions you want to be notified about, the arrival of data from a returning asynchronous operation, or other situations that require transportation of information: the runtime, third party components, or even objects you have written yourself send you a notification whenever the data you have asked for is available. That also works the other way round. If you want to notify someone else that something interesting has happened, for example signal to a UI component that your data has changed, you raise events. We've all gotten used to interfaces like INotifyPropertyChanged, do we?
This picture is quite different in XNA. A lot of work there is done using polling. For example, instead of being notified by an event that the user has touched the screen, you actively keep asking the screen if something interesting happened since your last call. Like on that long trip in the car, when your kids in the back seat keep asking "are we there yet"; with XNA, you are the kids, and you ask 30 times a second.

You may ask yourself why one would voluntarily use polling when there's so much comfort in using events. The answer is simple: to have full control about the processing of that information and data. One drawback of the event-driven model is that events may happen any time. This is a problem in Silverlight applications too, but we have learned to live with it and work around it. For example, let's say you have a button that kicks off a long-running operation. Nobody stops the user from hitting that button twice or three times in a row. If you want to prevent multiple operations from being started, then what you do is ignore subsequent events, or disable the involved UI elements so they do not generate those events anymore. With a polling based model, you simply wouldn't ask anymore. Also, more reasons for and benefits of that approach will become apparent once you learn more details about XNA. Especially user actions could corrupt your data if they happened e.g. between update and drawing operations. 
I don't say XNA doesn't have events, and I also don't say XNA doesn't use events. When you create an empty project and inspect the involved classes, as we will in just a few minutes, you'll realize that events are in fact used, for example to cope with system notifications (e.g. when the user has hit a hardware button and your game is suspended or similar things). In a lot of situations, you might want to use events in your own programming logic and game structure too, simply because the alternative often means to clutter your code with loads of flags and statements that check those flags (think complexity of a state machine). I'll try to point out those situations as we go. 
Drawing Content (aka "The Groundhog Day Effect")
When you want to make something visible on the screen in Silverlight, you simply add it to the visual tree in a "fire and forget" manner. That means that once added, the runtime will take care of it and draw it for you whenever it is necessary. You don't have to do anything for that, and the element stays visible until you remove it or a parent element from the visual tree (or explicitly set its visibility so it is not drawn, of course).
With XNA, this is very different. A good way is to imagine it as a flip-book. You can draw something nice on the current frame, but as soon as you turn the page to the next frame, you have to start all over again, with a blank piece of paper. In XNA, there is no automatism that tracks and re-draws objects on the screen for you. In every single render frame you have to draw the whole content that should be visible on the screen from scratch, you always start with that "blank piece of paper". In Silverlight there is also a lot of optimization going on to determine which parts of the screen actually need to be re-drawn. You can easily use the EnableRedrawRegions property to turn on a visual demonstration of that concept. In XNA, there's nothing like that. You simply draw the whole screen all the time, 30 times a second (30 is the default target frames per second setting on the Windows Phone platform).

The Game Loop
The central part of each game, the heartbeat if you will, is the game loop. To many modern programmers who have spent a lot of time to adopt the principles of object-oriented programming, having an uber-loop that drives the whole application from a central place seems like an awkward idea. Of course those of you with deeper knowledge or a background of Windows programming know the truth, which manifests itself in what is known as the message pump; but this is way beyond the scope of this article. Let's just agree on the fact that as a Silverlight developer, you won't see anything comparable to the game loop of XNA in your applications, ever. The simplest form of a game loop in pseudo code looks like this:


 while (IsRunning)

 {

   Update();

   Draw();

 }


In fact, this is what actually happens. XNA only adds more functionality to that to make the whole concept more robust (like accommodate for timing and/or performance problems) and to provide the developer with additional information and data. We'll take a closer look at it shortly. 
Having such a game loop often requires a different style of thinking in your programming, which is a problem for a lot of developers who start with game programming. As an application developer, you are used to write methods that complete a task by sequentially performing all the required steps. For example, when you want to copy some files, you would create a method that iterates over all the provided file names and call File.Copy() on each one of them. If you follow good practices and want to avoid that these operations freeze your UI, you move them to a background thread, but your code still would execute all the steps sequentially. In XNA, a lot of operations are not performed like that. In each iteration of the game loop, you only perform a tiny step that works towards the final result and then you stop until the next update. In the mentioned sample, that would mean that you would only copy a small part of one file, and then stop and return control to the runtime. In the next iteration, you'd resume your operation, copy another small part, and stop again etc.
Of course you won't find yourself copying a lot of files in XNA. A better example for this approach are animations, something we'll closely look at in a later part of the series. I've often seen that beginners create a "loop within the loop" and try to perform the logic of the whole animation within a single frame – which of course results in no visual effect at all. Instead, you need to learn these "baby steps" that require only tiny progress updates for the current frame, but sum up to the overall result you want to achieve in the long run. An interesting detail is that Silverlight's built-in animation system has to do exactly the same behind the scenes. Of course those details are hidden from the developer and the runtime does all that logic in this case; you only control those animations by simply setting some properties.

Your First XNA Project
After all this theoretical introduction you're probably eager to start with some code, so we'll finally dive into the real stuff now. After you've downloaded and installed the required tools for developing games for Windows Phone 7 (you can find them as web installer here) you can create your first game project in Visual Studio/Game Studio:

As you can see there are only two templates for Windows Phone, one for a game, and a second one for a class library. For now, select the game template, enter a name and hit the OK button. The following screenshot shows the structure of your solution after Visual Studio has prepared everything:

The first thing to note is that actually two projects have been created. The game itself is the first one in solution explorer, but below that there's a second entry for the content project. As you can see the game project references the content project using a "Content Reference". Visual Studio has also added some default references to common assemblies, like parts of the XNA library used for rendering and input in the game project, and various importers in the content project.
The Content Project
A full discussion of the XNA content pipeline is far beyond the scope of this article; however, you need to understand some of the basics and reasons how and why content in XNA games is separated from the actual game. "Content" is everything in your game project that is not executable code. Among game developers, the more common term for this kind of content probably is "assets". Your game assets include all graphics and related things (like textures, but also effects, 3D models and even fonts), audio (music, sound effects) and also other accompanying content, for example level data files or similar.
So instead of adding these assets to your game project, you add them to the content project. Let's just do that and add an existing image. Right-click the content project and select "Add/Existing item...". Browse to some image file on your hard disk and import it. You can also safe the following image file to your hard disk and use it, or download the source code at the end of the article:

For a better understanding of what happens with this imported image, select it and take a look at the properties window of Visual Studio:

Your assets are handled in a two-stage process. First they are read by an importer that knows how to treat that particular input format and transform it into a unified intermediate format. That means that no matter if e.g. your input image is a JPG or PNG, after the import process it will be available in the content pipeline as the same representation for further processing. The second step is a content processor that transforms the imported asset into the final, compiled format that is later used in the game. This separation adds a lot of flexibility to the overall process. For example, a sound file can be both processed into a sound effect as well as a song (we'll learn the difference between those two in a later part). Importing the file always is the same and can be done by the same importer in both cases. However, the final transformation requires two different processors.

For most file types, the required helpers for the content processing are detected automatically, but you can always override these. Of course you can also extend the content pipeline with your own importers and processors, to add the ability to use non-standard formats, or to create custom formats which you can use directly in your game later. We will briefly see how that works in a later part.
Reasons for the Content Pipeline
Why do we have this separation in place for XNA games, when we simply could add the images as resources or content to the game project itself? In fact, even a newly created game project (see above) already has some images added to it for the background and the game thumbnail! The main reason the assets are processed separately is (as often) improved performance. An important detail of the content pipeline is that the assets are imported and transformed at compile time. This means that when you build your solution, all your assets are processed and transformed into managed objects. Loading and handling of these objects at runtime then can be performed very fast, as they will always have the same format. Imagine the game needed to load different image formats at runtime. Not only may importing some formats (that use a more sophisticated compression, for example) be much slower than others, there might also be several sub-formats or encoding differences that add more complexity to the process even when you apparently use the same format for all resources.
Of course another reason is that you have more flexibility what programs you can use to generate your assets. The content pipeline supports the most common formats out of the box; for example, it doesn't matter if your images are BMPs, JPGs, PNGs, TGAs or in DDS format. All of those can be imported, which spares you the manual conversion or looking for suitable exporters for your graphics software. Some of these formats could not be used in the game project natively. The content pipeline also allows to perform additional steps automatically during the import, like creating multiple versions of a texture of different sizes ("mipmaps"), which otherwise you'd also have to do manually in an extra tool.
There have also been discussions about drawbacks of the content pipeline though. For example, by default XNA uses an uncompressed format for textures, which increases the size of your images significantly when the source files actually are compressed images like JPGs or PNG.s In turn, loading times may actually suffer. The texture content processor has the ability to compress images using the DXT format which can be activated in the properties window of an image. But then again this requires that your texture size is a power of two, which might not be the case and can result in additional (manual) work you need to perform to prepare your images, which kind of contradicts the idea of a smooth and comfortable import process.
The Game Project
After you've created the solution, the game project is already fully functional. You can simply hit F5 and it will start running and show an empty screen in cornflower blue. To this end Visual Studio uses the emulator that ships with the developer tools for Windows Phone:

This means the template already initializes everything in a way that there's already some visual experience, and theoretically you could start adding your own content and game logic right away. However, the initialization is not really complete. For example, when you take a closer look at the emulator you will realize that the game (which really only is a blue rectangle at the moment) doesn't occupy the whole screen; there's a black border around it. That is why we should take a look at some of the initialization options before we actually start adding our logic. 
An important note on the emulator: The emulator for Windows Phone 7 is great. It's not perfect, has its flaws, is missing some possibilities, and you might see some stuttering with games and similar glitches, but compared to previous emulators for Windows CE/Mobile my experience is that it's much better and faster in most areas, especially at startup and deployment of your projects. And it allows you to test your games easily without access to an actual device. However, please never publish a game to the market place without testing it on a real device first! The emulator actually is faster than real devices, and there are even some special cases with really huge differences. Some of these things will be emulated more accurately in the first major update of the platform ("Mango") and the corresponding development tools, for example the time it takes to check for trial mode. But there will still be huge differences regarding rendering performance even in this updated version, so please take this advice seriously. And of course it's always a good idea to use a real device to make sure your concepts (like input and the intended way of controlling your game) really work and feel right on actual hardware.
The Basic Setup 
Take a look at the source code of the Game1.cs file. Each XNA game derives from a built-in Game class that provides much of the required basic logic. One can say that with XNA, Microsoft has managed to neatly hide most of the difficult details required to set up a DirectX based game. When you're using DirectX in C++, or even in former attempts to bring DirectX to the managed world (Managed DirectX), you had and have to care about pesky details like acquiring and resetting lost devices and surfaces and other things, all of which is now handled for you behind the scenes. It really never has been easier to create games using this technology.
When you take a look at the constructor of the class, you see some of the initialization code:


 public Game1()

 {

     graphics = new GraphicsDeviceManager(this);

     Content.RootDirectory = "Content";

  

     // Frame rate is 30 fps by default for Windows Phone.

     TargetElapsedTime = TimeSpan.FromTicks(333333);            

 }


The graphics device manager does exactly what its name says, it manages the graphics device for you, and allows to manipulate various properties of that device through simple property values and methods. Three things you most likely want to configure here are full-screen mode, the supported screen orientation(s) and resolution. 
To support full-screen mode, you only need to set the corresponding property accordingly. The same is true for the supported screen orientations. This is a bit flag enum, which means you can combine multiple values to indicate that your game supports multiple screen orientations. In most cases though, implementing support for different orientations is complex, and sometimes doesn't even work without changing game mechanics, so it's totally valid to only support one orientation.
You should also set the back buffer dimensions, depending on the screen orientation. Think of the back buffer as the canvas you are drawing on; it is a direct representation of the screen, so usually its dimensions will be those of the device screen's native resolution (480x800 in portrait mode, or 800x480 in landscape mode). You can also render your game at smaller resolutions and make use of the built-in hardware scaler to zoom it to full screen size (it does that automatically). This will improve performance dramatically (at the cost of reduced visual quality), but it's usually not necessary, especially for simple games. Note the naming of these properties ("Preferred...") which indicates that your settings will automatically be discarded when you set it to non-supported values (e.g. values larger than what is supported by the device).


 public Game1()

 {

     graphics = new GraphicsDeviceManager(this);

     graphics.IsFullScreen = true;

     graphics.SupportedOrientations = DisplayOrientation.Portrait;

     graphics.PreferredBackBufferWidth = 480;

     graphics.PreferredBackBufferHeight = 800;

  

     Content.RootDirectory = "Content";

  

     // Frame rate is 30 fps by default for Windows Phone.

     TargetElapsedTime = TimeSpan.FromTicks(333333);            

 }


The Content property of the game class is a content manager instance that allows you to access the assets you have added in your content project. It's set up for you automatically (you can also use multiple instances of content managers, but in the beginning this will not be necessary), all you have to do is set the RootDirectory property value. You can structure your assets in the content project by creating folders (for example for the different asset types, or to group assets by level or similar). All content however is located below a (virtual) root directory. The name of that root directory is something that you can change in the properties of the content project. By default it is set to "Content" both in the content project and here in the constructor of the game class, so if you just leave it at that it will work without any additional changes. 

The last line of code in the constructor indirectly sets the desired frame rate you want to achieve by setting the target elapsed time. This is part of the sophistication I have talked about before, which is added to the game loop by XNA. What you basically say is that your game logic should be updated 30 times a second. XNA will try to adhere to this settings as good as possible. If your game is not very demanding (as in finishing an iteration of the game loop is faster than the target time), it will idle and wait for the next update to be triggered. On the other hand, if your game is complex or poorly optimized, the game loop may fall behind and not be able to provide 30 frames per second. In that case, the game will try to keep up by skipping drawing calls, and let your game logic update multiple times in succession (as drawing is way less important than updating your logic, which may break things if it doesn't happen as expected).
When your update and draw methods are called, XNA will provide you with some values, like the elapsed time since the last call. These values also include a property you can monitor to determine whether the game loop takes too long and XNA needs to skip frames to keep up (GameTime.IsRunningSlowly). You can fine-tune all these settings, but you should just keep them at default values for now.
The Game Methods
The rest of your game class contains the main methods you need to create a full game. The comments that have been added by the project template actually are pretty comprehensive and should give you an idea of the particular details.

    Initialize: Here you can add any initialization logic required by your game which is not related to graphics or your content. 
    LoadContent/UnloadContent: The LoadContent method is called whenever it is necessary to load your game assets. In these methods you make use of the content manager provided by your game to load textures, sounds and other required assets which you have added to your content project before. In the UnloadContent counterpart you can do some clean-up if necessary. Please note that the content manager cleans up any content managed through it automatically, so you don't need to take care of that separately. 
    Update: This is the place where you update all game logic. For example, it is here where you will take care of user input, performing animations, triggering sounds and handling general things like checking if the player has won or lost the game or updating your AI. By default, this method contains a check for the back button press which per certification requirement needs to exit the game if you're on the main screen. 
    Draw: Within this method, you draw all content that should be visible on the screen. This includes not only sprites like the player and enemies, or effects, but also things like background graphics, text, menu or message box overlays and similar things. 


Hallo World!
Let's use all we have learned so far to show the single texture we have imported into the content project on the screen. This will conclude our "Hallo World" project. 
Loading Content
First of all, we will use the LoadContent method to actually load the texture. To store it permanently, we'll also add a class field for it:


 Texture2D block;

  

 ...

  

 protected override void LoadContent()

 {

     // Create a new SpriteBatch, which can be used to draw textures.

     spriteBatch = new SpriteBatch(GraphicsDevice);

  

     // TODO: use this.Content to load your game content here

     block = Content.Load("Block");

 }


Simple, is it? You can use the Load method of a content manager to load assets from your compiled content. Simply pass in the name (including the relative path from the root directory, if you've chosen to put your assets into sub folders) and set the required generic type to the type of asset you want to load. In this case, we need to use Texture2D, as we want to load a normal two-dimensional image.
You can also see that in the LoadContent method, a SpriteBatch object is created, something we haven't talked about so far. The sprite batch is a helper class that is used to draw two-dimensional images and text on the screen. As the name implies it does that in a batch, which improves performance a lot. Will see how it works in a moment.
Updating the Logic
But first let's add some movement logic to our Hallo World game to make it a bit more interesting. For this, we use the Update method of the game class:


 Vector2 position;

 double angle;

  

 ...

  

 protected override void Update(GameTime gameTime)

 {

     // Allows the game to exit

     if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)

          this.Exit();

  

     // TODO: Add your update logic here

  

     // take the screen width

     var screenWidth = graphics.GraphicsDevice.Viewport.Width;

  

     // calculate the new rotation agle

     angle -= gameTime.ElapsedGameTime.TotalSeconds;

  

     // update the x and y coordinates

     position.X = (float)(screenWidth / 2.0 - block.Width / 2.0 + 200 * Math.Cos(angle));

     position.Y = (float)(screenWidth / 2.0 - block.Height / 2.0 + 200 * Math.Sin(angle));

   

     base.Update(gameTime);

 }


Positions are stored as vectors in XNA, which is why we need to add a class field of type Vector2 (a two-dimensional vector) for the position of the sprite. We also store the current rotation angle. In the Update method, we first fetch the actual screen width from the graphics device (more specifically from its view port). This value is identical to the value we have set as preferred back buffer width in the constructor of the game class.
The following lines update the rotation angle depending on the elapsed game time since the last call of the Update method and then calculate the x and y coordinates for a circular motion. This is the moment to remember the "baby steps" philosophy I have talked about in the beginning of the article. The Update method is called 30 times a second, which means that the gameTime.ElapsedGameTime property will be a very small time span (ideally 33.3 milliseconds). We need to adjust the motion values by similar very small values to create a smooth movement that is not too fast. To this end, we make the calculation dependent on that elapsed time value passed into the Update method. You will always see this approach for calculations, and over time you will become used to it. It's pretty easy to create the desired velocity for a movement with this. For example, let's say you want to move an object by 200 pixels a second, then you simply multiply that reference value (200 pixels/second) by the elapsed seconds since the last update (e.g. 0.033 seconds) and get the number of pixels you need to move the object in the current frame (6.67 pixels). In our example, we increase the angle by the elapsed seconds. Since a full rotation requires 2 * PI ~= 6.3 radians, this is the number of seconds the sprite needs to complete a circle.
Tip: It's a great idea to agree on one unit for all these calculations across your whole application. For example, if you use seconds in one part and milliseconds in other parts, things can easily become confusing when you need to connect both parts at a later point. I prefer to use seconds.

Output to the Screen
On to the Draw method! If you look at the draw method, you can see that it contains a single call to GraphicsDevice.Clear(), which takes a color as argument. That is where the cornflower blue comes from. Of course you can change that to anything you like. In addition, add the following code:


 protected override void Draw(GameTime gameTime)

 {

     GraphicsDevice.Clear(Color.DarkGoldenrod);

  

     // TODO: Add your drawing code here

     spriteBatch.Begin();

     spriteBatch.Draw(block, position, Color.Red);

     spriteBatch.End();

  

     base.Draw(gameTime);

 }


That is how you use the sprite batch. You tell it to begin a batch, queue up all drawing operations, and in the end call the End() method to have it process all the operations you have just added. For our simple project, we only have one thing to do: draw the block texture. The Draw method of the sprite batch has several overloads that let you resize or rotate the texture that should be drawn. You can also add a tint, which I did by setting the color argument to red. This is especially handy when you have several similar objects in your game that only are different in their color. You can then use a grey scale version of the texture and add the color here.
If you compile and run the project, you shouldn't receive any errors, and the result looks like this:

There you go, your first XNA project. I strongly encourage you to play with the different features we have learned today. Change the supported orientations, the back buffer resolution, the movement of the sprite, and make use of some of the overloads of the sprite batch draw method.
A word on "Mango"
What this article demonstrates stays valid for the first platform update (code name "Mango") without exceptions, if you are creating an XNA game. However, Mango offers new project types that mix XNA and Silverlight in the same application; this feature changes the basic setup and the way the update and draw logic is executed. If you are interested in these new possibilities and how to use them, please read part 12 of this series to learn more about it.
Summary
In this article we've learned some of the major differences in programming style between XNA and Silverlight. We have seen a few of those differences in the sample project, and finished by creating a small game application that already moves some content around the screen. You should also have developed an understanding for the concept of content and how content management in XNA works. You can download the full source code of the sample project here:
Download Source Code
This article was quite lengthy and covered a lot of the details we needed to finally get some tangible results; Hopefully it still was an interesting read for you and has whet some appetite for the things that will follow. Now that we have created a basis we can use to build upon, I will try to keep the next parts shorter so they can be digested a bit easier and make more of a lighter read. Feel free to leave any comments and feedback, and of course also suggestions what can be improved or what you want to see in future episodes.
About the Author
Peter Kuhn aka "Mister Goodcat" has been working in the IT industry for more than ten years. After being a project lead and technical director for several years, developing database and device controlling applications in the field of medical software and bioinformatics as well as for knowledge management solutions, he founded his own business in 2010. Starting in 2001 he jumped onto the .NET wagon very early, and has also used Silverlight for business application development since version 2. Today he uses Silverlight, .NET and ASP.NET as his preferred development platforms and offers training and consulting around these technologies and general software design and development process questions.
He created his first game at the age of 11 on the Commodore 64 of his father and has finished several hobby and also commercial game projects since then. His last commercial project was the development of Painkiller:Resurrection, a game published in late 2009, which he supervised and contributed to as technical director in his free time. You can find his tech blog here: http://www.pitorque.de/MisterGoodcat/


XNA for Silverlight developers: Part 0 - Why should I care?
editorial@silverlightshow.net (Peter Kuhn ) — Mon, 10 Jan 2011 10:29:00 GMT
Are you interested in creating games for Windows Phone 7 but don't have XNA experience? 

Watch the recording of the recent intro webinar delivered by Peter Kuhn 'XNA for Windows Phone 7'.



Don't miss...

    What is Windows Phone series 
    XNA article by Levente Mihály 
    WP7 series by Andrea Boschin 
    The XNA series is now available as a fully offline resource 


     All SilverlightShow Ebooks 

This article is Part 0 of the series “XNA for Silverlight developers”.
This article is compatible with Windows Phone "Mango". 

Latest update: Aug 1, 2011.
Introduction
Around the time the first Windows Phone 7 devices were released to the market, one popular sentence you heard was "every Silverlight developer is a Windows Phone 7 developer" – and that's true. Silverlight is Microsoft's main platform to do Windows Phone 7 development, and every desktop Silverlight programmer will feel comfortable in the new mobile programming environment instantly. Sure there are differences and libraries specific to the devices, but you won't have to learn a new programming language or new ways to define your UI, and you can use the same development environment you've been using for normal Silverlight development all the time. That's great!
However, Silverlight is not the only possibility to create software for Windows Phone 7 devices, there's also XNA. Most people that are interested in developing for the new mobile platform probably have already read about it, mostly in the context of game programming. This article tries to give a quick overview of XNA on the mobile platform for Silverlight developers who have not dealt with XNA in detail before. It explains the possibilities of interaction between Silverlight and XNA, and why you as a Silverlight developer should care about XNA even if you don't want to develop games.
In successive parts of this series, we'll go into the details of programming 2D games for Windows Phone 7 using XNA, with special focus on those parts that require a change of thinking when you are coming from a Silverlight background. I strongly encourage you to comment on each part and request more information about topics you are interested in. If possible, your feedback will directly result in the design of future articles.
The Windows Phone 7 Platform
The base of all development on the Windows Phone 7 platform is a .NET Framework managed runtime code sandbox based on the Compact Framework know from previous mobile platforms (Windows CE/Mobile). This means that all application development for the phone devices is done in managed code and in a protected sandbox. On top of that, the following structure is established:


    As you can see, both Silverlight and XNA share a great amount of the available functionality. The base class library provides all the basic plumbing needed in most software and is similar to what you know from other platforms like desktop Silverlight. Neither this base class library nor most of the provided services specific to the Windows Phone 7 platform are tied to Silverlight or XNA per se. In fact, it's even possible for great parts of Silverlight and XNA to interact with each other and to be used side-by-side. Let's see how that works.
    XNA and Silverlight Interop
    When a .NET or Silverlight developer reads "interop", they often think of painstaking work ahead. For Win32 interop, you need to import operating system functions, map data types and marshal between the managed and unmanaged world. For COM interop in Silverlight, you need to know the API by heart or look up every detail in its documentation, as you don't have any built-in help like Intellisense in Visual Studio which could guide you through the process of interacting with the unmanaged component. In this situation however, things are different.
    Since all development for Windows Phone 7 happens to be managed code in C# or Visual Basic .NET, and both Silverlight and XNA manifest themselves as libraries which can be referenced and accessed natively in managed code, the borders between both are easily blurred. The transition between both worlds in fact is so seamless that developers often don't even realize when they cross these borders. It's likely that even if you as a Silverlight developer have never consciously used XNA, an application of yours did, behind the scenes, without you even noticing.
    A concealed example
    A very prominent example for this is the Gesture Service and Gesture Listener that can be found in the Silverlight for Windows Phone Toolkit. These classes provide an easy way to access gestures like flicks or pinching in your Silverlight application. When you look at the source code however, you will realize that this construct is only a shallow wrapper around the Input.Touch namespace functionality from the XNA framework. It adds some logic to recognize gestures and to translate from XNA's polling-based model to the event-driven nature of Silverlight. To many people this comes as a surprise, and they're not aware it's actually XNA when they're using these features.
    Limitations of Silverlight
    In some areas we also have some limitations in Silverlight when it comes to making full use of the phone device features. In these cases, it's a good idea to take a quick look at XNA, because sometimes it offers superior possibilities in the same areas, which simply are not available in Silverlight. A very simple example of this is the message box. Silverlight's API for this is very limited:
    
    
     MessageBox.Show("Hallo World",
    
         "This is a caption",
    
         MessageBoxButton.OK);
    
    
    This is about all you get. You can show a text with a caption, and decide whether you want to show the OK button or both OK and Cancel buttons. In XNA though, there is the Guide helper class, which let's you do something like that:
    
    
     Guide.BeginShowMessageBox("This is a caption",
    
         "Hallo World",
    
         new string[] { "First button", "Second button" },
    
         1,
    
         MessageBoxIcon.Alert,
    
         null,
    
         null);
    
    
    You can specify the number of and labels for the buttons yourself, and when you pass in different values for the MessageBoxIcon argument, you will get different behaviors for your message box (e.g. different sounds). Another thing to note is that this message box is non-blocking by default, which is also not possible in Silverlight; but it also means you have to put extra effort into your code if you want to make it blocking.
    Other areas where XNA offers features that are not available in Silverlight are:
    
        Certain audio features like playing multi-channel sounds. 
        Advanced sound effects, for example changing parameters like pitch and similar on the fly while the sound is playing. 
        Recording audio using the phone's microphone. 
        Interaction with the media library to load songs, videos and pictures (without using the PhotoChooserTask) and also to save pictures back to the media library. 
        The previously mentioned input gestures, which are now also available by using the Toolkit wrapper. 
    
    Limitations of interop
    Although you can use great parts of both worlds in the same application, there are some restrictions to the possibilities of interop between XNA and Silverlight. To be more specific, the official certification requirements for the RTM release published by Microsoft contain a paragraph that says:
    
    4.2.5 The application must not call any APIs in the Microsoft.Xna.Framework.Game
    

    assembly or the Microsoft.Xna.Framework.Graphics assembly when using any methods from
    

    the System.Windows.Controls namespace.
    
    That's a heavy one. A lot of developers would love to pick the best of two worlds and mix visual elements from XNA and Silverlight in their applications. XNA does not have a real concept of controls, and hence does not ship with a set of built-in UI controls, so it would be great to be able to use Silverlight controls for your game's menu system, for example. And the other way round, a great benefit for Silverlight developers would be to use XNA in parts of their application, for example when they need the superior rendering capabilities and performance, or native 3D support. Unfortunately, with the above restriction in place, none of this is possible in the RTM release.
    The good news however is that this limitation is eased in the first major update of the platform (code name "Mango"). Starting with this version of Windows Phone, developers will be able to mix XNA and Silverlight in the same application. There still are restrictions in place (for example, you still won't be able to use anything from the Game assembly), and doing this requires to choose a certain solution/project setup where Silverlight takes the leading role; however, it allows you to use the best from Silverlight and still have XNA rendering parts of your game or application, or even mix elements of both technologies on the same page. We will see how this works in more detail in part 12 of this series.
    Windows Phone 7 as a Gaming Platform
    From the beginning, Windows Phone 7 has aggressively been promoted as a gaming platform. Big players in the industry like Electronic Arts are developing games for this platform, and you will find a lot of well-known brands in the market place, from The Sims™ to Assassin's Creed™ to Guitar Hero 5 and a lot more. In 2011's CES keynote from Steve Ballmer, a big part of the Windows Phone 7 presentation was the show case of current and future games. Obviously gaming is a major part of Microsoft's strategy for these devices.
    For smaller companies or hobby developers, the mobile platform offers the opportunity to develop casual games people can play wherever they are. Some very remarkable games are already available and prove that an addictive idea does not necessarily need a big publisher or developer team to make a successful appearance on the phone. Game development apparently is an area developers for Windows Phone 7 are very interested in. At the moment of writing this, the market place offers around 5900 apps for download, and out of this 1340 are games. This makes games by far the category with the most entries:
    
    In the following parts, I'll go into the details of what considerations you need to make when you want to develop games for Windows Phone 7.
    Choosing between Silverlight and XNA
    Because XNA is a dedicated framework for game development, a lot of people perceive this as the only possibility to create games for Windows Phone 7; some even think it is a certification requirement to use XNA when you want to publish applications to the game section of the market place. This could not be more far from the truth. You are free to also choose Silverlight as your development tool for game creation. In fact, I know of several games in the market place that are made with Silverlight, and your decision on what technology to use should be made carefully to optimize your development process in terms of efficiency, depending on your requirements.
    When to choose XNA
    3D support – This is a major argument for XNA. If you need that extra dimension, it's almost certain that XNA which is built on Direct3D will be the better choice. You have excellent support for 3D graphics with it, and if you have worked with 3D technology before (not necessarily XNA, but also native Direct3D or even OpenGL) the involved concepts and theory will be very familiar to you and make the transition easy. Although it has some limitations (for example in terms of shader support), XNA on the phone basically has the same features as Direct3D 9. Silverlight on the other hand has no real support for 3D, and it would require a lot of work to even get some of the basic things done.
    Performance – When you are about to create a visually complex game, probably with a lot of effects and moving elements, it's advisable to use XNA. It has been optimized for performance and GPU rendering. Silverlight's layouting system is more comfortable, but that comes at the cost of lower performance in these situations, and when you have to do a lot of blending and work with transparency a lot (particle effects and the like), performance may suffer with Silverlight.
    Compatibility with XBox – If you are planning on developing a game for both the Phone and XBox or even the Windows Desktop, and to share code between those implementations, Silverlight wouldn't be an optimal choice as it is not available on the XBox. XNA is not only a supported framework on the Phone, but also runs on the XBox and Windows desktop systems, which makes it considerably easier to share code for projects targeted at those platforms.
    Misc – There are some more smaller arguments for XNA. Using the built-in content pipeline to import assets provides a more powerful mechanism to organize your game content, for example. It supports a variety of formats for graphics and sounds that can be imported and converted without additional work, and you can even write your own importers for custom formats that integrate seamlessly into your developer experience if you like.
    
    When to choose Silverlight
    Comfort – Silverlight's development experience, especially compared to XNA, is a pleasure in a lot of situations. The design-time support of tools like Expression Blend alone can be a huge boost in productivity. That story continues when it comes to the rich set of built-in controls you can use in Silverlight (buttons, text controls, items controls etc.); you have to create those all manually in XNA, from scratch, if you need something comparable. Then there's the layout system and controls that do all the heavy lifting for you when it comes to arranging content automatically – in XNA you'll find yourself calculating positions and coordinates for these things a lot. So if your game depends a lot on user interaction with standard controls, or you can make good use of the built-in Silverlight features or use the available tools to cut your development time in half, Silverlight should definitely be a consideration for you.
    Compatibility with the web browser – We have talked about how XNA is great when you want to develop for both the phone and XBox. The same is true for Silverlight if you aim to create a game for both the phone and the web. It is unlikely that you can reuse your UI for a desktop Silverlight application. But again, if you plan on sharing code between the two platforms and plan ahead, Silverlight might be the better choice, as XNA's programming model is so different from Silverlight's and hence harder to port to a web application.
    Vector graphics – Silverlight's rendering system is vector based, even the text. That means that you get some benefits from that for free, for example lossless scaling capabilities. XNA has little to no support for this (text rendering is also bitmap based). So if your game heavily depends on zooming of elements that can be designed as non-bitmaps in Silverlight, you might want to make use of this. 
    
    Misc – As with XNA, there are also minor arguments for Silverlight for specific scenarios. For example, if you want to work with video content, then Silverlight offers great flexibility with the media element. XNA on the other hand only supports full-screen video playback, which means you cannot embed video nicely into your application.
    
    
    When to choose both
    As mentioned above, starting with Windows Phone "Mango", you will be able to mix both technologies in the same application. This is an attractive alternative for a lot of scenarios, and it allows you to easily make use of the best from XNA (like 3D support, the better performance, the content pipeline and more) and Silverlight (the comfort of having a layout and animation engine, pre-built controls, vector graphics and other things) at the same time.
    You may ask yourself why you shouldn't always use this kind of integrated application. One major argument against this is the worse portability of your code. XNA is a technology that supports not only Windows Phone, but has been established for years on other platforms like the PC and XBox. If you want to target those other platforms with your game too ("three screens"), then one of your goals of course is to reuse as much code as possible. Once you have decided to make use of the Silverlight-XNA-integration of Mango though, your code will need some adjustments (like not relying on the Game class anymore and others), and that will likely make it harder to achieve this goal.
    Another point of course is that this feature requires your end users to have Windows Phone "Mango" on their devices. The rollout of this new version only starts in the near future, and it will surely take months from now for the majority of users to transition to it. Until then, if you target Mango features like this exclusively, you are limiting the reach of your application and the number of potential customers. Of course this is only a temporary issue that will be solved over time, but depending on your release schedule it might be a big issue.
    Summary
    In this article we have learned that Silverlight and XNA, although very different in their programming models, are not that far apart on Windows Phone 7. Both are based on a common foundation, and parts of the libraries can be and already are shared between those two worlds easily.
    We have also seen that game development for the new mobile platform is not something exclusive to XNA, but can be accomplished using Silverlight too. In fact, both technologies have their advantages when it comes to effectively programming games for Windows Phone 7.
    I hope that by giving a glimpse of XNA, I've sparked some interest for those who had no motivation to delve into it so far. In the following parts of the series, we will shed light on several aspects of programming games with XNA and also focus on the differences to Silverlight's programming model to ease the learning curve for those who didn't engage in XNA development yet.
    Please feel free to add your comments and thoughts, or contact me directly with any questions you have.
    About the Author
    Peter Kuhn aka "Mister Goodcat" has been working in the IT industry for more than ten years. After being a project lead and technical director for several years, developing database and device controlling applications in the field of medical software and bioinformatics as well as for knowledge management solutions, he founded his own business in 2010. Starting in 2001 he jumped onto the .NET wagon very early, and has also used Silverlight for business application development since version 2. Today he uses Silverlight, .NET and ASP.NET as his preferred development platforms. 
    He created his first game at the age of 11 on the Commodore 64 of his father and has finished several hobby and also commercial game projects since then. His last commercial project was the development of Painkiller:Resurrection, a game published in late 2009, which he supervised and contributed to as technical director in his free time. You can find his tech blog here: http://www.pitorque.de/MisterGoodcat/


Exploring Silverlight-XNA integration on Windows Phone 7
editorial@silverlightshow.net (Levente Mihály ) — Mon, 30 Aug 2010 00:33:00 GMT
This article is compatible with the latest version of Silverlight for Windows Phone 7.

More on this topic..

    WP7 Stock Quoting Demo series 
    What is Windows Phone series 
    DataGrid Control for WP7 series 


Windows Phone 7 platform provides two different frameworks for developing applications: Silverlight and XNA. XNA is a game-specific framework. If you want to write a 3D game, or a loop-based game with a lot of effects, textures and motion, you should choose XNA. So why should a SilverlightShow reader care about XNA? Because the two platforms are more-or-less compatible with each other, meaning you can use XNA assemblies in your Windows Phone 7 Silverlight applications. Here’s a brief introduction to the Silverlight-XNA integration.
First of all, you can download source codes for 
- MicDemo – recording with microphone
- SoundEffectDemo – MSDN code modified for Silverlight: playing and applying 3D positioning effects to a SoundEffect
- SongDemo – playing back a song
- PictureDemo – loading and saving pictures with MediaLibrary
XNA assemblies, limitations
In a Silverlight WP7 application we can use all the XNA assemblies except Microsoft.Xna.Framework.Game and Microsoft.Xna.Framework.Graphics. Sadly, this kind of kills the concept of a game with Silverlight menus or a Silverlight application with some 3D XNA graphic.
Enabling XNA
When you first run your Silverlight application that uses the XNA Framework, you might get an exception like this:
 
The FrameworkDispatcher.Update method triggers event processing in the XNA Framework. It is automatically called whenever Game.Update is called. In Silverlight though, we don’t have a Game.Update, thus we have to call the FrameworkDispatcher.Update method manually.
The easiest way is to create a class like this:


 public class XNAAsyncDispatcher : IApplicationService

         {

             private DispatcherTimer frameworkDispatcherTimer;

             public XNAAsyncDispatcher(TimeSpan dispatchInterval)

             {

                 this.frameworkDispatcherTimer = new DispatcherTimer();

                 this.frameworkDispatcherTimer.Tick += new EventHandler(frameworkDispatcherTimer_Tick);

                 this.frameworkDispatcherTimer.Interval = dispatchInterval;

             }

  

             void IApplicationService.StartService(ApplicationServiceContext context)

             {

                 this.frameworkDispatcherTimer.Start();

             }

             void IApplicationService.StopService()

             {

                 this.frameworkDispatcherTimer.Stop();

             }

             void frameworkDispatcherTimer_Tick(object sender, EventArgs e)

             {

                 FrameworkDispatcher.Update();

             }

  

         }


and add it to ApplicationLifetimeObjects collection:


 // Constructor

 public App()

 {

     ...

     this.ApplicationLifetimeObjects.Add(

        new XNAAsyncDispatcher(TimeSpan.FromTicks(333333))

        );

 }


The standard rendering rate for XNA is 30fps so we configure the DispatcherTimer according to that.
Audio and Media
The Microsoft.Xna.Framework.Audio and Media namespaces offer  a lot of options. Playing back sound effects, dynamic sound effects, recording audio with the microphone, applying 3D effects to audio, and the list goes on…

SoundEffect
The SoundEffect class can be useful in a Silverlight game where you have a lot of sounds, often playing at the same time. Using the SoundEffect class to play a wave sound should be better performance-wise than using Silverlight’s MediaElement. Here’s how to load and play a sound file in a loop with XNA:


 SoundEffect se = SoundEffect.FromStream(TitleContainer.OpenStream("hand-clap-1.wav"));

 soundEffectInstance = se.CreateInstance();

 soundEffectInstance.IsLooped = true;

 soundEffectInstance.Play();


The TitleContainer static class provides filestream access in XNA. In the Play method we can also pass volume, pitch and panning values.
It’s very easy to apply positional effects to the sound, by calling the Apply3D method on the SoundEffectInstance, and passing one or more AudioListener instances and an AudioEmitter.
Microphone
Windows Phone 7 provides access to the microphone via the Microsoft.Xna.Audio.Microphone class. The quality is 16-bit Mono.


 Microphone mic = Microphone.Default;

 MemoryStream micStream = new MemoryStream();

 byte[] buffer;

 SoundEffect recordedSE;

        

 // Constructor

 public MainPage()

 {

    InitializeComponent();

    mic.BufferReady += new EventHandler(mic_BufferReady);

    mic.BufferDuration = TimeSpan.FromMilliseconds(1000);

    buffer = new byte[mic.GetSampleSizeInBytes(mic.BufferDuration)];            

 }

   

 void mic_BufferReady(object sender, EventArgs e)

 {

    mic.GetData(buffer);

    if (isRecording)

    {

      micStream.Write(buffer, 0, buffer.Length);

    }

 }


Now we can start recording by calling the mic.Start() method, and stop recording with mic.Stop(). 
We can play it back:


 SoundEffect recSE = new SoundEffect(micStream.ToArray(), mic.SampleRate, AudioChannels.Mono);

 recSE.Play();


Or save it to the application’s isolated storage:


 using (var isf = IsolatedStorageFile.GetUserStoreForApplication())

 {

    using (var isfstream = new IsolatedStorageFileStream("record.pcm", FileMode.Create, isf))

    {

      isfstream.Write(micStream.ToArray(), 0, (int)micStream.Length);

    }

 }


Media
The Microsoft.Xna.Framework.Media namespace provides access to the Media Library. With the MediaLibrary class we can play back songs and load pictures from the user’s collection on the device. Saving pictures to the MediaLibrary is also allowed, but this is not true for songs. Another limitation is that we can’t get access to DRM protected music. 
To load a picture from the media library, we must select the device’s library source. In the following code snippet I’m loading the first picture of the user’s library:


 foreach (var source in MediaSource.GetAvailableMediaSources())

 {

     if (source.MediaSourceType == MediaSourceType.LocalDevice)

     {

       ml = new MediaLibrary(source);

       if (ml.Pictures.Count > 0)

       {

         var bitmap = new BitmapImage();      

         bitmap.SetSource(ml.Pictures[0].GetImage());

         img.Source = bitmap;

       }

       break;

     }

 }


And we can write to the library using the MediaLibrary.SavePicture method:


 ml.SavePicture("TestPic", TitleContainer.OpenStream("Chrysanthemum.jpg"));


Regarding the emulator’s Songs library,  it is empty, unlike the Pictures, which contains some sample images. To make things worse, even on the unlocked emulator I couldn’t find any way to upload some mp3s to the emulator’s library.
Still, the Song class is useful, we can load our files (or download, save to isolated storage and then load), and play them as background music. The Song class has also properties for artist, rating, playcount etc. They can be played using the MediaPlayer static class. 


 Song song = Song.FromUri("I Will Not Bow", new Uri("02.I Will Not Bow.mp3", UriKind.Relative));

 if (MediaPlayer.GameHasControl)

 {

   MediaPlayer.Play(song);

 }


In XNA for Windows or Xbox, MediaPlayer can provide visualization data, so you can display audio visualization easily (sound waves, bars etc) via the MediaPlayer.GetVisualizationData method. In Windows Phone 7 it is not available (it won’t throw an exception if we call it, but will only return a bunch of zeros), so you will have to find your own way to give graphical feedback.
MathHelper, Vectors
XNA contains a lot of classes required by game developing including a Vector class with 2,3 or 4 components, Rectangle class with intersect checking and a MathHelper static class. This gives somewhat an out-of-the-box solution for checking collisions, playground etc.
GameServices
The GameServices assembly gives you access to Xbox Live parts, but i’m not sure if it’s usable in a Silverlight based game. Even if you are developing an XNA game, you will need to be a registered Xbox Live developer to gain access to the GameServices.AchievementCollection for example.
Summary
Well, I think I covered the most promising scenarios, but I’m also sure, that a lot of new ideas will come about. On the audio level the integration is good, and apart from a few missing things, it’s definitely usable. The absence of the Game and Graphics assemblies really hurts, with them the Silverlight-XNA integration would reach a whole new level. We don’t have to go too far to imagine an XNA game with Silverlight menus, scoreboard, etc. or a Silverlight application with 3D models loaded with XNA. I hope in the next versions of Windows Phone 7 this level will be reached, and until then we can use the non-graphical components in our Silverlight applications.

	Initialize	Activated	Deactivated	Exiting
Game is started	x	x
Game is deactivated/tombstoned (RTM)			x	x
Game is deactivated/dormant (Mango)			x
Game is reactivated	x	x
Game is exited			x	x

	Launching	Deactivated	Activated	Closing
Game is started	x
Game is deactivated/tombstoned (RTM)		x
Game is deactivated/dormant (Mango)		x
Game is reactivated			x*
Game is closed				x