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
Individual DirectDrawSurface objects represent display buffer memory. This can be either offscreen storage for image data or the visible display itself. The application uses these surface objects to communicate directly with the video hardware, either through direct memory access of image data or methods that access hardware acceleration. Surfaces provide methods to copy image data to and from each other, performing various operations on the image data such as scaling or ignoring transparent pixels. DirectDrawSurface objects encapsulate much of the power provided by DirectDraw. DirectDrawPalette objects hold color data for images that are stored in a palettized format. They also represent the application’s interface directly to the display hardware’s palette. DirectDrawPalette objects will be covered in more detail in the next chapter. #### COM Fundamentals DirectX objects are COM based, consequently involving all of the associated benefits and drawbacks of using COM objects. Microsoft’s Component Object Model (COM) is a huge beast, not unlike that of the VCL. A full-fledged discussion of COM is beyond the scope of this book, and unnecessary for the purposes of DirectX programming. However, there are a few COM theories that we must understand before delving into the heart of DirectX programming. Working with DirectX objects has some similarities to working with other COM objects, but there are a few differences. The primary difference that most experienced COM programmers will discover is the fact that DirectX objects do not need to be created by using the CoCreateInstance function. Other COM objects frequently used in a traditional COM application, such as IClassFactory, are also unnecessary. All DirectX objects are created through custom function calls that return an instantiated COM object. For example, the DirectDrawCreate function is used to create an instantiated IDirectDraw object (more on this later). If you’ve never worked with COM objects before, this takes some of the confusion out of the loop, and is similar to creating traditional VCL objects in code. A COM object can almost be thought of as a VCL object with no properties, only methods. The methods of a COM object are known as an interface. A COM object can have more than one interface, and it can be extended by added new interfaces, similar to deriving a new component from an ancestor. However, the COM standard dictates that an interface can never change. The result of this is that older code is guaranteed to work with newer COM objects, as the original interfaces will still be implemented and available. For this reason, you will see several different types of interface declarations in the DirectX header files. As each new version of DirectX comes out, offering new functionality, an entirely new interface must be created to support this functionality. However, you can rest assured that your DirectX game will still work when DirectX 7, 8, 9, etc., are introduced in the future. An interesting feature implemented by COM allows applications to query a COM object to see if it implements a particular interface. This allows your application to be extremely flexible when implementing certain features. For example, force feedback is a newer addition to DirectInput functionality. Your application, upon startup, could query the DirectInput objects to see if they support the interface required to implement force feedback output. If they do not, indicating that the game is running on a machine with an older version of DirectX, you could simply bypass the part of your code that implemented force feedback. However, if the force feedback interface is available, your application can make full use of its features. In this way, game applications can be very robust, taking advantage of special features only on those machines that have them available, while still running acceptably on older machines without those features. We will see an example of this later in this chapter when we discuss how to detect what version of DirectX the user has installed. Reference Counting One fundamental concept in COM is the idea of lifetime management. COM was implemented with the idea that several users, or clients, could potentially use the exact same COM object, thus saving memory and resources. Therefore, the COM objects themselves implement a method of reference counting. Essentially, COM objects keep a count of how many times they are being used. When they are created, this count is initialized to 1. When a new client wishes to use the COM object, this reference count is incremented. When a client no longer needs the COM object and it goes out of scope, such as when an application terminates, the reference count is decremented. When the reference count reaches 0, the object knows it can free itself. This reference count incrementing and decrementing is accomplished by calling the AddRef and Release methods implemented in all COM objects. However, fortunately for Delphi developers, Delphi takes care of this automatically and, for the most part, transparently. Reference counting does add some esoteric nuances to using COM objects that are not present when using VCL objects. As a Delphi DirectX developer, don’t worry about explicitly freeing DirectX objects after they are created; they will free themselves when they go out of scope or when the application terminates. For more information on general COM programming concepts, look at Delphi 4 Developer’s Guide by Teixeira and Pacheco (ISBN 0-672-31284-0) or Delphi Developer’s Handbook by Cantu, Lam, and Gooch (ISBN 0-782-11987-5). GUID COM objects are identified by a unique number known as a GUID, pronounced “goo-id” or “gwid” (like “squid”), which stands for globally unique identifier. Without going into too much detail, Microsoft provides an API call that generates a GUID that is completely unique; it is guaranteed to be unique if the machine on which the GUID was created has a network card installed. The concept of what a GUID is or how it is used is only important to the DirectX developer in that GUIDs are used to identify many individual objects and devices, such as specific DirectX objects (such as memory surfaces or sound buffers) and specific drivers (such as a particular video driver or device). We will be using GUIDs throughout every example in the book. #### Surfaces Perhaps the single, most important concept in DirectDraw programming is that of the surface. A surface is directly analogous to Delphi’s TBitmap or TCanvas object. It represents a virtual “picture” upon which graphical output can be drawn. In reality, a surface is a linear chunk of memory that is managed as if it were rectangular. Surfaces have width and height, among many other properties. The memory for a surface can be located in a number of places, but primarily it will be found in system memory or in the memory on the display card itself.
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.