Porting GAPI Games from Portrait to Square Screens
Brian Cross
Microsoft Corporation
April 2005
Applies to:
Windows Mobile 2003 Second Edition software for Pocket PCs
Summary: Windows Mobile 2003 Second Edition software and later support square screens. Learn about the various scenarios you may encounter when porting a full-screen game from portrait to square screen. (6 printed pages)
Download PSTicTacToe.msi from the Microsoft Download Center.
Contents
Introduction
Common Problems
Designing for Both Portrait and Square Screens
Conclusion
Introduction
In earlier versions of Pocket PCs, the Pocket PC screens had a standard portrait resolution of 240 x 320. While it is not a good idea to assume that an application will run on a specific resolution, developers wrote applications with this specific screen knowledge built into their applications. Many legacy applications support square resolutions (for example, 240 x 240) automatically through the use of scroll bars, but full-screen applications, namely games, do not. Game developers need to keep multiple resolutions in mind when they develop full-screen games if the games are to appear and run correctly on different screens.
This article describes some of the common problems encountered when porting a full-screen game from a portrait display to a square screen display and their possible solutions. Each solution has trade-offs, and its usefulness depends on the game.
Common Problems
Users experience a few common problems playing full-screen games on square screen devices:
- Clipped background and objects
- Scaled game play
- Input not scaled
The following game exemplifies these problems. The object of this game is to clear the bricks from the upper portion of the screen by moving the paddle at the bottom of the screen to hit the ball. If the ball hits a brick, the brick is removed.
Figure 1 shows how this game might appear on a portrait screen.
.gif)
Figure 1. Bricks game on a portrait screen
Clipped Background and Objects
When the resolution is hard coded for a portrait screen in a game, clipping can occur at the bottom of the game. Clipping makes the Bricks game unplayable because the user cannot see the paddle at the bottom of the screen, as shown in Figure 2.
.gif)
Figure 2. Clipped square screen
One solution to this problem would be to position the objects relative to the screen. In the case of the Bricks game, you can position the bricks relative to the top of the screen and the paddle relative to the bottom of the screen. Positioning the objects in relative screen coordinates eliminates the dependency the game has on screen resolution. However, this solution can result in another problem: scaled game play.
Scaled Game Play
For this example, the Bricks game uses relative positioning for its objects as described in the previous section. While relative positioning solves the clipping problem, the game becomes very difficult to play on a square screen device — there is not enough space between the paddle and the bricks, as shown in Figure 3.
.gif)
Figure 3. Scaled game play on a square screen
Relative positioning may work very well on some games; however, in the case of the Bricks game, it changes the game play significantly. The game shown in the figure is much more difficult to play because the player needs to react quicker than on a portrait device to hit the ball with the paddle. In some instances, it may be impossible to bring the paddle across the screen fast enough to hit the ball.
One way to solve this problem is to reduce the number of rows of bricks in the level (for example, from nine rows to five rows). The game will not play identically on square and portrait screens, but the user experience will be more enjoyable.
If loosing some detail is not a problem for your game, another solution is to scale the entire game to fit within the confines of the screen. The Bricks game has simple graphics, so if you scale the game vertically, its appearance is comparable to how it appears on a portrait device.
Input Not Scaled
The screen dimensions also affect the amount of space where the user can tap on the screen. Make sure that when you scale all of your graphics, you also take input into account. Failing to use the same method of scaling for input and images can result in your input coordinates not aligning with your images or being missed entirely.
For example, suppose that the graphics for the Bricks game were scaled, but the input coordinates were not scaled. If the game tries to process taps where y > 280 to position the paddle, the paddle will be unable to be moved on a square screen device that has the vertical resolution of 240 pixels.
Designing for Both Portrait and Square Screens
You can use other techniques to make games play well on both portrait and square screens. The success of these techniques depends on the game.
Bitmap Scaling
You can use scaling in many different ways to achieve a successful result. In the simplest way, you can scale everything to fit into the current screen. The Tic-Tac-Toe download sample scales all of the bitmaps according to the screen size. Near the top of tictactoe.h, you'll see:
#define DesignedWidth 240
#define DesignedHeight 240
You can use these values, which are the screen dimensions the game was designed on, to determine how much you need to scale the original graphics in the game according to the device's screen dimensions. The ScalingImage class compares the dimensions of the device's screen and the dimensions the developer designed the game to use when the game loads the bitmaps. If the designed resolution matches the actual resolution of the device, you don't need to scale the graphics.
Scaling bitmaps may not be the answer for high-detailed bitmaps or images that will not look appealing when they are stretched. In this case, you can create separate images for square and portrait screens.
Screen-Relative Coordinates
The Tic-Tac-Toe download sample demonstrates how to use screen-relative coordinates to draw the game board in the TicTacToe::DrawBoard method. Each of the lines are drawn at 1/3 increments horizontally and vertically, which split the screen into the nine quadrants necessary for a game of Tic-Tac-Toe. Using screen-relative coordinates enables the board to be drawn on any resolution.
Relative screen coordinates can also be used to test for input. By using the same rules as those used for the Tic-Tac-Toe board, you can accurately test for a tap in each quadrant of the game board.
Letterboxing
If, after you've scaled the game vertically, the game doesn't have a result that you like, you can scale the game proportionally to the height of the square screen and letterbox it. Figure 4 shows how the Bricks game might look if it was letterboxed.
.gif)
Figure 4. Bricks game scaled to square screen and letterboxed
Letterboxing has the advantage of presenting the same game play while losing some detail in your graphics. If you letterbox your game, you can use the extra space on the sides to display game information, or artwork to take advantage of the space. If your game is a side-scrolling game, you have the option to scale your game as previously described, but you can also use the extra space on the sides to widen what the player can see.
Panning
If scaling or letterboxing does not work for your game, panning may be a solution. Panning displays as much of your game as possible on the screen and uses a mechanism for moving the view if your game is bigger than the screen. Using scroll bars to read this article is a simple example of panning. You can only see a portion of this article in your browser's window, but when you want to see more, you use the scroll bar to display more text. You can also use the stylus, buttons on the device, and many other mechanisms to enable your users to pan.
You do not have to scale your images if you decide to enable panning, nor does your game display the extra space letterboxing adds. However, panning can affect game play. The Bricks game would be fairly difficult to play if the game required the user to scroll vertically to see where the ball was going. Panning would work very well for a turn-based game, where the extra time the user needs to look around the board does not affect game play.
Design for a Square Screen
Now that you know that square screens are supported in Windows Mobile Second Edition software and later, you can design games to work on square screen by default. When users play your games on a portrait screen, you can use the extra space at the bottom of the screen to display information that isn't crucial to game play, for example, the score. Figure 5 shows how you can use this space for the Bricks game.
.gif)
Figure 5. The left image shows the Bricks game on a square screen; the right image shows Bricks game on a portrait screen that uses the extra space for additional game information. Click the thumbnail for a larger image.
You can also shift the game to the bottom of the screen and display the additional game information at the top. You can decide the game design that works best for your game.
Conclusion
Most of the problems mentioned in this article occur because the developer assumed the user will play the game on a portrait screen resolution. When developers remove assumptions about the screen size, users can play games on both portrait and square screens. There are many techniques to write games that work well on both portrait and square screens, but the techniques that work best largely depend on the games themselves.