Search Tips Advanced Search |
| Delphi Graphics and Game Programming Exposed with DirectX 7.0 by John Ayres Wordware Publishing, Inc. ISBN: 1556226373 Pub Date: 12/01/99
Search this book:
Previous | Table of Contents | Next
### Summary In this chapter, we discussed several basic topics in graphics programming. Although all of the examples demonstrated these topics using normal Windows GDI function calls, the concepts and theories presented apply to graphics programming in general. When coding a graphically intensive application under Windows, it is important to keep these points in mind: • The GDI subsystem is responsible for all of the graphical output displayed to the screen during a Windows session. One of Windows’ strongest attributes is its device independence, or its ability to be run on a wide variety of hardware combinations. Due to this requirement, the GDI’s primary purpose is to provide a mechanism by which an application can output graphical content without the programmer being concerned about what type of hardware upon which the application will be running. Unfortunately, as a direct consequence of this device independence, the GDI is notorious for its slow performance. Even so, the GDI is very useful when creating tools for games, and some commercial games have been written using little more than generic GDI function calls. • One must be familiar with a number of terms that describe various common graphical elements. Such graphical elements include pixels, lines, polygons, and bitmaps. A pixel is defined as the smallest, single element in a graphical image or on the display surface. Lines are a collection of pixels, usually arranged in a linear configuration. A collection of lines, arranged in such a way that the ends are connected to form a continuous, closed shape, is known as a polygon. A bitmap is a collection of pixels arranged in a rectangular configuration in such a way that they form a recognizable shape, such as a picture or texture. • Discussions of graphics programming usually start from a consideration of what resolution the video driver is currently in and how many colors are available in which to draw the graphics. These two concepts are directly related, and are generally referred to in a combined sense as the video mode. Both the resolution and the color depth of the current video mode will affect the perceived quality of the displayed graphical images. The greater the resolution and color depth, the more realistic and detailed the displayed graphics will become. However, on the downside, higher resolution and deeper color depth mean greater memory usage and slower speed. • The color of every pixel drawn to the screen is determined by three components: a red intensity, a blue intensity, and a green intensity. As these intensities increase or decrease, the color of an individual pixel is affected accordingly. Each intensity can have a minimum value of 0 and a maximum value of 255. If the intensity of each component is 0, the resulting color is black, while if each component is at 255, the resulting color is white. This gives a maximum of 16,777,216 colors. This is referred to as RGB color, denoting red, green, and blue, respectively. • Four and eight bits-per-pixel color depths are the only palettized video modes. At 8 bits-per-pixel, each pixel can assume a value between 0 and 255. These values act as an index into what can be considered a 256-entry array known as the color palette. Each entry in this array contains an 8-bit value for the blue, green, and red intensity of a color. Palettized display modes require careful planning of art resources, but are very fast and allow for palette animation special effects. By contrast, 16, 24, and 32 bits-per-pixel video modes directly store the color value for each pixel. This color value is encoded according to the bits-per-pixel used, and can vary from video board to video board. Non-palettized video modes have the advantage of total freedom to display any number of bitmaps simultaneously, without worrying about color problems or palette management. The downside to this is that more memory is required for both display and bitmap storage, and games tend to run slower as it requires longer to move a bitmap from one place in memory to another. • A device context represents a surface upon which graphical output can be drawn. Specifically, a device context represents the surface of an output device such as a monitor, printer, or plotter, and gives the developer access to modify its appearance. Fortunately, we will not need to be concerned much with device contexts, as the TCanvas object encapsulates the functionality of the device context and makes graphical output much easier. • Bitmaps come in many varieties, from two color to true color, and in many different formats. The native Windows bitmap format is easy to use, and comes in two subformats: DDB and DIB. The device-dependent bitmap, or DDB, is an older bitmap format and is kept around solely for backward compatibility. The device-independent bitmap, or DIB, stores more information than a DDB and can accurately be reproduced on any output device. The use and display of DIBs is not quite as fast as DDBs, but their flexibility more than makes up for the loss in speed. Fortunately, the TBitmap object encapsulates the functionality of both the DDB and DIB image formats, making bitmap manipulation easy. • There are many nuances to working in a palettized mode under Windows, making the creation of games using regular GDI functions difficult. There are two different kinds of palettes used by the Windows operating system: the system palette and logical palettes. The system palette is a Windows- maintained global palette containing all of the colors that can be displayed. Logical palettes are created by the application, and contain the colors that the application would like to use.
Previous | Table of Contents | Next

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 whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.