Delphi Graphics and Game Programming Exposed! with DirectX For versions 5.0-7.0:Basic Graphics Programming                       Search Tips   Advanced Search        Title Author Publisher ISBN    Please Select ----------- Artificial Intel Business & Mgmt Components Content Mgmt Certification Databases Enterprise Mgmt Fun/Games Groupware Hardware IBM Redbooks Intranet Dev Middleware Multimedia Networks OS Productivity Apps Programming Langs Security Soft Engineering UI Web Services Webmaster Y2K ----------- New Arrivals









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 Palettized Modes Four and eight bits-per-pixel color depths are the only palettized video modes. As 4 bits-per-pixel color depths are no longer used for games, we will discuss only 8 bits-per-pixel color depths. 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. Now, each entry in this array contains an 8-bit value for the blue, green, and red intensity of a color. In effect, this gives 8 bits-per-pixel color depths access to 16,777,216 potential colors, but only 256 of them can be shown at one time. Figure 3-7:  An 8 bits-per -pixel bitmap’s pixels act as indices into a color palette There are many things to consider when working with 8 bits-per-pixel color modes. A major disadvantage to this mode is that all bitmaps to be displayed simultaneously must be drawn using the same palette. This requires a lot of careful planning on the part of art production, and can limit the creativity of artists and the variety of artwork that can be displayed on screen. Bitmaps that are drawn using one palette but displayed on a device in which a different palette is currently being used, will have unpredictable results. A bitmap’s pixels could be mapped to the closest approximation of the appropriate color in the current palette, but this process is slow, usually produces inadequate results, and is not appropriate for fast action games. Different palettes can be used between scenes, however, which can reduce this effect. However, 8 bits-per-pixel video modes give the greatest speed advantage, and a tremendous number of colors can potentially be used while taking up the least amount of RAM. Up to four pixels can be moved simultaneously by using 32-bit memory movement instructions, allowing bitmaps to be moved about at blindingly fast speeds. Another major advantage comes from palette animation. If colors within the palette are moved about, or cycled, every pixel drawn using that color is affected simultaneously and automatically. This can be used for various special effects, such as flowing water or lighting. Palette animation is not available under non-palettized video modes. Since this book is concerned with high- performance games and graphics programming, all examples will use only 8 bits-per-pixel video modes in order to squeeze out as much speed as possible. Non-palettized Modes 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. In general, 16 bits-per-pixel color depths use five bits to describe each of the red, green, and blue intensities of a color. 24 bits-per-pixel uses a full eight bits to describe each intensity, and 32 bits-per-pixel uses the same format with eight extra bits used as a translucency value. 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. This book will concentrate on using only 8 bits-per-pixel color depths, so any further discussion of non-palettized video modes is beyond our scope. Graphics Output Techniques As stated above, the GDI provides the primary functions and procedures by which graphics can be drawn to the screen. There are literally hundreds of functions and procedures, and covering all of them is well beyond the scope of this book. However, we will discuss a number of the most common GDI graphical output functions and will look at several examples that demonstrate their use. The Device Context 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. This access is accomplished through the specific device’s device driver. device context (DC): Represents the surface of an output device such as a monitor, printer, or plotter, allowing the application to perform graphical output. Under regular Windows programming, the device context provides the only way to render graphics to the screen. Device contexts can be used with Direct- Draw functions to make certain tasks easier, as we’ll see in later chapters. Most, if not all, GDI API functions require a handle to the device context upon which the specified graphical operation will be performed. Device contexts represent certain areas on the screen, from the surface of a control (such as a button) to the entire surface of a window or even the screen itself. To retrieve a handle to a device context, an application calls the GetDC function, passing it the handle of the window whose surface is to be drawn upon. It is very important to call the ReleaseDC function when the application is finished drawing its output, as neglecting to release the device context can cause Windows to lock up. 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. Painting on the Canvas Objects derived from TGraphicControl and TCustomControl provide a TCanvas property for performing graphical output. This allows the developer to determine the appearance of the control. The TCanvas object, as an encapsulation of the device context, contains numerous methods for drawing graphics, making the use of most GDI function calls unnecessary. However, when using GDI API functions that are not encapsulated by the TCanvas object, the Handle property can be used in parameters that require a handle to a device context. Lines, polygons, even individual pixels can be drawn on the surface of a TCanvas object with relative ease. Again, like the device context, the TCanvas object represents the surface of a window, such as a control or the application window itself. Thus, when anything is drawn on the canvas, it will appear on screen in the position of the control or window which it represents. Note: Graphics output is controlled by specifying a horizontal and vertical coordinate, with the horizontal coordinate increasing from left to right and the vertical coordinate increasing from top to bottom. Since the TCanvas object represents an individual window or control, the origin of its coordinates is relative to the window or control it represents. Thus, the coordinate 0, 0 will be in the upper left-hand corner of the window or control it represents, which may or may not be the upper left-hand corner of the physical screen. Now let’s examine some techniques for drawing graphics. These techniques will be concerned with drawing graphics primitives, or simple lines, dots, and polygons. These simplistic techniques demonstrate how easy it is to use the TCanvas encapsulation of a device context for performing graphical output. They all use the Canvas property of the main form for the drawing surface. 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.