Clan Web Sites, Online Games and Hosting

The idea behind this juiced up approach to keyboard event handling is that instead of sitting around waiting for Windows to eventually send you a keyboard message, you constantly check the keyboard to see if any of the keys you’re interested in have been pressed. If so, the game instantly springs into motion and efficiently responds to the key press. If no key is pressed, the game engine hums along with no interruptions. The strategy here is to basically take keyboard processing into your own hands and bypass the standard Windows approach, which ultimately results in much more responsive keyboard controls for your games. You learn how to implement this speedy keyboard handler in code a little later in the hour. For now, let’s take a look at how to respond to mouse events. Tracking the Mouse When you move the mouse, a series of events is set off that is very similar to those set off by the keyboard. In fact, the Win32 API includes a series of mouse messages that are used to convey mouse events, similar to how keyboard messages convey keyboard events. You learned in the previous section that the Win32 keyboard messages aren’t up to the task of providing efficient input for games. Fortunately, the same cannot be said of the mouse messages. It turns out that the built-in Win32 approach to handling mouse events via messages works out just fine for games. Following are the mouse messages used to notify Windows programs of mouse events: WM_MOUSEMOVE Any mouse movement WM_LBUTTONDOWN Left mouse button pressed WM_LBUTTONUP Left mouse button released WM_RBUTTONDOWN Right mouse button pressed WM_RBUTTONUP Right mouse button released WM_MBUTTONDOWN Middle mouse button pressed WM_MBUTTONUP Middle mouse button released The first mouse message, WM_MOUSEMOVE, lets you know whenever the mouse has been moved. The remaining messages relay mouse button clicks for the left, right, and middle buttons, respectively. Keep in mind that a mouse button click consists of a button press followed by a button release; you can implement a mouse dragging feature by keeping track of when a mouse button is pressed and released, and watching for mouse movement in between. Regardless of whether you’re interested in mouse movement or a mouse button click, the important factor regarding the mouse is where the mouse cursor is located. Fortunately, the mouse cursor position is provided with all the previously mentioned mouse messages. It’s packed into the lParam argument that gets sent to the GameEngine::HandleEvent() method. Following is the prototype for this method, just in case you forgot: LRESULT GameEngine::HandleEvent(HWND hWindow, UINT msg, WPARAM wParam, LPARAM lParam); If you recall, the wParam and lParam arguments are sent along with every Windows message, and contain message-specific information. In the case of the mouse messages, lParam contains the XY position of the mouse cursor packed into its low and high words. Following is an example of a code snippet that extracts the mouse position from the lParam argument in a WM_MOUSEMOVE message handler: case WM_MOUSEMOVE: WORD x = LOWORD(lParam); WORD y = HIWORD(lParam); return 0; The wParam argument for the mouse messages includes information about the mouse button states, as well as some keyboard information. More specifically, wParam lets you know if any of the three mouse buttons are down, as well as whether the Shift or Control keys on the keyboard are being pressed. In case you don’t see it, the wParam argument used in conjunction with WM_MOUSEMOVE provides you with enough information to implement your own Doom strafing feature! Following are the constants used with the mouse messages to interpret the value of the wParam argument: MK_LBUTTON Left mouse button is down MK_RBUTTON Right mouse button is down MK_MBUTTON Middle mouse button is down MK_SHIFT Shift key is down

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services

MK_CONTROL Control key is down You can check for any of these mouse constants to see if a button or key is being pressed during the mouse move. The constants are actually flags, which means that they can be combined together in the wParam argument. To check for the presence of an individual flag, you must use the bitwise AND operator (&) to see if the flag is present. Following is an example of checking wParam to see if the right mouse button is down: if (wParam & MK_RBUTTON) // Yep, the right mouse button is down! This code shows how to use the bitwise AND operator (&) to check for individual flags. This is a technique you use in Hour 7 to check the state of a joystick. Revamping the Game Engine for Input Because we’ve already built a game engine for use in carrying out the various tasks associated with game management, it only makes sense to incorporate user input handling into the game engine. Granted, a certain aspect of handling user input is game specific, and therefore must be handled in the code for each individual game. However, there are some general aspects of keyboard and mouse handling that you can incorporate into the game engine to simplify the work required of specific game code. If you recall, the idea behind the game engine is to provide a certain degree of game functionality in a self-contained class, and then delegate game specific tasks to a series of functions that each game is responsible for providing. For example, the GamePaint() function must be provided in a game to draw the game screen. Although the game engine doesn’t technically provide code for the GamePaint() function, it does make sure that it gets called whenever the game window needs to be painted; it’s up to each game to provide the actual code for GamePaint(), which makes sense because every game draws itself differently. Similar functions need to be added to the game engine to provide games with a means of handling user input. The next couple of sections guide you through modifications to the game engine to add support for keyboard and mouse input handling. Adding Keyboard Support Earlier this hour, you found out that the standard Windows approach to keyboard handling with messages simply isn’t good enough for games. A much better way to handle keyboard input is to repeatedly check the state of the keyboard for specific key presses, and then react accordingly. Using this strategy, much of the burden of keyboard input handling is passed on to the game code, which means that the game engine is primarily responsible only for calling a keyboard handler function to give the game a chance to respond to key presses. Following is what this function looks like: void HandleKeys(); The HandleKeys() function must be provided as part of the game code, and therefore isn’t included in the game engine. If you don’t want your game to support keyboard input, you can just leave the HandleKeys() function blank. Of course, the game engine must make sure that the HandleKeys() function gets called rapidly enough to give your games a responsive feel. This is accomplished in the WinMain() function within the game engine code. Following is the change made to this function: if (iTickCount > iTickTrigger) { iTickTrigger = iTickCount + GameEngine::GetEngine()->GetFrameDelay(); HandleKeys(); GameCycle(); } The only change to the WinMain() code is the new call to the HandleKeys() function. Notice that this call occurs just before the GameCycle() function, which means that a game gets a chance to respond to keyboard input before every game cycle. Don’t forget; the specifics of handling keyboard input are carried out in each specific game when you create your own HandleKeys() function. You find out how to do this later in the hour.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services

your goal as well. Different game players like different things, and the safest solution is to hedge your bets and support all input devices whenever possible. By following this simple rule, you can develop games that can be appreciated and enjoyed by a broader group of game players. Joysticks Although not quite as standard as keyboards and mice, joysticks nonetheless represent a very common component of modern computer systems. Joysticks are in many ways a throwback to video games of old many of which relied heavily on joysticks for controlling characters, spaceships, and other game objects. Joysticks come in both digital and analog form, although the difference between the two isn’t terribly important from a programming perspective. The primary thing to consider when assessing the role of joysticks in games is whether it makes sense to play the game with a joystick. In other words, does the movement in the game lend itself to being carried out with a vertical stick (or flat game pad), as opposed to using keyboard keys or a mouse? Of course, it’s not a bad idea to support multiple input devices in which case you might opt to include joystick support just to be flexible. Most game pads count as joysticks because they provide a similar functionality in terms of providing a multidirectional control for movement, as well as several buttons. From a programming perspective, Windows doesn’t distinguish between joysticks and game pads, which is a good thing for you. It’s worth mentioning that some games out there seem to be expressly designed for being played with joysticks. For one, the extremely popular game Halo on the XBox console system uses a unique feature that would be difficult to replicate with a keyboard or mouse. Halo allows you to press the joystick inward to activate a rifle scope on your gun. So, if you see some bad guys off in the distance, you can push in on the joystick to zoom with the scope and pick them off one by one. The scope/zoom feature in Halo is an excellent example of an ingenious game feature made possible by a specific type of input device. Of course, the XBox controller had to include a joystick with the push feature in order for Halo to work, so Microsoft deserves some credit on the hardware side of things. Assessing Keyboard Input for Games You know that messages are used heavily throughout the Win32 API to deliver notifications regarding things such as window creation, window destruction, window activation, window deactivation, and so on. You may be glad to find out that this same messaging system is used to deliver notifications regarding key presses on the keyboard. More specifically, the Win32 API defines messages called WM_KEYDOWN and WM_KEYUP that inform you whenever a key has been pressed or released, respectively. These two messages are quite easy to handle in a Windows program, and I’d love to show you how to use them, but there’s a problem. The problem is that the standard Windows messaging system is painfully slow when it comes to delivering keyboard messages. Because games rely heavily on responsive controls, it simply isn’t acceptable to work with the Windows keyboard messages. The bottom line is that none of your games can support keyboards. Okay, I’m kidding. The truth is that there is always a workaround in game programming, and the slow keyboard messaging problem presents a perfect opportunity for a workaround. If you recall, the timing for the Game Engine was established back in Hour 3, “Creating an Engine for Games,” in the WinMain() function. If you recall, the WinMain() function included a program loop that repeated over and over, processing messages for the program. When the function wasn’t processing messages, it spent its time running through cycles of the game engine. In other words, the game engine takes advantage of idle time in the main program loop to carry out its game-related tasks. This idle time is what you can use to your advantage when processing key presses and releases on the keyboard. The concept of “idle time” with respect to the WinMain() function is a little misleading. When you consider that games don’t typically process very many messages from Windows, the vast majority of the time spent by a game program is idle time, or time not responding to standard Windows messages. This time can therefore be put to use running the game engine, which is what I mean when I talk about running through the game cycles during idle time.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services

Input devices are the physical hardware that allows a user to interact with a game. Input devices all perform the same function: converting information provided by the user into a form understandable by the computer. Input devices form the link between the user and your game. Even though you can’t directly control the input device hardware, you can certainly control how it is interpreted in your game. As I mentioned earlier, there are three primary types of user input devices: The keyboard The mouse Joysticks In case you’re wondering, trackballs are functionally very similar to mice and are often treated just like mice from a software perspective. In fact, the Win32 API doesn’t discern between trackballs and mice, so the mouse support in your games indirectly supports trackballs as well. The next few sections get you acquainted with these devices and their relationship to game user input. The Keyboard The keyboard has been the computer input device of choice since its inception. Although mice, joysticks, flight sticks, and many other user input devices have brought extended input capabilities to the game player, none is as established as the keyboard. At the bare minimum, you can always count on a game player having a keyboard. The keyboard is a surprisingly useful input device for a wide range of games. The sheer amount of keys alone gives the keyboard appeal for games that require a wide variety of user input. Even more useful in the keyboard is the natural feel of pressing keys for games requiring quick firing and movement. This usefulness is evident in the amount of arcade games that still use buttons, even when powerful digital joysticks are readily available. Keys (or buttons) simply are easier to use in many games, including those with many input combinations. When assessing the potential use of the keyboard in a game, try to think in terms of the most intuitive user interface possible. For example, any game involving the player moving an object around would benefit from using the arrow keys. A good example is the classic 3D shooter Doom, which makes creative use of a keyboard-specific feature that greatly enhances the playability of the game. The left and right arrow keys, when used alone, rotate the player left and right in the game world. However, when the Shift key is held down, the same left and right arrow keys cause the player to strafe, meaning that the player moves sideways without changing direction. This seemingly small enhancement to the keyboard controls goes a long way when playing the game. When you’re deciding on specific keys to use for keyboard controls in your game, consider the potential limitations on players using other platforms or hardware configurations. For example, I primarily use a Windows XP PC equipped with a Microsoft Natural keyboard. If you aren’t familiar with these keyboards, they are split down the middle for ergonomic reasons. If you don’t use one of these keyboards, it might not occur to you that key combinations near the center of the keyboard will be separated a few inches for people like me. So, remember that if you use the G and H keys (or other middle keys) in your game, and it plays well for you, it might not work out so well for players with different keyboards. The most common keys used in games are the arrow keys. If you’re writing an action game, you might also have keys for firing and selecting between weapons. When you’re deciding on the keys to use, keep in mind things like the creative usage of the Shift key in Doom. If you can limit the number of primary game control keys by making use of a secondary key such as Shift, you’ve made the game controls that much easier to use. The Mouse Although the keyboard is firmly in place as the most necessary of user input devices, the graphical nature of modern computers establishes the mouse, or a similar pointing device, as a standard input device as well. The mouse, however, doesn’t share the wide range of input applications to games that the keyboard has. This stems from its primary usage as a point-and-click device; if you haven’t noticed, a lot of games don’t follow the point-and-click paradigm. In regard to gaming, the usefulness of the mouse is dependent totally on the type of game and, therefore, the type of user interaction dictated by the game. However, as quickly as some people write off the mouse as being a useless interface in some games, others praise the fine control it provides. Again, a good example is Doom. Personally, I think the keyboard is much more responsive than the mouse, and the keyboard enables me to get around faster and with more control. But I have friends who feel lost playing the game without a mouse. Clearly, this is a situation in which the game designers saw a way to provide support for both the keyboard and mouse. With the exception of the most extreme cases, this should be

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services

keyboard and mouse, whereas Hour 7, “Improving Input with Joysticks,” tackles joysticks. In this hour, you’ll learn: Why user input is so important in games How each of the major types of input devices impact games How to efficiently detect and respond to keyboard input How to handle mouse input How to create a program with an animated graphical object that you can control with the keyboard and mouse Gaming and User Input User input is the means by which the user interacts with a game. Considering the fact that user input encompasses the entire communications between a player and a game, you would think that designing an intuitive, efficient interface for user input would be at the top of the list of key game design elements. However, that isn’t always the case. With all the hype these days surrounding real-time, texture-mapped 3D graphics engines and positional 3D audio in games, effective user input support is often overlooked. In fact, user input is perhaps the most overlooked aspect of game design, which is truly a tragedy. It’s a tragedy because user input support in a game directly impacts the playability of the game; and when the user input isn’t effective, the play suffers. You see, I’m from the old school of game players, and I still remember paying homage to the gods of gaming with my hard earned allowance in arcades, well before there was an option of playing anything other than Pong at home (see the opener for Hour 1, “The Basics of Game Creation”). In return for my quarter offerings, the game gods usually provided me with incredibly fun games that usually had to survive on their playability alone. Because the hardware at that time simply couldn’t provide a very high level of graphic and sound intensity, game developers were forced to make up for it with game play. Of course, they didn’t consider their focus on playability as making up for anything; with the limited graphics and sound capabilities at the time, they didn’t have an option. Let me give you a quick example of what I’m talking about in regard to playability and user input. One of my all-time favorite games is Ring King, which is a boxing game for the Nintendo Entertainment System (NES). Ring King is definitely considered “old” by current gaming standards possibly even ancient. Compared to current games, it has weak graphics, animation, and sound. However, I still play the game simply because it plays so well. And that playability is largely based on how the game handles user input; it allows for very subtle timing when you punch and dodge, which goes a long way in a boxing game! Since then, I’ve tried to find a modern replacement for Ring King, but I’ve had no luck. When I get beyond the fancy graphics and sound, I start missing the responsiveness of the controls in my old favorite. I’m still looking, though. Lest you think I’m being overly critical of current games, plenty of recent games have incredible user input support, along with awesome graphics and sound. However, an equal number of recent games have killer graphics and sound, but little substance when it comes to playability and user input. These types of games might be visually stunning and fun to listen to, but they rarely have any lasting appeal beyond the initial “Wow!” Now, let me step down from the soapbox and get to the real point, which is that you should carefully plan the user input for your games just like you carefully plan the graphics, sound, and game logic. This doesn’t mean only deciding between supporting a keyboard or a mouse for the user interface. It means putting some real thought into making the user interface as intuitive as possible. You want the controls for the game to feel as natural as possible to the player. Taking a Look at User Input Devices

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Clan Web Hosting services

you’ll find out how bitmaps don’t always originate with bitmap files or resources. Besides, you might want to create a bitmap as a background for a game that gets customized specifically for the game. For example, consider a space background with several planets. You might create a solid black bitmap and then draw the planets on top of it. 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: Why would you want to store bitmaps as resources in an executable program, as opposed to using them straight from files? 2: What is the purpose of the color table in a bitmap? 3: What kind of bitmap is supported by the Bitmap class created in this hour? Exercises 1. Modify the Slideshow program example so that it uses your own bitmap images as slides. Make sure to change the number of slides in the program to accommodate how many you’re using. Also, if you choose to use a different size for your images, simply change the size of the game screen to match when you create the game engine. 2. Alter the frame rate of the Slideshow program example to see how it impacts the speed of the slide images being drawn. You should notice the program reach a maximum speed, after which it doesn’t really make any difference how fast you set the rate. In other words, there are limits as to how fast of a frame rate you can get. Part II: Interacting with Game Players Hours 6 Controlling Games with the Keyboard and Mouse 7 Improving Input with Joysticks 8 Example Game: Brainiac Hour 6. Controlling Games with the Keyboard and Mouse All the graphics in the world wouldn’t save a game if you couldn’t interact with it. There’s a name for a game with no user interaction it’s called a screensaver! User interaction can come from several different places, but you can generally break it down into a short list of user input devices: the keyboard, the mouse, and joysticks. The keyboard and mouse are by far the two most standard user input devices on computers, and are just about guaranteed to be supported on all personal computers. Joysticks are also quite common, but aren’t nearly as commonplace as keyboards and mice. So, you should consider the keyboard and mouse the two most important game input devices, with joysticks following behind in third place. This hour focuses on interacting with the user via the

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Clan Web Hosting services

window needs to be repainted. The trick is to force a repaint of the window, which is possible using the Win32 InvalidateRect() function. The GameCycle() function calls InvalidateRect() to force a repaint and display the new slide bitmap (line 16). The second argument to InvalidateRect() indicates that the entire client area is to be repainted, whereas the last argument indicates that it isn’t necessary to erase the client area before repainting. Assembling the Resources You’ve now seen the vast majority of the code for the Slideshow program example, which hopefully wasn’t too overwhelming seeing as how the Bitmap class removed a great deal of the work required to display images. The only remaining code to address involves the bitmap resources used in the program. To demonstrate how to use bitmaps as resources, I decided to go ahead and include all the slide bitmaps as resources, even though the program only loads three of them as resources. Listing 5.7 contains the code for the Resource.h header file, which defines unique resource IDs for the bitmaps. Listing 5.7 The Resource.h Header File Contains Resource IDs for the Icons and Bitmap Images in the Slideshow Program Example 1: //—————————————————————-2: // Icons Range : 1000 - 1999 3: //—————————————————————-4: #define IDI_SLIDESHOW 1000 5: #define IDI_SLIDESHOW_SM 1001 6: 7: //—————————————————————-8: // Bitmaps Range : 2000 - 2999 9: //—————————————————————-10: #define IDB_IMAGE1 2000 11: #define IDB_IMAGE2 2001 12: #define IDB_IMAGE3 2002 13: #define IDB_IMAGE4 2003 14: #define IDB_IMAGE5 2004 15: #define IDB_IMAGE6 2005 This code reveals how resources are typically organized according to type. It also shows how the numbers used to distinguish between resources are specified as ranges for each resource type. This is primarily an organizational issue, but it does help to keep things straight. The bitmap resource IDs are created in lines 10 15, and are pretty straightforward. Notice that there is no ID for the seventh bitmap, the solid color bitmap, because it is a blank bitmap that doesn’t derive from a resource. The bitmap resource IDs come into play in the Slideshow.rc resource script, which is shown in Listing 5.8. Listing 5.8 The Slideshow.rc Resource Script Contains the Resources for the Slideshow Program Example, Including the Bitmap Resources 1: //—————————————————————-2: // Include Files 3: //—————————————————————-4: #include “Resource.h” 5: 6: //—————————————————————-7: // Icons 8: //—————————————————————-9: IDI_SLIDESHOW ICON “Slideshow.ico” 10: IDI_SLIDESHOW_SM ICON “Slideshow_sm.ico” 11: 12: //—————————————————————-13: // Bitmaps 14: //—————————————————————-15: IDB_IMAGE1 BITMAP “Image1.bmp” 16: IDB_IMAGE2 BITMAP “Image2.bmp” 17: IDB_IMAGE3 BITMAP “Image3.bmp” 18: IDB_IMAGE4 BITMAP “Image4.bmp” 19: IDB_IMAGE5 BITMAP “Image5.bmp” 20: IDB_IMAGE6 BITMAP “Image6.bmp” This resource script reveals how bitmap resources are included using the BITMAP resource type. Including bitmaps in a resource script is similar to including icons, and involves specifying the resource ID, resource type, and image file for each bitmap (lines 15 20). By including bitmaps in the resource script, you are alleviating the need to include separate

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Clan Web Hosting services

bitmap image files with the completed program. Testing the Finished Product The Slideshow program example is definitely the most practical program you’ve seen thus far. You can use the program to display any kind of slideshow of images that you want, provided that you store the images as 8-bit (256 color) bitmaps with no compression. To demonstrate the practicality of the program, I decided to put together a slideshow of photos from a recent trip I took to Arizona. Figure 5.2 shows a photo of a jackrabbit, which happens to be the opening slide in the slideshow. Figure 5.2. The Slideshow program example demonstrates how to display bitmap images, and also serves as a good way to relive a vacation. You’ll notice that every three seconds the slide will change, eventually leading to the end of the slideshow, after which it wraps around and begins with the first image again. Figure 5.3 shows another slide in the slideshow to demonstrate how the slides are changed. Figure 5.3. Each successive slide in the Slideshow program is separated by a three second delay. Whether or not you decide to place your family album of digital photographs into a Slideshow program of your own, you’ve hopefully gained an appreciation of bitmaps and how to work with them at the programming level. You also now have the Bitmap class, which you will be using heavily throughout the remainder of the book. Summary This hour tackled one of the most important topics of game development by introducing you to bitmap images, as well as how they are loaded and displayed in a Windows program. You first analyzed the inner structure of a bitmap, which was necessary in order to gain an understanding of what it takes to write code that can load a bitmap from a file or resource. You then used this knowledge to assemble a bitmap class that handles the messy details of creating bitmaps based on files, resources, or solid colors. The hour concluded by demonstrating how to use the bitmap class in a practical example program. This hour concludes the first part of the book, which laid the groundwork for game programming in Windows. The next part of the book addresses the all-important topic of interacting with game players. You find out how to receive and process user input from a keyboard, mouse, and joystick, as well as creating your first complete game. Q&A Q1: Why isn’t the Bitmap class in this hour more flexible in supporting other image types? A1: There are two reasons for the Bitmap class being limited in its support for image types. The first reason has to do with coding simplicity it takes considerably more complex code to handle multiple image types. Because the goal of this book is to get you creating games with minimal distractions, keeping the Bitmap class as simple as possible is extremely important. The second reason has to do with performance using an image format with fewer colors results in faster games. This is because less colors results in less information being transferred when an image is drawn to a device context, which means speedier draws. Performance is a critical factor in virtually all games, so sacrificing zillions of colors in favor of a smoother and quicker game is usually worth the trade-off. Q2: What’s the purpose of the third Create() method in the Bitmap class? A2: The third Create() method in the Bitmap class is used to create a blank bitmap in a solid color, which might not seem very useful at first. However, later on in the book,

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Clan Web Hosting services

13: // Set the first slide 14: _iCurSlide = 0; 15: } 16: 17: void GameEnd() 18: { 19: // Cleanup the slide bitmaps 20: for (int i = 0; i < _iNUMSLIDES; i++) 21: delete _pSlides[i]; 22: 23: // Cleanup the game engine 24: delete _pGame; 25: } The GameStart() function takes on the responsibility of creating the slide bitmaps. It first obtains a device context, which is necessary to create any bitmaps (line 4). It then loads several bitmaps from files (lines 5 7), as well as loading a few bitmaps as resources (lines 8 10). The final bitmap is a solid color blank bitmap that is created using the third Bitmap() constructor (line 11). After creating the bitmaps, the GameStart() function sets the current slide to the first bitmap (line 14). The GameEnd() function simply cleans up the slide bitmaps by stepping through the array and deleting them one at a time (lines 20 and 21). This is an important part of the Slideshow program because you definitely want to clean up after yourself. The current slide is drawn to the game screen in the Slideshow program thanks to the GamePaint() function, which is shown in Listing 5.5. Listing 5.5 The GamePaint() Function Simply Draws the Current Slide Bitmap 1: void GamePaint(HDC hDC) 2: { 3: // Draw the current slide bitmap 4: _pSlides[_iCurSlide]->Draw(hDC, 0, 0); 5: } The GamePaint() function is probably simpler than you might have expected. Here, you’re really getting to see how helpful the Bitmap class is because it allows you to draw a bitmap image with a very simple call to the Draw() method (line 4) of the Bitmap object. The _iCurSlide global variable is used to make sure that the appropriate slide is drawn. The GameCycle() function is responsible for moving to the next slide after imposing a small delay, as shown in Listing 5.6. Listing 5.6 The GameCycle() Function Steps Through the Slides After Waiting a Few Seconds 1: void GameCycle() 2: { 3: static int iDelay = 0; 4: 5: // Establish a 3-second delay before moving to the next slide 6: if (++iDelay > 3) 7: { 8: // Restore the delay counter 9: iDelay = 0; 10: 11: // Move to the next slide 12: if (++_iCurSlide == _iNUMSLIDES) 13: _iCurSlide = 0; 14: 15: // Force a repaint to draw the next slide 16: InvalidateRect(_pGame->GetWindow(), NULL, FALSE); 17: } 18: } Because the game engine is limited to a minimum frame rate of one second, it’s necessary to slow down the slideshow further by imposing a delay in the GameCycle() function. Three seconds is a reasonable delay for viewing each slide, so the GameCycle() function uses a static variable, iDelay, to delay each slide for three seconds before moving to the next (line 3). In order to move to the next slide, the iCurSlide variable is incremented (line 12); if it is incremented past the last slide, the slideshow cycles back to the first slide (line 13). Just because you increment the current slide variable doesn’t mean that the slideshow updates to show the new slide bitmap. Keep in mind that the current slide bitmap is drawn in the GamePaint() function, which is called whenever the client area of the Slideshow

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services

_hInstance variable is necessary to store because a program instance handle is necessary in order to load bitmaps as resources (line 14). An instance is simply a program loaded into memory; all the programs you have open and running in Windows are considered instances. An instance handle is a reference to an instance, which allows you to interact with the instance and do things such as load resources that are stored in the executable program file. Because you’re going to be loading bitmaps as resources, it’s important to store away an instance handle for the Slideshow program. The _pGame global variable is used to store a pointer to the game engine, which should be familiar to you by now (line 15). The remaining member variables relate specifically to the slideshow functionality. The global constant _iNUMSLIDES is used to set the number of slides in the slideshow, and should be changed if you modify the number of slides in the slideshow (line 16). The _pSlides variable is perhaps the most important because it stores away pointers to the Bitmap objects (line 17); these objects correspond to the slides in the slideshow. Finally, the _iCurSlide variable represents the array index of the current slide, which is the slide currently being displayed (line 18). This variable is important because it keeps track of where the slideshow is in the slide sequence. The global variables in the Slideshow header file are somewhat revealing, but you obviously have to look at the code for the game functions to really get a feel for what’s going on. Listing 5.3 contains the code for the GameInitialize() function, which is the first of the Slideshow game functions. Listing 5.3 The GameInitialize() Function Creates the Game Engine, Sets the Frame Rate to One Cycle Per Second, and Stores Away the Instance Handle for the Program 1: BOOL GameInitialize(HINSTANCE hInstance) 2: { 3: // Create the game engine 4: _pGame = new GameEngine(hInstance, TEXT(”Slideshow”), 5: TEXT(”Slideshow”), IDI_SLIDESHOW, IDI_SLIDESHOW_SM); 6: if (_pGame == NULL) 7: return FALSE; 8: 9: // Set the frame rate 10: _pGame->SetFrameRate(1); 11: 12: // Store the instance handle 13: _hInstance = hInstance; 14: 15: return TRUE; 16: } The GameInitialize() function is pretty basic in terms of doing things you’ve gotten accustomed to seeing in a program that makes use of the game engine. Notice, however, that the frame rate for the game engine is set to 1, which means that there is only one game cycle per second (line 10). This is important because it helps to establish the timing of the slideshow. The problem is that one second is still too short a period to flip between slides, so we’ll have to trick the game engine into displaying each slide a little longer; you tackle this problem in a moment. The only other task carried out in GameInitialize() is storing away the instance handle, which is very important for loading bitmaps from resources (line 13). Although GameInitialize() creates and initializes the game engine, it’s the GameStart() function that really gets the Slideshow program on track. Its counterpart is GameEnd(), which cleans up the bitmaps created in GameStart(). The code for both functions is shown in Listing 5.4. Listing 5.4 The GameStart() and GameEnd() Functions Take Care of Initializing and Cleaning Up the Slide Bitmaps 1: void GameStart(HWND hWindow) 2: { 3: // Create and load the slide bitmaps 4: HDC hDC = GetDC(hWindow); 5: _pSlides[0] = new Bitmap(hDC, TEXT(”Image1.bmp”)); 6: _pSlides[1] = new Bitmap(hDC, TEXT(”Image2.bmp”)); 7: _pSlides[2] = new Bitmap(hDC, TEXT(”Image3.bmp”)); 8: _pSlides[3] = new Bitmap(hDC, IDB_IMAGE4, _hInstance); 9: _pSlides[4] = new Bitmap(hDC, IDB_IMAGE5, _hInstance); 10: _pSlides[5] = new Bitmap(hDC, IDB_IMAGE6, _hInstance); 11: _pSlides[6] = new Bitmap(hDC, 640, 480, RGB(128, 128, 64)); 12:

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services