- Graphics Essentials
- Examining Graphics in Windows
- Painting Windows
- Building the Crop Circles Example
- Summary
- Field Trip
This chapter is from the book
This chapter is from the book
This chapter is from the book
Examining Graphics in Windows
In order to seamlessly support a wide range of graphical output devices, Windows handles the painting of graphics a little differently than you might expect. Instead of allowing you to draw directly to the screen, a layer called the Graphics Device Interface or GDI is used to separate drawing operations from physical graphics devices, such as monitors and printers. The role of the GDI is to provide a programmatic interface for painting graphics in a generic manner. GDI operations work in concert with Windows graphics drivers to communicate with physical graphics devices. Figure 3.4 shows the architecture of GDI.
)
Figure
3.4 The GDI in Windows provides a layer between graphics operations at the
application (game) level and physical graphics devices.
Keep in mind that although I use the term "generic" to describe GDI graphics, the Win32 API provides a broad range of GDI graphics operations. In fact, the remainder of this chapter is devoted to showing you some of the interesting things you can do with GDI graphics.
Working with Device Contexts
The key component in GDI graphics is the graphics context or device context, which acts as a gateway to a physical graphics device. You can think of a device context as a generic drawing surface to which graphics are painted. In other words, a device context is like a piece of paper that you can draw on—except once you've drawn on it, the resulting image can be displayed on a variety of different devices. Device contexts are very important in Windows programming because they make it possible to have device-independent graphics.
A device context is really just a way to allow you to draw in a generic manner without worrying about where the drawing is physically taking place. Device contexts are necessary so that the same graphics routines can be used regardless of whether you are drawing to the screen, to memory, or to a printer. Granted, in game programming you'll always be drawing to the screen, but that doesn't mean you can just ignore the GDI. You have to go through a device context in order to draw graphics using the GDI, so you might as well get comfortable with them. The important thing to remember is that all the drawing you do in Windows is actually done to a device context. It is then up to Windows to make sure that the drawing on the device context gets properly displayed on the screen.
You normally obtain a device context by calling the Win32 BeginPaint() function. BeginPaint() is paired with EndPaint() to form a graphics drawing pair, like this:
PAINTSTRUCT ps; HDC hDC = BeginPaint(hWindow, &ps); *** GDI drawing operations go here *** EndPaint(hWindow, &ps);
The BeginPaint() function requires a window handle and a PAINTSTRUCT structure. The PAINTSTRUCT structure is filled with information pertaining to the device context and is rarely used in game programming. The BeginPaint() function returns a handle to a device context, which is all you need to start drawing graphics using the GDI. The EndPaint() function is then responsible for releasing the device context once you're finished with it.
It's also possible to paint outside of the BeginPaint()/EndPaint() function pairing—in which case, you have to obtain a device context in a slightly different manner. This is done using the GetDC() function, which only requires a window handle to obtain a device context. You must match the GetDC() function with the ReleaseDC()function to release the device context when you're finished using it. The following is an example of how these two functions are used together:
HDC hDC = GetDC(hWindow); *** GDI drawing operations go here *** ReleaseDC(hWindow, hDC);
In addition to device contexts, the GDI also supports the following common graphics components that you'll find useful in developing game graphics:
Pens
Brushes
Bitmaps
Palettes
The next few sections look at these graphics components in more detail and help you to understand how they fit into the GDI, as well as game graphics.
Writing with Pens
Pens in the GDI are analogous to ink pens in the real world; they are used to draw lines and curves. Pens can be created with varying widths and different colors. There are two kinds of pens: cosmetic and geometric. A cosmetic pen draws lines of fixed width and lines that need to be drawn quickly. A geometric pen draws scaleable lines, lines that are wider than a single pixel, and lines with unique styles. Given that cosmetic pens offer the speediest approach to drawing, they are the pen type most commonly used in game programming.
Painting with Brushes
Brushes in GDI are analogous to paint brushes in the real world; they are used to paint the interior of polygons, ellipses, and paths. Although you might commonly think of a paint brush as using a solid color, GDI brushes can also be defined based on a bitmap pattern, which means that they paint in a pattern, instead of as a solid. Brushes and pens go hand in hand when drawing graphics using the GDI. For example, if you were to draw a circle, a pen would be used to draw the outline of the circle, whereas a brush would be used to paint its interior.
Drawing Images with Bitmaps
A bitmap is a graphical image stored as an array of pixels. If you've ever used a digital camera or seen pictures on a Web site, you are already familiar with bitmaps. Bitmaps are rectangular, so the number of pixels in a bitmap is the width of the bitmap multiplied by its height. Bitmaps can contain multiple colors and are often based on a specific palette or set of colors. Bitmaps are, without a doubt, the most important graphics components in game programming because they provide the most flexibility in terms of using high-quality artwork. Unfortunately, bitmaps are a little more complex to use at the programming level, which is why I don't go into detail with them until the next chapter.
Managing Color with Palettes
A palette is a set of colors used by the GDI when rendering a bitmap. As an example, many images (bitmaps) are stored as 256-color images, which means that they use colors from a palette of 256 colors. Depending on the specific settings of your screen in Windows, the GDI might have to map the color palette for a bitmap to the color palette used by the screen. Most of the complexities of palette management are handled automatically by Windows.
Bitmap images can be stored in a variety of different formats ranging from 1 bit per pixel to 32 bits per pixel. 256-color bitmaps require 8 bits per pixel and are therefore referred to as 8-bit images. A pure black and white bitmap requires only one bit per pixel because each pixel is either on (black) or off (white); these are called 1-bit images. The most popular images in use today are 24-bit images, and they are capable of doing an excellent job of representing highly detailed images with millions of different colors.
Nowadays, it's safe to assume that most desktop PCs are set to a color mode higher than 256 colors (8-bit). In fact, most PCs are now set to 24-bit color, which supports more than 16 million different colors. This is important because if you assume that the target computer system for your game uses a 16-bit or higher color mode, you don't have to fool with palettes. You can simply create all of your game graphics as 24-bit images and load them without worrying about the complexities of mapping bitmap colors to screen colors. The next chapter shows you how to carry out this task.