Undoubtedly you've seen some type of UI before while using your computer. Windows has plenty of resources built into the GDI, which ships as part of the operating system to build rich graphical user interfaces (GUIs). However, these interfaces don't translate well into the full-screen DirectX applications. When running your game in full screen, you don't want an extra window (that looks nothing like the rest of your application) popping up. At best, it's not appealing; at worst, it can cause your main application to minimize or have other problems.
To present a consistent look and feel throughout an application, most game developers actually design a completely new UI to meld with the rest of the games they are developing. Because the goal of this book is for you to learn to be a 3D game developer, you should do what they do. For this game, you will design some overly simple UI screens, consisting only of buttons and a background image. Because the game will have multiple screens (the main screen to start a new game, a select character screen, and a quit confirmation screen), create a base class that encompasses the major functionality of your screens. To do so, add a new code file to your project named gui.cs. This code file will contain all your UI screens when the game is complete.
Because this first class you are writing in this file will be the base for all subsequent UI screens, you should make it abstract so you don't attempt to accidentally create an instance of it yourself. Add the code in Listing 5.6 to your new code file now.
Listing 5.6. The Abstract UI Class
public abstract class UiScreen : IDisposable
{
// Constants
public static readonly Vector3 ObjectCenter = new Vector3();
public static readonly int SpriteColor = unchecked((int)0xffffffff);
protected const int SmallButtonWidth = 128;
protected const int SmallButtonHeight = 64;
protected const int LargeButtonWidth = 256;
protected const int LargeButtonHeight = 64;
protected Sprite renderSprite = null;
protected Texture backgroundTexture = null;
protected Rectangle backgroundSource;
// Screen size
protected int screenWidth = 0;
protected int screenHeight = 0;
// Should the object be centered?
private bool isCentered = false;
protected Vector3 centerUpper;
#region IDisposable Members
///
/// Clean up in case dispose isn't called
///
~UiScreen()
{
Dispose();
}
///
/// Clean up any resources
///
public virtual void Dispose()
{
GC.SuppressFinalize(this);
// Dispose the sprite
if (renderSprite != null)
{
renderSprite.Dispose();
}
renderSprite = null;
}
#endregion
}
You will need to add more to this class soon, but this section is the initial code that can actually be compiled successfully. You'll notice that first you need to declare two constants. They will be used during the rendering of your UI. The first one is the rotation center of your texture, but because you do not need to rotate it, an empty vector will suffice. The next parameter is the color you want to render the texture toa slightly misleading description because it's not the only factor determining color.
Construction Cue
The value specified in the color constant is equivalent to the solid color white; however, this doesn't mean that when you render your texture it will appear entirely in white.
The integer value of this constant has four separate color components, each a single byte, ranging from 0x0 to 0xff. The components are alpha, red, blue, and green, and in this constant, you are specifying "full power" to each. When the texture is rendered, the colors are not affected at all because you are specifying the full power for each. Say, however, that you declare the constant as 0xff00ffff instead. In this case, there is no red component, so when you render your textures, they have no red in them either. You can use this constant to add varying effects, but for this game, you want the images rendering as they are, with no changes.
The last of the constants are the sizes (both width and height) of the buttons you need for your UI. The two different sizes of buttons, large and small, are represented via these constants. The screens you create will have buttons and will use these constants to determine where (and how) to place them onscreen.
The first three nonconstant variable declarations deal directly with the items you will be rendering for the UI screens. The first is a Sprite object, which is a built-in object to Managed DirectX that greatly simplifies the process of rendering 2D images (sprites) in a 3D scene. This object is generic enough that it can render many different sprites, from many different textures in a single scene. Therefore, you need to include a texture that will be the background of your UI screen. If you do not want one, it can obviously be null. Finally, you might want more than one texture inside the same texture file. The rectangle variable stored here allows you to specify the location of the texture inside the main texture file. For UI screens, it will almost certainly be the same size as the main texture itself. The object is listed as protected, however, so any of the deriving classes can change it if they need to.
You also need to know the screen width and height for your UI screens. This information is mainly so you can calculate the position of various items on the screen (such as buttons) and have them appear in a similar location regardless of the resolution.
The last two variables determine whether the background of the UI screen should be centered onscreen or "stretched" to encompass the entire screen. You only need to know whether the centering should happen (the Boolean variable) and, if so, where the upper-left corner of the texture should go onscreen. This value is calculated during the object's construction, which you get to in just a moment.
Finally, this object needs a way to release the objects that it has created. Notice that the object implements the IDisposable interface, which is a convenient way to mark an object has resources it needs to clean up at a deterministic time. The only object that you actually create for this object is the Sprite class, so that is the only object you need to clean up when you call the Dispose method. You also notice that a SuppressFinalize method is called when you clean up the object. In C#, the Finalize method is declared with the destructor syntax from C/C++, as you saw in Listing 5.6 earlier. The only thing the destructor does is call the Dispose method. When an object goes out of scope and it is ready to be collected by the garbage collector, it first detects whether that object needs to be "finalized." If it does, it places the object on a separate queue, and the object survives the collection. Calling the SuppressFinalize method eliminates this scenario and is more efficient. A good rule of thumb is that if you implement IDisposable, you must always implement a destructor that calls your Dispose method and always call SuppressFinalize in your Dispose method.
Now then, how should you actually create an instance of this class? Well, because it is marked as abstract, you won't be able to do so directly; however, you should still add a constructor because your derived classes will call into the constructor of its base class. Add the constructor (and supporting method) in Listing 5.7 to your class.
|
