The CD-Rom for this book contains the code for all the Bitmap() constructors, as well as the destructor and the Free() method. The Bitmap() constructors are all very simple in that they call a corresponding Create() function to carry out the specifics of creating a bitmap based on a file, a resource, or a solid color. The default constructor doesn’t do much of anything other than initialize member variables; the idea behind this constructor is that you will eventually call the Create() method directly to load the Bitmap object with data. The destructor calls the Free() method to release the memory associated with the bitmap and clear the bitmap handle. The Free() method first checks to see if the bitmap handle, m_hBitmap, is valid in which case, it deletes the GDI bitmap object and clears out the handle. This is all that’s required to free the memory associated with the bitmap. Three Ways to Create a Bitmap There are three Create() methods in the Bitmap class that are fairly long, but you can access them from the CD-ROM. The first Create() method is responsible for loading a bitmap from a file. The method starts out by calling Free() to make sure that any previous bitmap data is cleaned up; this would apply if the same Bitmap object was being reused for a different bitmap. The file is then opened, and the resulting file handle is checked to make sure that the open proceeded without a hitch. The file header for the bitmap is then read from the file, and some checks are made to ensure that it was read without any problems. The file header contains information about the bitmap file itself, whereas the info header contains information about the bitmap. The info header is read next, and another error check is performed. With the headers properly read from the file, the Create() method is ready to get down to the real business of reading the bitmap data. The color table for the bitmap is read and followed by the image data. It is worth pointing out the usage of the CreateDIBSection() Win32 function, which is used to obtain a handle to a GDI bitmap object from raw bitmap data. This function ultimately makes it possible to read a bitmap and prepare it for use with the GDI. The last step in the Create() method is to free the bitmap memory if an error occurred while reading its data. The second Create() method supported by the Bitmap class is used to load a bitmap from a resource. This method follows roughly the same pattern as the first Create() method except in this case, the bitmap information is retrieved from a resource in memory, as opposed to being read from a file. The first step is to find the bitmap resource, load the resource into memory, and then lock the resource so that you can access its raw data. You don’t have to worry about the color table in this case because it is already included in the bitmap information. The width and height of the bitmap are stored next, and the image data is copied and used as the basis for obtaining a bitmap handle using CreateDIBSection(). Finally, the method concludes by performing some clean up in case an error occurred. The last of the Create() methods is the one that creates a blank bitmap in a solid color. This method is considerably different from the other two Create() methods because it has the luxury of not having to involve itself with any existing bitmap data. Instead, it uses a Win32 function called CreateCompatibleBitmap() to create an entirely new bitmap based on the supplied device context. Because the width and height are provided as arguments to the method, they are easy to store. Most of the work in the method has to do with filling the bitmap with a solid color. A compatible device context is first created to hold the bitmap for drawing, and then a solid brush in the specified color is created. The bitmap is then selected into the device context and filled with the solid brush. The graphics objects are then cleaned up to finish the job of this Create() method. Drawing the Bitmap The three Create() methods are by far the toughest parts of the Bitmap class, so the Draw() method will be a welcome relief. The Draw() method is actually similar to the third Create() method because it involves drawing a bitmap. However, in this case the bitmap is being drawn to an outside device context, as opposed to you drawing on the bitmap itself. The Draw() method accepts a device context and an XY coordinate as arguments. This reveals how simple it is to use the method to draw a bitmap. The first step in drawing the bitmap is ensuring that the bitmap handle is valid. If the handle checks out okay, a compatible device context is created to temporarily store the bitmap, and the bitmap is selected into the device context. This is an important step because drawing images always takes place from one device context to another. The bitmap is actually drawn using the Win32 BitBlt() function, which draws an image from a source device context to a specified location on a destination device context. Drawing a bitmap image is sometimes referred to as blitting, which is where the name BitBlt() comes from; you are blitting the image bits when you draw the image. The Draw() method finishes up by cleaning up the temporary device context.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
The x and y arguments to the Bitmap::Draw() method are specified relative to the device context the bitmap is being drawn on, and they indicate the upper left corner of the bitmap image. You now have a complete, fully working Bitmap class that is ready to be used in games to load and draw bitmap images. Let’s move on and take a look at a program example that puts the Bitmap class through its paces. Building the Slideshow Example Program Because you haven’t learned about how to process user input such as key strokes and mouse clicks, it still isn’t quite possible to create a game yet. However, the remainder of the hour guides you through the creation of a surprisingly practical example program that happens to serve as a great demonstration of the Bitmap class. I’m referring to the Slideshow program, which uses a series of bitmap images to present a slideshow. The Slideshow program takes advantage of the timing mechanism built into the game engine to provide a delay between moving to each successive image in a slideshow. The Bitmap class proves to be quite useful as a means of loading and drawing bitmaps from both files and resources. Before looking at the code for the Slideshow program, let’s quickly go over what it is supposed to accomplish: Create several bitmaps from files Create several bitmaps from resources Create a blank bitmap in a solid color Draw the bitmaps one at a time as part of a slideshow Time the presentation of the slides in the slideshow appropriately These requirements for the Slideshow program make it pretty clear what is supposed to happen. The only thing worth mentioning is that you wouldn’t normally mix the two approaches of loading bitmaps from files and resources. Generally speaking, it makes sense to commit to one approach or the other. In the case of a slideshow, it probably makes more sense to load bitmaps from files because you might want to change the images without recompiling the program. However, in this case it’s important to demonstrate the different uses of the Bitmap class. Writing the Program Code The header for the Slideshow program example is the best place to start in terms of getting acquainted with how it works. Check out Listing 5.2 to get a feel for what the header is all about. Don’t forget that you can access all of the code for the Slideshow program on the accompanying CD-ROM. Listing 5.2 The Slideshow.h Header File Imports a Few Header Files and Declares Several Global Variables 1: #pragma once 2: 3: //—————————————————————-4: // Include Files 5: //—————————————————————-6: #include 7: #include “Resource.h” 8: #include “GameEngine.h” 9: #include “Bitmap.h” 10: 11: //—————————————————————-12: // Global Variables 13: //—————————————————————-14: HINSTANCE _hInstance; 15: GameEngine* _pGame; 16: const int _iNUMSLIDES = 7; 17: Bitmap* _pSlides[_iNUMSLIDES]; 18: int _iCurSlide; Other than declaring a few global variables, there aren’t really any surprises here. The
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
Header Color table Image data The header contains information pertaining to the overall makeup of the bitmap, such as its width, height, number of bits per pixel (8 or 24), and so on. The color table contains the palette for the bitmap, which is the list of colors used throughout the image. The color table is extremely important for 8-bit bitmaps because it describes up to 256 colors used by pixels in the image. 24-bit bitmaps don’t need a color table because their colors are sufficiently described by the pixels themselves. The image data is where the actual pixels of the bitmap are stored. For example, if a bitmap is 10×12, it is 10 pixels across and 12 pixels down for a total of 120 pixels. If it is an 8-bit image, each pixel requires 8 bits (1 byte) to describe its color. So, the image data for this bitmap would consist of 120 bytes. To determine the color of each pixel, you would look up the byte value in the color table to see what color the pixel is. Of course, all this color table and image data stuff takes place automatically once you load an image and start using it with GDI functions. In other words, you only have to worry yourself with the inner workings of bitmaps when you first load the bitmap from a file or resource. Once loaded, you use a handle to a bitmap to draw it to a device context in much the same way as you drew graphics primitives to a device context in Hour 4, “Learning to Draw Basic Graphics.” Developing a Bitmap Class Although I could provide you with a handful of bitmap functions and set you on your way, bitmaps provide a perfect opportunity to take advantage of object-oriented programming. More specifically, you can create a class that includes all the code required to load and draw bitmaps, and then use the class to create bitmap objects that are much easier to use than if you had created several functions. Knowing this, the next couple of sections are devoted to the design and development of a bitmap class that you will use throughout the book in just about every example program from here on. Although the bitmap class is admittedly a little tricky in places, once created it is unbelievably easy to use. So, the idea is to create the class once with the knowledge that it will make your life incredibly easier in coming hours. How It Will Work The idea behind the Bitmap class is to provide a means of loading bitmaps from a file or resource, as well as drawing bitmaps to a device context. By incorporating these capabilities into a class, you’ll be able to create Bitmap objects in your games that are very easy to use and that hide the messy aspects of working with bitmaps. The Bitmap class has the following requirements: Loads a bitmap from a file Loads a bitmap from a resource Creates a blank bitmap Draws a bitmap to a device context Obtains the width and height of a bitmap The first two requirements are fairly obvious from the earlier discussion. The third requirement isn’t terribly important just yet, but you might find yourself wanting to create a blank bitmap for some reason, so why not have that capability? Besides, later in Hour 10, “Making Things Move with Sprites,” you’ll see how bitmaps are important for solving a flicker problem associated with animation; the solution requires blank bitmaps. The final requirement isn’t terribly important, but you might encounter a situation in which it’s necessary to determine the width and height of a bitmap. The information is readily available when you load a bitmap, so you might as well make it accessible from the Bitmap class. Putting the Code Together The code for the Bitmap class is admittedly complex in places, so I’m not suggesting that you expect to understand every nuance of it immediately. In fact, my goal isn’t really to make you a bitmap expert, which is practically a requirement in order to fully understand the Bitmap class. Even so, I don’t like the idea of accepting code at face value without any explanation, so I’d like for you to have a general understanding of what is going on in the Bitmap class. If I gloss over a section of code, just understand that the goal here is
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services
to get you using bitmaps in as little time as possible so that you can quickly move on to placing them in games. The Class Definition Win32 defines several data structures that pertain to bitmaps, so you’ll see several different ones throughout the Bitmap class code. One of these structures is BITMAPINFOHEADER, which is a structure that stores the header information associated with a bitmap. When you read a bitmap from a file or resource, you will store its header in a BITMAPINFOHEADER structure. Another important bitmap-related structure is RGBQUAD, which is used to store the four 8-bit components of a 32-bit color. Even though you’re working with 8-bit images, it’s still necessary to use the RGBQUAD structure for loading bitmaps. Speaking of 8-bit images, you know that an 8-bit bitmap requires up to 256 colors. The following code is for a custom structure named BITMAPINFO_256 that stores the header and a color table for a bitmap with 256 colors: struct BITMAPINFO_256 { BITMAPINFOHEADER bmiHeader; RGBQUAD bmiColors[256]; }; This structure will come in quite handy in a moment when you begin loading bitmaps. Before we get into that, however, let’s take a look at the Bitmap class definition, which is shown in Listing 5.1. Listing 5.1 The Bitmap Class Definition Includes the Member Variables and Methods Used to Manage Bitmaps 1: class Bitmap 2: { 3: protected: 4: // Member Variables 5: HBITMAP m_hBitmap; 6: int m_iWidth, m_iHeight; 7: 8: // Helper Methods 9: void Free(); 10: 11: public: 12: // Constructor(s)/Destructor 13: Bitmap(); 14: Bitmap(HDC hDC, LPTSTR szFileName); 15: Bitmap(HDC hDC, UINT uiResID, HINSTANCE hInstance); 16: Bitmap(HDC hDC, int iWidth, int iHeight, COLORREF crColor = 17: RGB(0, 0, 0)); 18: virtual ~Bitmap(); 19: 20: // General Methods 21: BOOL Create(HDC hDC, LPTSTR szFileName); 22: BOOL Create(HDC hDC, UINT uiResID, HINSTANCE hInstance); 23: BOOL Create(HDC hDC, int iWidth, int iHeight, COLORREF crColor); 24: void Draw(HDC hDC, int x, int y); 25: int GetWidth() { return m_iWidth; }; 26: int GetHeight() { return m_iHeight; }; 27: }; This listing reveals the overall makeup of the Bitmap class, including its member variables, constructors, destructor, and methods. The m_hBitmap member variable is used to store a handle to the bitmap, which is extremely important for drawing the bitmap to a device context using the GDI (line 5). The m_iWidth and m_iHeight member variables store the width and height of the bitmap, respectively (line 6). The Constructors and Destructor Notice in Listing 5.1 that there are three constructors in the Bitmap class in addition to the default constructor, each of which corresponds to one of the different approaches to creating bitmaps (lines 14 16)). Each Bitmap() constructor has a corresponding Create() method that is used to handle the work of loading the bitmap data and creating it as a GDI object (lines 20 22). The Free() method is a helper method used within the Bitmap class to free up the memory associated with the bitmap (line 9). The Draw() method shouldn’t be too surprising because it provides a means of drawing the bitmap to a device context (line 23). And finally, the GetWidth() and GetHeight() methods are simply used to obtain the width and height of the bitmap, respectively (lines 25 and 26).
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services
know when you are finished using them, and therefore they have a tendency to sit around wasting memory. In fact, undeleted graphics objects represent one of the common memory leaks in Windows programs, which are objects created by a program that are no longer used but still take up memory. Memory leaks are a very bad thing, and should be avoided at all costs. If you stay disciplined about cleaning up after yourself, you shouldn’t have too much trouble with graphics objects being inadvertently left in memory. Workshop The Workshop is designed to help you anticipate possible questions, review what you’ve learned, and begin learning how to put your knowledge into practice. The answers to the quiz can be found in Appendix A, “Quiz Answers.” Quiz 1: How is the Windows graphics coordinate system laid out? 2: What three colors form the components of a color in Windows? 3: If you use the GetDC() function to obtain a device context for drawing graphics, what function must you call to release the device context? 4: When you use the TextOut() function to draw text, what is the drawing position based on? Exercises 1. Create a pen in a color of your choosing, and then use it in the GamePaint() function of the Trippy program to draw grid lines in that color. 2. Modify the random color values used for the brush in the GameCycle() method of the Trippy program to see how different combinations work. For example, change the red component so that it is fixed at either 0 or 255, and then shorten the range of the green or blue component. Hour 5. Drawing Graphical Images We’ve all heard that a picture is worth a thousand words, and when it comes to computer games, they might be worth even more than that. Or to translate into nerd talk, a 640×480 image is worth 307,200 pixels. Okay, maybe nerd talk is something I should avoid. The point is that pictures (images) are extremely important in computer games because they provide the only means of incorporating artwork into the games. Sure, it’s nice to be able to draw lines, rectangles, and ellipses using GDI functions, but it would take a great deal of effort to draw a menacing creature out of graphics primitives. For that reason, we use graphical images as a means of visualizing graphical parts of games. This hour is all about showing you how to load and display graphical images. In this hour, you’ll learn: The fundamentals of bitmap images and why they are important in game programming About the inner workings of bitmap images How to develop an all-purpose bitmap class for use in games How to use the bitmap class to represent slide images in a slideshow program
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Clan Web Hosting services
The Basics of Bitmap Images Images in windows games are represented by bitmaps, which are rectangular graphics objects containing rows and columns of little squares called pixels. The name bitmap comes from the fact that the rows and columns determine how to map the pixels to the screen; the pixels themselves are composed of bits. Each pixel in a bitmap is a solid color. In fact, the only information associated with a pixel is its color. So, you can think of a bitmap as a rectangular arrangement of little colored squares. If you’re old enough to remember the popular Lite Brite toy, you definitely have an understanding of how a bitmap works. Lite Brite, which is still manufactured today by Hasbro, allows you to plug colored pegs into a black plastic grid to draw pictures. Two types of bitmaps are supported in Windows: device-dependent bitmaps and device-independent bitmaps. Device-dependent bitmaps are stored in a manner determined by a specific device, whereas device-independent bitmaps are stored in such a way that they can be displayed on any device. All the bitmaps you work with in this book are device-independent bitmaps, which are sometimes referred to as DIBs. Just keep in mind that when I refer to “bitmaps” from here on, I’m really referring to DIBs. You are probably familiar with bitmaps from the popular .BMP file type that is used throughout Windows. BMP is the standard image format used in Windows, and is also the format you’ll be using to work with bitmaps throughout this book. Although GIF and JPEG have certainly surpassed BMP as image formats for use on the Web, BMP is still used a great deal by Windows users. Not only that, but the BMP image format is considerably simpler and easier to work with at a programming level than GIF and JPEG. You can use the standard Paint program built into Windows to create and edit BMP files, or use Microsoft Photo Editor, which offers more features for working with photographic images. Although there is only one bitmap image format, not all bitmap images are created equal. First of all, the bitmap image format allows you to create bitmaps with varying numbers of colors. More specifically, you can create 8-bit bitmaps that use 256 (palletized) colors or 24-bit bitmaps that use more than 16 million colors. You can also create bitmaps that use a technique known as compression to help reduce the size of the bitmap file. To help keep the code simple, the bitmaps you use throughout the book are limited to 8-bit uncompressed bitmaps. This is very important to remember because other types of bitmaps won’t work with the bitmap code you develop in this hour. Regardless of how you create a bitmap, it ultimately ends up as a file with a .BMP file extension. To use such a bitmap in a Windows program, you have two options: Read the bitmap directly from the file Store the bitmap as a resource and read it from memory In the first option, the Windows program opens the bitmap file from disk and reads in the image data. It then uses the bitmap image data to create a GDI bitmap graphics object that can be drawn to a device context. The second option involves storing a bitmap as a resource within the executable program, which means that you don’t have to include the bitmap file with the program once it is compiled. The advantage to this option is that you are able to distribute your game as a single program file. Fortunately, the bitmap class you create later in this hour supports both approaches to using bitmaps. Peeking Inside a Bitmap In order to use bitmaps in your games, you must have a basic understanding of how they are put together. More specifically, you need to have knowledge of the inner structure of a bitmap because you must write code that reads this structure and extracts information about the bitmap. This is necessary so that you can create a bitmap object that can be drawn. You’ll be glad to know that bitmaps aren’t too terribly complicated, as is evident in Figure 5.1. Figure 5.1. The structure of a bitmap consists of three parts: a header, color table, and image data. The figure reveals that every bitmap consists of three basic parts:
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Clan Web Hosting services
10: _rcRectangle.bottom = _rcRectangle.top + _pGame->GetHeight() / 5; 11: } Any program that makes use of random numbers is responsible for seeding the built-in random number generator. This is accomplished in line 4 with the call to srand(). You’ll see this line of code in virtually all the program examples throughout the book because most of them involve the use of random numbers; random numbers often play heavily into the development of games. The remainder of the GameStart() function is responsible for setting the position and size of the initial rectangle to be drawn (lines 7 10). This rectangle is sized proportionally to the client area of the main program window, and positioned centered within the client area. I mentioned earlier that part of the Trippy program was to demonstrate the difference between drawing graphics in the GamePaint() function, as opposed to drawing them in GameCycle(). Listing 4.4 shows the code for GamePaint(), which in this case is responsible for drawing a bunch of grid lines as a background for the rectangles. Listing 4.4 The GamePaint() Function Draws a Grid of Lines to Fill the Entire Client Area 1: void GamePaint(HDC hDC) 2: { 3: // Draw grid lines as a background for the rectangles 4: const int iGridLines = 50; 5: for (int i = 1; i <= iGridLines; i++) 6: { 7: // Draw a horizontal grid line 8: MoveToEx(hDC, _pGame->GetWidth() * i / iGridLines, 0, NULL); 9: LineTo(hDC, _pGame->GetWidth() * i / iGridLines, _pGame->GetHeight()); 10: 11: // Draw a vertical grid line 12: MoveToEx(hDC, 0, _pGame->GetHeight() * i / iGridLines, NULL); 13: LineTo(hDC, _pGame->GetWidth(), _pGame->GetHeight() * i / iGridLines); 14: } 15: } The line drawing functions you learned about in this hour, MoveToEx() and LineTo(), are both used to draw a series of horizontal (lines 8 and 9) and vertical (lines 12 and 13) grid lines in the client area. Because these lines are being drawn in GamePaint(), they are not lost when the window is repainted. You can easily alter the number of grid lines by changing the value of the iGridLines variable (line 4). The GameCycle() function is where the actual rectangles are drawn, as shown in Listing 4.5. Listing 4.5 The GameCycle() Function Randomly Alters the Position of the Rectangle, and Then Draws It in a Random Color 1: void GameCycle() 2: { 3: HDC hDC; 4: HWND hWindow = _pGame->GetWindow(); 5: HBRUSH hBrush; 6: 7: // Randomly alter the position and size of the rectangle 8: int iInflation = (rand() % 21) - 10; 9: InflateRect(&_rcRectangle, iInflation, iInflation); 10: OffsetRect(&_rcRectangle, (rand() % 19) - 9, (rand() % 19) - 9); 11: 12: // Draw the new rectangle in a random color 13: hBrush = CreateSolidBrush(RGB(rand() % 256, rand() % 256, rand() % 256)); 14: hDC = GetDC(hWindow); 15: FillRect(hDC, &_rcRectangle, hBrush); 16: ReleaseDC(hWindow, hDC); 17: DeleteObject(hBrush); 18: } The GameCycle() function is interesting in that it does a few things you haven’t seen before. First of all, it uses two new Win32 functions, InflateRect() and OffsetRect(), to randomly alter the size and position of the previous rectangle. A random inflation value is first calculated, which is in the range of -10 to 10 (line 
. This value is then used as the basis for shrinking or growing the rectangle using the InflateRect() function (line 9). The rectangle is then offset by a random amount between -9 and 9 using the OffsetRect() function (line 10). With the new rectangle size and position figured out, the GameCycle() function moves on to determine a new fill color for it. This is accomplished by randomly selecting a color for a
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
new solid brush (line 13). If you recall, earlier I mentioned that you had to select a graphics object into a device context in order to use it. In this case, however, it’s possible to use a different rectangle function that allows you to directly provide the brush to be used. I’m referring to FillRect(), which accepts a handle to a device context, a rectangle, and a brush (line 15). After filling the rectangle with the solid brush, the device context is released (line 16) and the brush is deleted (line 17). Testing the Finished Product Now that you’ve worked through the code for the Trippy program example, I suspect that you’re ready to see it in action. Figure 4.6 shows the program running in all of its psychedelic splendor. Figure 4.6. The Trippy program example uses rapidly drawn rectangles to achieve a psychedelic effect. If you recall from the code, the Trippy program is smart enough to redraw the grid lines in the background if the window is minimized or resized, but it doesn’t take into account redrawing the rectangles. You can test this out by covering part of the window with another window, and then revealing the window again. The portion of rectangles not covered will be erased because of the repaint, but the part of the window that was visible will remain untouched. This redraw problem is not too difficult to fix. In fact, you solve the problem in Hour 5 when you build a slideshow program example using bitmap images. Summary This hour laid the groundwork for the game graphics that you develop and use throughout the remainder of the book. I know; you’re no doubt getting antsy because you’ve yet to touch on anything terribly game-specific. However, keep in mind that game programming, especially in Windows, involves a variety of different programming disciplines that must come together before a complete game can be built. Even so, hopefully you’re feeling a significant sense of accomplishment now that you know how to draw graphics with a little animated pizzazz using the GDI. Hour 5 continues along in the exploration of GDI graphics programming by uncovering the most important game development concept: graphical images. You find out about bitmap images, how they work, and how to load and display them in a Windows program. You also put your image handling skills to work by creating a slideshow that you can use to display storyboards for your games, or maybe just pictures from your last vacation. Q&A Q1: Why are color components specified in the range 0 to 255? A1: This has to do with the fact that Windows assumes that you are okay with using 8 bits to represent each color component. Allowing 8 bits for each component results in 256 possible shades of that component (0 255). 8 bits was chosen because 24-bit color is largely considered enough to display extremely high-quality color in graphical images. By combining three 8-bit color components, you arrive at 24-bit graphics. Of course, you might be familiar with the fact that many computers now take advantage of 32-bit color. 32-bit color adds an extra 8-bit channel to a standard 24-bit color to represent the transparency of the resulting pixel. In other words, a 32-bit color consists of three 8-bit color components, as well as an 8-bit value that indicates how transparent (or opaque) the image pixel is. Q2: Why is it necessary to delete graphics objects after creating them when drawing graphics? A2: Deleting graphics objects is very important because Windows doesn’t inherently
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
solid brushes, which allow you to fill in graphics shapes with a solid color. You create a solid brush using the Win32 CreateSolidBrush() function, which simply accepts a COLORREF structure. Following is an example of creating a purple brush: HBRUSH hPurpleBrush = CreateSolidBrush(RGB(255, 0, 255)); Notice in this code that a value of 255 is used to set the red and blue components of the color, which is how you are achieving purple in the final mixed color. Now that you have a handle to a brush, you’re ready to select it into a device context and begin painting with it. Selecting Pens and Brushes In order to use a pen or brush you’ve created, you must select it into a device context using the Win32 SelectObject() function. This function is used to select graphics objects into a device context, and applies to both pens and brushes. Following is an example of selecting a pen into a device context: HPEN hPen = SelectObject(hDC, hBluePen); In this example, the hBluePen you just created is selected into the device context. Also notice that the previously selected pen is returned from SelectObject() and stored in hPen. This is important because you will typically want to restore GDI settings to their original state when you’re finished painting. In other words, you want to remember the original pen so that you can set it back when you’re finished. Following is an example of restoring the original pen using SelectObject(): SelectObject(hDC, hPen); Notice that it is no longer important to remember the return value of SelectObject() because you are restoring the original pen. One more important task related to creating pens is that of deleting graphics objects that you create. This is accomplished with the DeleteObject() function, which applies to both pens and brushes. It is important to delete any graphics objects that you create after you’ve stopped using them and they are no longer selected into a device context. Following is an example of cleaning up the blue pen: DeleteObject(hBluePen); Selecting and deleting brushes is very similar to selecting and deleting pens. Following is a more complete example to illustrate: HBRUSH hBrush = SelectObject(hDC, hPurpleBrush); // *** Do some drawing here! *** SelectObject(hDC, hBrush); DeleteObject(hPurpleBrush); In this example, the purple brush from the previous section is selected into the device context, some drawing is performed, and the old brush is restored. The purple brush is then deleted to clean up everything. Building the Trippy Example Program At this point, you’ve seen bits and pieces of GDI graphics code, and you’ve learned how to carry out basic drawing operations with a variety of different graphics shapes. You’ve also learned how to tweak the appearance of those shapes by creating and using different pens and brushes. You’re now ready to put what you’ve learned into a complete example program that demonstrates how to draw graphics in the context of a game. Okay, you’re not really creating a game in this hour, but you are using the game engine to draw some pretty neat graphics. The example program I’m referring to is called Trippy, and its name comes from the fact that it displays a psychedelic series of rectangles in different sizes and colors. The idea behind the Trippy program is to draw a random rectangle in each cycle of the game engine. Although the rectangles are drawn outside of the GamePaint() function in response to a game cycle, it is still important to demonstrate how to draw within GamePaint() so that the drawing isn’t lost when the window is minimized or hidden. For this reason, Trippy draws a grid of lines in GamePaint() to demonstrate how graphics drawn in this function are retained even if the window must be repainted. The actual rectangles are drawn in
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Clan Web Hosting services
GameCycle(), which means that they are lost if the window is repainted. Let’s take a look at how the code actually works for this example program. Writing the Program Code The fun begins in the Trippy program example with the header file, Trippy.h, which is shown in Listing 4.1. All of the code for the Trippy program is available on the accompanying CD-ROM. Listing 4.1 The Trippy.h Header File Imports a Few Header Files and Declares the Global Game Engine Pointer, as Well as the Previous Rectangle That Was Drawn 1: #pragma once 2: 3: //—————————————————————-4: // Include Files 5: //—————————————————————-6: #include 7: #include “Resource.h” 8: #include “GameEngine.h” 9: 10: //—————————————————————-11: // Global Variables 12: //—————————————————————-13: GameEngine* _pGame; 14: RECT _rcRectangle; This code isn’t too mysterious. In fact, the only real difference between this header and the one you saw for the Game Engine example in the previous hour is the declaration of the _rcRectangle global variable (line 14). This rectangle stores the previously drawn rectangle, which allows you to alter its position randomly for the next rectangle. The end result is that the rectangles tend to randomly drift around the screen, as opposed to popping up in random locations all over the place. Moving right along, remember that we’re now taking advantage of the game engine to simplify a great deal of the work in putting together programs. In fact, all that is really required of the Trippy program is to provide implementations of the core game functions. Listing 4.2 contains the code for the first of these functions, GameInitialize(). Listing 4.2 The GameInitialize() Function Creates the Game Engine and Sets the Frame Rate to 15 Cycles Per Second 1: BOOL GameInitialize(HINSTANCE hInstance) 2: { 3: // Create the game engine 4: _pGame = new GameEngine(hInstance, TEXT(”Trippy”), 5: TEXT(”Trippy”), IDI_TRIPPY, IDI_TRIPPY_SM); 6: if (_pGame == NULL) 7: return FALSE; 8: 9: // Set the frame rate 10: _pGame->SetFrameRate(15); 11: 12: return TRUE; 13: } The GameInitialize() function is responsible for creating the game engine (lines 4 and 5) and setting the frame rate for it (line 10). In this case, the frame rate is set at 15 cycles per second (frames per second), which is plenty to demonstrate the psychedelic nature of the rectangles. Following up on GameInitialize() is GameStart(), which actually gets things going. Listing 4.3 shows the code for the GamStart() function. Listing 4.3 The GameStart() Function Seeds the Random Number Generator and Establishes an Initial Rectangle 1: void GameStart(HWND hWindow) 2: { 3: // Seed the random number generator 4: srand(GetTickCount()); 5: 6: // Set the position and size of the initial rectangle 7: _rcRectangle.left = _pGame->GetWidth() * 2 / 5; 8: _rcRectangle.top = _pGame->GetHeight() * 2 / 5; 9: _rcRectangle.right = _rcRectangle.left + _pGame->GetWidth() / 5;
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Clan Web Hosting services