Tricks of the Windows Game Programming Gurus:Windows GDI, Controls, and Last-Minute Gift Ideas

All ITKnowledge Source Code Search Tips Advanced Search |

| Tricks of the Windows Game Programming Gurus by Andre LaMothe Sams, Macmillan Computer Publishing ISBN: 0672313618 Pub Date: 09/27/99

Search this book:

Previous | Table of Contents | Next

## Chapter 4
Windows GDI, Controls, and Last-Minute Gift Ideas

> “Compuuuuterrr?”

> —Scotty, Star Trek IV

This is the last chapter on pure Windows programming. Thank the gods! Anyway, we’re going to cover more on using the Graphics Device Interface. Stuff like drawing pixels, lines, and simple shapes. Then we’ll touch on timing and finish off with Windows’ child controls. Finally, we’ll take everything and create our first shot at the T3D Game Console template application that we’ll use throughout the remainder of the book as a starting point for all demos. Here’s a list of the main topics:

  • Advanced GDI programming, pens, brushes, and rendering
  • Child controls
  • System timing functions
  • Sending messages
  • Getting information
  • The T3D Game Console

### Advanced GDI Graphics

As I’ve mentioned, GDI is horribly slow when compared to DirectX. However, GDI is good at everything and it’s the native rendering engine for Windows itself. This means if you create any tools or standard GUI applications, knowing your way around GDI is an asset. Moreover, knowing how to mix GDI and DirectX is a way to leverage the power of GDI’s functionality to emulate functions you haven’t completed in your DirectX programming. Hence, GDI has utility as a slow software emulation for functions you might write down the road in your game design. Bottom line—you need to know it.

What I’m going to do now is cover a few basic GDI operations. You can always learn more by perusing the Win32 SDK, but the basic skill set you’ll learn here will more than prepare you for figuring out any GDI function. It’s like Comdex—if you’ve seen one, you’ve seen them all.

#### Under the Hood with the Graphics Device Context

In Chapter 3, “Advanced Windows Programming,” you saw the type handle to device context, or HDC, a number of times. This of course is the data type that represents a handle to a device context. In our case, the device context has been a graphics device context type, but there are others like printer contexts. Anyway, you might be wondering what exactly a graphics device context is? What does it really mean? Both are good questions.

A graphics device context is really a description of the video graphics card installed in your system. Therefore, when you have access to a graphics device context or handle this really means that stuffed away somewhere is an actual description of the video card in your system and its resolution and color capabilities. This information is needed for any graphics call you might make to GDI. In essence, the HDC handle you supply to any GDI function is used to reference whatever important information about your video system that a function needs to operate with. And that’s why you need a graphics device context.

Furthermore, the graphics device context tracks software settings that you may change throughout the life of your program. For example, GDI uses a number of graphics objects such as pens, brushes, line styles, and more. These basic data descriptions are used by GDI to draw any graphics primitives that you may request. Therefore, even though the current pen color is something that you might set and isn’t intrinsic to your video card, the graphics device context still tracks it. In this way, the graphics device context is not only a hardware description of your video system, but a repository of information that records your settings and stores them for you, so that the GDI calls you make can use those settings rather than explicitly sending them along with the call. This way you can save a lot of parameters for GDI calls. With that in mind, let’s take a look at how to render graphics with GDI.

#### Color, Pens, and Brushes

If you think about it, there aren’t that many types of objects that you can draw on a computer screen. Sure, there are an unlimited number of shapes and colors you can draw them with, but the types of objects are very limited. There are points, lines, and polygons. Everything else is really a combination of these types of primitive objects.

The approach that GDI takes is something like that of a painter. A painter paints pictures with colors, pens, and brushes—work with me on this <BG>. GDI works in the same manner, with the following definitions:

  • Pens—These are used to draw lines or contours. They have color, thickness, and a line style.
  • Brushes—These are used to fill in any closed objects. They have color, style, and can even be bitmaps. Take a look at Figure 4.1 for a detailed labeling.

Figure 4.1 A brush, labeled in detail.

Before we get into pens and brushes and actually using them, I want to take a minute to look at the situation. GDI likes to use only one pen, and one brush at a time. Sure, you can have many pens and brushes at your disposal, but only one of each is active in the current graphics device context. This means that you must “select objects” into the graphics device context to use them.

Remember, the graphics device context is not only a description of the video card and its services, but a description of the current drawing tools. Pens and brushes are primary examples of tools that the context tracks and that you must select in and out of the graphics context. This process is called selection. As your program runs, you’ll select in a new pen and then select it out later, and maybe select in and out different brushes and so on. The thing to remember is that once a drawing object is selected into the context it’s used until it is changed.

Finally, whenever you create a new pen or brush, you must delete it when you’re done. This is important because Windows GDI has only so many slots for pen and brush handles and you could run out! But we’ll get to that in a minute. Okay, so let’s cover pens first, and then brushes.

Previous | Table of Contents | Next

Copyright © Macmillan Computer Publishing, Inc.

Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.