The Windows version of the project runs in a tall, thin window; a window whose client area has a width of 480 pixels and a height of 800 pixels—exactly the size of the Windows Phone 7 screen.

The window is sized in this way because these are the dimensions specified for the graphics.PreferredBackBufferWidth and graphics.PreferredBackBufferHeight properties in the Game1 class constructor. By setting these dimensions to different values for the Windows version of the game, we can get a more appropriate window size. Listing 16-3 includes code for both Windows Phone 7 and Windows, using a 1024 × 768 pixel window for the latter. You can find this code in the FirstXNAProject example accompanying this chapter.

// Set backbuffer size and orientation
#if WINDOWS_PHONE
        _graphics.PreferredBackBufferWidth = 480;
        _graphics.PreferredBackBufferHeight = 800;
#else
        _graphics.PreferredBackBufferWidth = 1024;
        _graphics.PreferredBackBufferHeight = 768;
#endif

This size feels much more comfortable in Windows now, but has resulted in a differently sized window, which is therefore able to display fractionally less content on the y axis, and considerably more on the x axis than the original portrait-oriented Windows Phone 7 display.

You will almost certainly have to make adjustments to your game to compensate for these differences if you use this phone orientation. If nothing else, you will want to center the graphics horizontally to stop them from appearing along the left edge of the window.

In games using matrix rendering rather than sprites, the impact of this change might not be as great because the abstract coordinate system will adjust to match the new window size. There will still be considerably more space available at each side of the window, though, which might result in unexpected graphics appearing.

If your Windows Phone 7 game uses landscape orientation, the effect of the new window size will be much less significant as the Windows monitor is very likely to be using the same orientation. A window that is 800 × 480 pixels feels much more comfortable in Windows than one that is 480 × 800 pixels.

A very common feature of Windows games is the ability to run in full screen mode, where the game takes over the entire display rather than running inside a floating window. Full screen mode is handled in Windows in the same way as the phone—by setting the graphics.IsFullScreen property to true in the class constructor.

You will find this instruction inside this chapter's FirstXNAProject example, commented out. You can uncomment it to see its effects, but before you do, note that when the game is running in full screen mode, there is no Close Window button to use to leave the game and return to Windows. The keyboard shortcut Alt+F4 is the answer here because it closes the active window; use it when the game is running to close its window down.

Once your game is running, if you decide to switch between full screen and windowed mode, you can just call the graphics.ToggleFullScreen method and XNA will take care of everything for you.

When the game runs in full screen mode, Windows will automatically stretch it to fill the whole monitor. This can be very useful, but can also result in the graphics being stretched if the aspect ratio of the monitor doesn't match that of the window.

Something you might want to do is to run the game at the native screen resolution being used by Windows. At the time the game class constructor is running, nothing is available to provide this information, but we can defer the setting of the resolution until a moment later, by which time the desktop width and height can be retrieved.

This is achieved instead by setting up an event handler for the _graphics object's PreparingDeviceSettings event. When that event fires, the back buffer size can be set to match the size of the current display mode, as shown in Listing 16-4.

public Game1()
  {
      _graphics = new GraphicsDeviceManager(this);
      Content.RootDirectory = "Content";

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

      // Set backbuffer size and orientation
#if WINDOWS_PHONE
      _graphics.PreferredBackBufferWidth = 480;
      _graphics.PreferredBackBufferHeight = 800;
#else
      // Instead of setting a fixed size, use the size of the Windows desktop
      _graphics.PreparingDeviceSettings += new
          EventHandler<PreparingDeviceSettingsEventArgs>(_graphics_PreparingDeviceSettings);
#endif

      // Switch to full screen mode
      _graphics.IsFullScreen = true;
  }

  // Set the window size to match the desktop resolution
  void _graphics_PreparingDeviceSettings(object sender, PreparingDeviceSettingsEventArgs e)
  {
      e.GraphicsDeviceInformation.PresentationParameters.BackBufferHeight =
                        e.GraphicsDeviceInformation.Adapter.CurrentDisplayMode.Height;
      e.GraphicsDeviceInformation.PresentationParameters.BackBufferWidth =
                        e.GraphicsDeviceInformation.Adapter.CurrentDisplayMode.Width;
  }

Be aware when setting the resolution in this way that you have no idea what size your window will actually end up being. You will need to ensure that your rendering code is resolution-independent to ensure that the game continues to be playable on all different screen modes.

In a finished game, it is worth considering providing options to give the user a choice of window sizes and control over whether the game will display in full screen mode or not.

XNA's default behavior in Windows is to hide the mouse cursor when it is over the game window. This might be what you want in full screen mode (though it also might not), but in windowed mode it can be quite distracting—when the user moves the cursor across the window to click the window's Close button, the cursor suddenly vanishes!

Its behavior is easy controlled using the IsMouseVisible property provided by the XNA Game class. You can therefore simply change this property in your constructor or elsewhere in your game to control the cursor visibility, as shown in Listing 16-5.

this.IsMouseVisible = true;

When we wanted to read raw touch input from the screen in our Windows Phone 7 projects, we used the TouchPanel class (refer to Chapter 4 if you need to refresh your memory on this subject). The TouchPanel class is available when running on Windows so the code still compiles, but unless you have a capable touch-screen monitor running under Windows 7, it reports a MaximumTouchCount of 0 and never returns anything from its GetState function.

Assuming that we decide to use mouse input as an alternative to touch input, the best way to obtain this data in a Windows game is by using the Mouse class.

This class contains a static method named GetState that returns a MouseState object containing all sorts of details about the mouse. These include the following:

The capabilities are very different from the multitouch values that the TouchPanel class provides, and if your game is doing anything more complex than simple single-point interaction, you might need to invest some thought and time into remapping the control mechanism into the Windows environment.

The Mouse class is available and functional inside the Windows Phone 7 environment, too, so if its capabilities are suitable, you might be able to use the same code in both places. Windows Phone 7 treats the primary contact point as if it were the left mouse button.

There are several useful TouchPanel features that you will lose as a result of using Mouse on the device, however, as they are not offered by the MouseState class. They include the ability to tell whether the touch state is Pressed, Moved, or Released; and the TryGetPreviousLocation method. Also note that the X and Y position properties will always return the last known position unless contact is currently being made with the phone's screen.

The TouchPanel example project that accompanies this chapter has been copied from the project with the same name in Chapter 4 and modified to additionally support Windows. As you will see if you look through the source code, the touch processing code in the TouchPanelGame.Update method needed to be completely rewritten to support the use of the Mouse class.

The high-level TouchPanel gestures are not supported in the Windows environment. The code will compile and run without any problems, but no gestures will be returned by the IsGestureAvailable or ReadGesture class members.

Now for a little good news: keyboard input is handled exactly the same way in Windows as it is in Windows Phone 7. The Keyboard.GetState function is used to return information about keys that are pressed, and the data is formatted just the same as on the phone.

Windows games have an input mechanism that Windows Phone 7 does not, however, and that is the ability to use Xbox 360 game controllers for input. Input from these controllers is provided using the GamePad class.

Data is obtained by calling the static GamePad.GetState function, which is called passing in the index of the player whose gamepad values are to be returned. For single-player games, just pass PlayerIndex.One. The function returns a GamePadState object.

The first thing you need to do with this returned object is check whether it is actually receiving data from a connected gamepad. Its IsConnected property will return this piece of information; if it returns false, the rest of the state object will be entirely empty and another input mechanism must be sought.

If the device is connected, it offers a wealth of controller information:

The class also offers two methods, IsButtonDown and IsButtonUp, which allow a specific button's state to be checked. This will sometimes be more useful than the GamePadButtons properties, as passing the button as a parameter allows it to be easily reassigned by the player.

As mentioned in the "Isolated Storage" section a moment ago, there is no IsolatedStorageSettings class in the Windows version of XNA, so we will need to find an alternative method for Windows to use for storing settings in the GameFramework.SettingsManager class.

This functionality is not too tricky to replicate. First of all, when compiling for Windows, the class will provide a dictionary into which string values can be written. Two new functions are then provided that allow the contents of this dictionary to be translated into an XML document and written to disk, or to be read back from the XML and placed back into the dictionary.

The API for the class can remain identical across the two platforms, removing any need for the games using the class to have to cater separately for each target environment.

First there is the settings dictionary. This dictionary is declared as a class-level variable, as shown in Listing 16-6, set to compile only under Windows. Alongside it we declare a file name to use when reading and writing the settings. No path is specified, so this will be created in the same directory as the game's executable.

#if WINDOWS
    // Declare a dictionary into which all of our settings will be written
    private Dictionary<string, string> _settings = new Dictionary<string, string>();
    // The name of the file in which the settings will be stored
    private const string FileName = "Settings.dat";
#endif

Following on from this is a minor change to the class constructor. So that any previously stored settings are available as soon as the class is queried, they must be reloaded. The constructor handles it to ensure that values are always available to the class. Listing 16-7 shows the new constructor; we will look at the LoadSettings function shortly.

internal SettingsManager(GameHost game)
    {
        // Store the game reference
        _game = game;

#if WINDOWS
        // Load any existing stored settings
        LoadSettings();
#endif
    }

The next change that the class needs relates to putting values into the dictionary and getting them back out again. Although there are multiple overloads of SetValue and GetValue, only one overload for each function actually interacts with the settings, so this is the only one that we need to modify.

SetValue is enhanced as shown in Listing 16-8 so that it will work for both Windows Phone 7 games and Windows games. The Windows code is virtually identical to that of Windows Phone 7, except that it uses the class's _settings dictionary instead of IsolatedStorageSettings.

public void SetValue(string settingName, string value)
    {
        // Convert the setting name to lower case so that names are case-insensitive
        settingName = settingName.ToLower();

#if WINDOWS_PHONE
        // Does a setting with this name already exist?
        if (IsolatedStorageSettings.ApplicationSettings.Contains(settingName))
        {
            // Yes, so update its value
            IsolatedStorageSettings.ApplicationSettings[settingName] = value;
        }
        else
        {
            // No, so add it
            IsolatedStorageSettings.ApplicationSettings.Add(settingName, value);
        }
#else
        // Does this setting already exist in the dictionary?
        if (_settings.ContainsKey(settingName))
        {
            // Update the setting's value
            _settings[settingName] = value;
        }
        else
        {
            // Add the value
            _settings.Add(settingName, value);
        }
        // Save the settings
        SaveSettings();
#endif
    }

One final change is present in this piece of code in addition to the change of dictionary, however: it makes a call to SaveSettings each time a value is updated. This ensures that the settings are always retained from the moment they are modified, mirroring the behavior on the phone. We will look at the SaveSettings function shortly.

The code for GetValue is similarly modified, reading from either the _settings dictionary or IsolatedStorageSettings as appropriate. This is repeated, too, for the ClearValues and DeleteValue functions, both of which also call SaveSettings to ensure that their changes are immediately reflected to the data file on disk.

Finally we arrive at SaveSettings and LoadSettings, whose responsibilities are to ensure that the data is stored for later use, and then read back in for subsequent interrogation. They operate using an XML file, into which all the defined values are placed.

The code within these functions is not particularly interesting, using exactly the same techniques that we used for saving and restoring the high scores inside the HighScores class, so please take a look in the project's source code if you want to see how they are implemented.

With these changes in place, the class operates identically (from the client's perspective) under both environments. If you scan through the code for the class, the conditional compilation statements scattered throughout do make the code harder to read, but the overall functionality is worth that increase in complexity if you want to be able to target both platforms.

Although in Windows Phone 7 we need to deal with the Launching, Closing, Deactivated, and Activated events, in Windows, we don't particularly need to worry about any of these as there is no application life cycle as such.

It is likely that you will have taken advantage of the Launching event to initialize your game, however, so it is important that its event still fires when running under Windows so that the initialization still completes properly.

Instead of setting up the event handlers, the GameHost class constructor simply calls into the virtual GameLaunching function when running under Windows. This is the same path that a newly launched game would take on the phone, resulting in the same startup behavior.

All the rest of the life cycle code can be excluded from this class as it is not needed in Windows.

A small and simple change is required to the HighScores class to instruct it to read and write its score data to a file using the System.IO namespace instead of using isolated storage. As the class already stores its content in an XML document, no additional modifications are necessary.

There are no other changes required to the game framework. The rest of the project works identically in both environments.

The biggest changes that you will find you need to make when getting your games running for Windows will almost certainly be in the area of the organization of your display (taking the Windows display orientation and screen resolutions into account) and input (using Mouse and Keyboard instead of TouchPanel). You should find that the rest of your game will work as expected without any changes being required.

FireAndSmoke was a project that we used back in Chapter 8 to demonstrate particle effects. It runs in landscape orientation, so it should convert fairly easily to the default Windows landscape screen orientation; and has no interaction at all, removing the need to change any input processing code.

Only one change was required during the conversion of the project: to simply set a more appropriate default screen resolution—1024 × 768 pixels instead of the phone's 800 × 480.

With this change made, the project runs very nicely under both Windows and Windows Phone 7.

This project was developed in Chapter 8 and then updated in Chapter 10 to add tombstoning support. We will leave all this in place in the conversion to Windows so that the functionality remains when compiling for the phone.

Three changes were required during the conversion of the project. The first was to set a more appropriate default screen resolution, just as we did for the FireAndSmoke project.

The second change, the only one of any substance, was to the way the camera mode is changed. On the phone, the TouchPanel class is used to detect taps to the screen, but in Windows we need to use the Mouse class instead. However, the Mouse class only tells us whether the button is up or down, and doesn't directly provide a way to tell whether the button has been pressed down since the last update. As a result, simply checking the left button state would cause the camera to constantly and rapidly cycle through all the different modes when the button was held down, making it very difficult for the user to simply move to the next mode.

We can replicate the "just pressed" behavior by storing the state of the mouse from the previous update and comparing it with the state for the current update. If it was up previously but is down now, it has just been pressed, and we can move to the next camera mode; otherwise, the camera mode is not altered.

Listing 16-9 shows the first part of this modification. It declares a class-level variable to hold the mouse state from the previous update. We begin by setting the current state into it, so there is always a valid set of data contained within the variable even during the first call to Update.

#if WINDOWS
    // Track the previous mouse state so we can tell when the button pressed state changes
    private MouseState lastMouseState = Mouse.GetState();
#endif

The remainder of the code is shown in Listing 16-10. It checks the current state of the left mouse button and compares it with the previous state, indicating that the camera should be updated only if the button has just been pressed.

bool toggleCamera = false;

#if WINDOWS_PHONE
        // Has the user touched the screen?
        TouchCollection tc = TouchPanel.GetState();
        if (tc.Count == 1 && tc[0].State == TouchLocationState.Pressed) toggleCamera = true;
#else
        // Was the mouse up last time, but is down now?
        MouseState thisMouseState = Mouse.GetState();
        if (lastMouseState.LeftButton == ButtonState.Released &&
                                           thisMouseState.LeftButton == ButtonState.Pressed)
        {
            // Yes, so change camera
            toggleCamera = true;
        }
        // Store the new mouse state for next time
        lastMouseState = thisMouseState;
#endif

The final change to the project is a cosmetic one that is present only to make the project look better. When we ran on the phone, we instructed the PaperPlaneObject class to add a new vapor particle only every three updates. This provided a reasonable balance between display complexity and performance; adding more particles caused the game to slow down when running on the device.

Windows PCs tend to have significantly more graphical power than the phone, so we can happily add a particle every update. This results in a much thicker and more voluminous vapor trail.

Everything else works as required without needing to be changed.

To create a new project, use the Silverlight Application template, as shown in Figure 16-3. Use the same name for your application as you used for the Windows Phone 7 application. In this case, we will use the name ColorFade.

Figure 16.3. Creating a new Silverlight application project

Once you have selected a location for your project and clicked the OK button, the New Silverlight Application window will appear, shown in Figure 16-4. It can be used to set the parameters for the project that you are creating.

Figure 16.4. Setting the configuration of the new Silverlight application project

Unless you have specific requirements to the contrary, keep all the options set as shown in the screenshot. This will create a Silverlight 4 project (as mentioned earlier) and will host it in the ASP.NET Development Server. This is a lightweight web server designed specifically for hosting .NET debug sessions, and removes the need to install and configure IIS for development and debugging.

The IDE will open with two projects in the new solution: one for the actual Silverlight application, and the other for the ASP.NET Development Server web site. The latter of these projects can be ignored for our purposes as it is already configured to launch the Silverlight application in the default browser. We will concentrate instead on the main application project.

This project contains a similar set of source files to those we saw when developing for the phone, and they have very similar initial content, too. App.cs contains the code required to start up the project, and MainPage.xaml contains an empty page—though it is actually completely empty this time, whereas on the phone we were given a simple control layout by default.

We could run the project at this stage to see how it looks in the browser, but all it does at the moment is display a white rectangle on a white background. This makes it kind of hard to see whether it is working!

To resolve this issue, click into the main area of the MainPage.xaml page designer and set a color for the Background property of the Grid that is filling the page—any color will do as long as it's not white. With this done, start the project running. After a few seconds, your browser should appear, and it will then display your colored rectangle. Success!

The rectangle will, however, be displayed so that it completely fills the entire browser client area. This is because the Width and Height properties of the page have both been set to Auto. This can be very useful as it allows the content and the user interface to automatically adapt to the available space, but for the purposes of our games it would be much more useful to fix the page to the same screen area that the phone uses.

Try changing the Width property of the page (not the Grid) value to 480 and the Height to 800, and then run the project again. Now the colored rectangle appears at the defined size, ready for us to start putting some content inside it.

Silverlight in the browser uses a different method to display multiple pages of data. If you look carefully at the MainPage code that has been created in our sample project, you will find that it is not actually a page at all, but instead a UserControl.

Silverlight in the browser can display one single top-level element at any time. This is called the root visual, and is set into the application's App object. If you take a look in App.xaml.cs, you will find the code from Listing 16-11. It is this piece of code that actually causes the contents of MainPage to appear in the browser.

private void Application_Startup(object sender, StartupEventArgs e)
    {
        this.RootVisual = new MainPage();
    }

This approach is clearly different from the one we used on the phone. Silverlight offers a control class named Frame, however, which provides exactly the navigation model that we used on the phone. It can navigate to a Page contained within the application using its Navigate method, has GoBack and GoForward methods, and has CanGoBack and CanGoForward properties—all exactly the same as the NavigationService object on the phone.

To take advantage of these navigation functions, we will place a Frame control onto MainPage. All our application pages will then be displayed inside this page, avoiding the need to change any structures of our converted projects.

Delete the existing Grid control from MainPage, and then add a new Frame control from the Toolbox. Right-click the Frame and select Reset Layout/All from the context menu, as shown in Figure 16-5. It will remove all configuration from the Frame so that it completely fills its container: the MainPage user control.

Figure 16.5. Resetting the layout of the Frame control

Change the Frame's name so that it is called mainFrame instead of the default frame1. This is all we need within the XAML to host our content.

We have a slight naming issue to deal with next. The page we have been working on is called MainPage, but we have also been using a class with this name in our Windows Phone 7 projects to actually store the content of the main page. To resolve this naming collision, we will rename the MainPage class in the new Silverlight project to HostPage instead. This then clearly has the role of hosting the pages rather than providing the content for one.

The class can be renamed by first right-clicking the MainPage.xaml file in Solution Explorer and selecting Rename from the context menu. Enter the new name, HostPage.xaml, and the .xaml file itself and the .xaml.cs code file will both be renamed accordingly.

This procedure has only affected the file names, however, not the name of the class defined in the code. To complete the rename operation, open the code behind the page, right-click the name MainPage in the class declaration, and select Refactor/Rename, as shown in Figure 16-6. Enter the new name, HostPage, and click OK to complete the renaming of the class.

Figure 16.6. Renaming the MainPage class

Our project now contains a single UserControl named HostPage, inside which an empty Frame resides. The next step is to add the source files from our Windows Phone 7 project.

The only page in the original ColorFade project is MainPage, so we copy across the MainPage.xaml and MainPage.xaml.cs files, putting them into the new project's directory along with the existing source files. MainPage.xaml can then be added into the project.

Several compilation errors appear at this stage due to differences between the two Silverlight environments. We can fix them up as follows:

This is quite a lot of effort for a single simple page and clarifies why a single code base for both Silverlight environments is not practical. After completing these steps, your project should compile without errors, though it still shows nothing when run because we just get to see the empty frame.

To actually display MainPage, we simply need to tell the frame to navigate there. Modify the HostPage class constructor to contain the code shown in Listing 16-12.

public HostPage()
    {
        InitializeComponent();

        // Navigate to MainPage
        hostFrame.Navigate(new Uri("/MainPage.xaml", UriKind.Relative));
    }

Now when you run the application, the browser window appears and displays the contents of MainPage.

These are the basic steps that need to be performed to transfer your pages across to Silverlight from the phone. Once you have followed these steps, the majority of the XAML layout and the code behind the page should work with little or no modification (unless you are calling in to any Windows Phone 7 libraries, in which case they will need to be redesigned or refactored).

The amount of effort involved is great enough that you will not want to have to repeat the steps on a regular basis. For this reason, a sensible strategy for putting a demonstration game into Silverlight is to focus just on the main game content and leave all the navigation, high scores, and so on behind. This results in a much simpler task.

Another strategy that is worth adopting if you plan to target both environments is to put as little content into the game's Page classes as possible. Simple non-page classes will copy in to the Silverlight environment with little or no modification required at all, so getting as much content into such classes as possible will reduce the overall amount of effort, particularly if you want to regularly update the browser-based Silverlight application to match changes you have made to the Windows Phone 7 version.

The Navigation project demonstrates how navigation within a Frame control works when running in the browser. When you launch the project, the simple game framework menu will appear just as it did on the phone. Clicking the buttons will navigate between the different pages.

Note that each time you click a button, the browser's navigation history is updated. This allows you to use the browser's Back button to return to the previous page, just like on the phone. Also observe that the stack is manipulated in exactly the same way as on the phone when navigating between non-menu pages; click the End Game button in the "Game" page and you will be sent to the "High scores" page, but clicking Back here returns you to the menu, not to the "Game" page.

Also note that state is maintained between the pages in exactly the same way as on the phone. If you click the Back button from the game page, the menu offers the Resume Game button, and clicking it will return you to the game. The state is maintained despite the browser navigation that is taking place.

If you click to start a new game while an existing game is active, you will notice that the MessageBox call works perfectly well in the browser-based Silverlight, too.

In practice, including navigation in a game that you are converting to the browser might be more than you really need, especially if you simply want to give the player an idea of what the game has to offer. It might be more sensible to launch straight into the game and not worry about including the overheads of high score tables and so on. Once you have convinced the players that your game is worth further investigation, they can take advantage of all these features in the full version on the phone.

Apart from the changes described for converting project pages from the Windows Phone 7 Silverlight environment into the browser environment, there are no code changes to this project at all.

To demonstrate getting a game up and running, let's convert the DiamondLines example from Chapter 12. This demonstrates the use of the SLGameFramework, Sprite control, storyboards and animation, user interaction, and (of course) results in a playable game at the end (even if it is very basic).

As you will see if you open and launch the project, it performs very nicely in the browser. The higher specification of a PC results in a very smooth experience. The storyboard animation really helps as it allows the graphics to move as quickly as the PC can animate them, but still ensure that they move at the correct speed, resulting in predictable and very smooth animation.

Figure 16-7 shows a screenshot of the game running inside Mozilla Firefox.

Figure 16.7. Playing Diamond Lines inside a web browser

Once again, the changes required to get this running were no more than described for converting pages earlier on. Despite the game using just a single page (MainPage, in which the game is displayed) we still use the HostPage approach here, both because it simplifies the import of the existing page and because it allows us to more easily add in navigation support later should we want to.