To access the contents, click the chapter and section titles.
Cutting Edge Direct 3D Programming
(Publisher: The Coriolis Group)
Author(s): Stan Trujillo
ISBN: 1576100502
Publication Date: 11/01/96
Chapter 3 Introduction To Direct3D
- Microsofts COM Programming Model
- The Direct3D Objects
- Important Direct3D Data Types
- X Files
In this chapter, well take a look at Direct3D. Well talk about the concepts and terminology that Direct3D employs, and well look at the Direct3D API itself.
Direct3D
Direct3D is a collection of Microsofts Component Object Model (COM) interfaces that represent graphical constructs such as meshes and faces and application constructs such as viewports and devices. Well talk about each interface in this chapter.
Although we will be discussing interfaces and member functions, the purpose of this chapter is not to provide a reference manual. We arent concerned with parameter lists or return values, just the functionality that an interface provides through its member functions.
Before we jump into our discussion of the Direct3D interfaces, you need to be familiar with Microsofts COM. The following is a short discussion of COM. By convention, COM interfaces are named with an I prefix (I for Interface). In our discussion, well omit this prefix.
COM
Microsofts COM (Component Object Model) is a programming model designed to allow the development of completely portable, safely upgradable software components. COMs vision is that software components should be as easy to install as hardware components. Snickers aside (that sure doesnt sound like the hardware components Ive installed), COM is the foundation of APIs such as OLE and DirectX.
COM uses an object-oriented model that is different from the model used by languages such as C++. The COM model is more strict. The COM version of inheritance, for example, is limited compared to the C++ version. Also, COM objects do not allow public data members. All interaction with the object must be done through member functions.
A COM component is made up of an object and one or more interfaces that access the object. The object provides the actual functionality that the COM component supports but cannot be accessed directly. COM objects are always accessed through interfaces. A single object can support multiple interfaces. Figure 3.1 illustrates the object/interface relationship.
Figure 3.1 COM objects and interfaces.
The figure illustrates the applications relationship with the COM object. The application uses the COM object only through the interfaces that the object supports.
COM objects support multiple interfaces in order to allow the objects functionality to be upgraded or extended without risk of breaking existing programs.
COM also supports a feature called lifetime encapsulation. Lifetime encapsulation means that COM objects control their own destruction. When an object detects that it is no longer needed, it destroys itself. In order for this feature to work properly, programs are charged with the responsibility of notifying objects when a new pointer to the object is created and when one is destroyed.
All COM objects are derived from the Iunknown COM object. Iunknown supplies three member functions: AddRef(), Release(), and QueryInterface(). AddRef() and Release() are the member functions that increase and decrease an objects reference count. The QueryInterface() function is used to retrieve auxiliary interfaces for an object (or to determine that the interface is not supported). One of the QueryInterface() function arguments is a Globally Unique Identifier (GUID) that identifies the interface that is being sought.
All of the DirectX APIs are built with COM. This does not, however, mean that you must be an expert on COM to use DirectX. In fact, using COM objects is similar to using C++ objects. The following guidelines point out some of the rules that should be observed when using COM.
- COM objects and C++ objects cannot be derived from one another. The closest you can get to deriving a C++ class from a COM object is to embed the COM object into the C++ classes and write wrapper functions for each COM member function.
- Anytime a copy of a COM object pointer is made, the objects AddRef() member function should be called to notify the object of the additional reference. This doesnt apply to object creation. Usually the DirectX API supplies a function that creates the COM object and calls AddRef() for you.
- Anytime a COM object pointer is no longer needed, the objects Release() member function should be called.
- The QueryInterface() member function isnt magic. QueryInterface() will return interfaces to an object only if the object supports the interface. Attempts to obtain arbitrary interfaces from an object will fail.
If you want to know more about COM, you can download the specifications from the Microsoft Web site (www.microsoft.com).
|