5. Input Differences
The majority of Windows users will not have access to
a touch screen, but the mouse can be used to provide most of the
interaction that the touch screen can provide. The loss of multitouch
input is offset by having multiple mouse buttons, and the mouse wheel
available to most users.
On the other hand, all your users will have
keyboards, whereas only a minority of Windows Phone 7 users will have
this hardware available.
This section explores the differences in input methods between the two environments.
5.1. Mouse Input
When we wanted to read raw touch input from the screen in our Windows Phone 7 projects, we used the TouchPanel class . 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 mouse position relative to the window, using the X and Y
properties. This will be available regardless of which mouse buttons
are pressed, and at all times, even if the mouse cursor is outside the
game window.
The state of the LeftButton, MiddleButton, and RightButton. The available state values are Released when the button is up, and Pressed when it is down.
Support for the state of two additional mouse buttons via the XButton1 and XButton2
properties (though many mice will not have sufficient buttons to
support this, and exactly which buttons they correspond to will vary
from one mouse to the next).
A ScrollWheelValue
that contains the cumulative distance that the mouse wheel has been
scrolled. This is not incremented or decremented by values of 1, but
uses larger values (typically 120 for each unit that the wheel is
scrolled).
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.
5.2. Gestures
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.
5.3. Keyboard Input
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.
5.4. GamePad Input
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 Buttons property returns a GamePadButtons object, which in turn has properties to allow the state of each individual button to be checked. These button properties are A, B, Back, BigButton, LeftShoulder, LeftStick, RightShoulder, RightStick, Start, X, and Y. That should be enough buttons for anyone.
The DPad property returns a GamePadDPad object, with properties to query the state of the directional pad: Down, Left, Right, and Up.
The ThumbSticks property returns a GamePadThumbSticks object, with properties for the controller's thumb sticks. Two properties are available, Left and Right, corresponding to the left and right stick. They each return a Vector2, allowing proportional values to be read rather than simple pressed or released values.
The Triggers property returns a GamePadTriggers object, allowing the state of the trigger buttons to be read. They are obtained from the Left and Right properties, and are once again proportional values, returned as a float.
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.
NOTE
The GamePad class will compile in the
Windows Phone 7 environment, and in fact is used in all XNA projects to
check for the state of the Back button. This is the only button that
will return any values on the device, however.
6. Isolated Storage
Unlike Windows Phone 7, Windows is an open operating
system and allows full access to its underlying file system. There is
therefore no concept of isolated storage when running in Windows.
File access is instead performed using the normal System.IO namespace, exactly as it would be in another game.
XNA games in Windows also have no access to the IsolatedStorageSettings
class that we used in the game framework to save and reload our game
settings. This was a very useful class to have around, and we will need
to replicate its behavior when running in Windows – this issue will be
addressed in a moment.
7. Application Life Cycle
Windows is a fully multitasking operating system with
none of the memory or processing constraints that the phone has to work
within, so it does not have any concept similar to that of tombstoning.
When a Windows application is put into the
background, it continues running exactly as it would have in the
foreground. There is no need to maintain application state when the game
deactivates or to perform any other similar processing.
