Using XNA Input for Controllers

The Example

We will develop a simple "game" that exercises each of the features of the controller. Each digital button will be represented on the screen with a graphic, and when the player presses a button, its graphic will change to reflect the change in state. The screen will also contain "slider" images where the state of each of the analog buttons will be presented. In addition to the button images, there will be a small viewport where a ship flies around on a sheet of graph paper. As the player uses any of the directional controls to move left or right, the ship will rotate. When the player presses the triggers or uses any of the directional controls to move up or down, the ship will move. Figure 1 shows a screenshot of the final game.

Figure 1: Screenshot of the example game that we will develop in this article.

The Source Images

I created two graphics for each digital button, one for each state (pressed and released). To lay out the screen, I played around with the images in a paint program, moving them around until I was happy with the rough design. Figures 2, 3, and 4 show the source graphics. I divided the collection of images into three files, but this separation is fairly arbitrary.

Figure 2: The sprites that represent the pressed and released states for each of the 14 digital buttons.

The first source image, shown in Figure 2, is named "buttons," and it contains the pressed and released graphics for each of the 14 digital buttons. The second image, shown in Figure 3, is named "analog," and it contains the slider bars and arrows that I use to render the states of the analog buttons.

Figure 3: The sprites for the sliders to show the state of the six analog buttons, as well as the sprites that show which controller ports are active.

It also contains the images that I use to indicate which of the four Xbox 360 Controllers are currently connected. Rather than having eight separate images of the controller connection states (four controllers, each with two states), I decided to build a composite image at runtime by layering the images that you see here. The actual source image is transparent, but I've added a simple checkerboard pattern so that you can see how the individual components of the image line up with each other.

The final image, shown in Figure 4, is named "background," and it contains the graph paper graphic that is tiled across the entire game screen, as well as the ship, and the 640x480-pixel background image, which includes the viewport (complete with drop shadow).

Figure 4: The background sprite that will be layered on top of the scrolling grid. The game screen is 640x480, but the image is 1024x512 (dimensions as powers of 2).

The actual source image is transparent, but I've added a simple checkerboard pattern so that you can see how the individual components of the image line up with each other.

The ButtonSprite Class

The individual graphics are lined up in the source image so that I can render each of the button state graphics to the same X and Y coordinates on the screen. When it's time to draw the button on the screen, I select the appropriate graphic based on the current state of the button it represents. I wanted to be able to easily move the buttons around on the screen in case I decided to change my layout, so I created a simple C# class to represent the on-screen button. For each button, I need references to two Texture2D objects -- one for the pressed state and one for the released state. Since my source images contain multiple graphics, I can use the same texture for many of the buttons, but I'll still need some way to remember where the individual graphics are within the larger source image. To keep track of their locations, I'll use a Rectangle for each state.

private Texture2D m_TextureNormal;
public Texture2D TextureNormal
{
  get { return m_TextureNormal; }
  set { m_TextureNormal = value; }
}
private Rectangle m_RectNormal = Rectangle.Empty;
public Rectangle RectNormal
{
  get { return m_RectNormal; }
  set { m_RectNormal = value; }
}
private Texture2D m_TexturePressed;
public Texture2D TexturePressed
{
  get { return m_TexturePressed; }
  set { m_TexturePressed = value; }
}
private Rectangle m_RectPressed = Rectangle.Empty;
public Rectangle RectPressed
{
  get { return m_RectPressed; }
  set { m_RectPressed = value; }
}

I also need to know where to draw the button on the screen. To store the X and Y coordinates, I'll use a Vector2D structure.

public Vector2 Location = Vector2.Zero;

Using this basic class, I can place the ButtonSprite anywhere on the screen, and not worry about the details of how it's rendered. Each ButtonSprite will be rendered the same way -- using code similar to that found in the following snippet.

// bat is an XNA SpriteBatch class, btn is our custom ButtonSprite class
bat.Draw(btn.TexturePressed, btn.Location, btn.RectPressed, Color.White);

(Rather than writing new classes to support the other (non-digital) buttons, I reuse the properties of this class. Where I deviate from the obvious functionality, I've included comments in the source code. For example, the left trigger is an analog control that has no "pressed" state. The TextureNormal and RectNormal properties of the ButtonSprite are used to define the texture and bounds of the vertical slider graphic. Since there is no pressed state, I use the RectPressed structure to denote the bounds of the "usable" area of the slider -- the subset of the graphic that excludes the rounded edges, the transparent areas, and the drop shadow. This inner rectangle is used to place and constrain the vertical bar arrow graphic.)