Driving DirectX

Using Vertex Shaders, Part 1

 

Philip Taylor Microsoft Corporation

February 19, 2001

Download Base.exe and Basevs.exe.

Welcome to Driving DirectX. Last month I presented an overview of programmable vertex and pixel shaders. This month I want to explore vertex shaders in more detail. Vertex shaders gives developers fine-grained control over the vertex transformation and lighting pipeline and can be used as a substitute in DirectX® 8 for the fixed-function transform and lighting pipeline. First, though, we need to examine the new sample framework so we have a basis to begin developing vertex shader samples and vertex shaders.

DirectX 8 Graphics Sample Framework

While the DirectX 8 Direct3D SDK graphics sample framework is an evolution from the DirectX 7 graphics sample framework (D3DFrame, covered in the May 2000 issue of Driving DirectX), it has changed enough that some small additional coverage is warranted to update the particulars.

First, the SDK layout has changed. The SDK samples, by default, are installed in \Mssdk\Samples\Multimedia. The new SDK layout is shown in Figure 1.

Figure 1. DirectX 8 SDK sample folder layout

For our purposes, the folders of interest are Common and Direct3D. The sample framework is now contained in the Common folder and the Direct3D samples based on the graphics framework are contained in the Direct3D folder. Within the Common folder are Include and Src folders containing the headers and source files that make up the graphics framework (as well as support for the samples that showcase the other components of DirectX, but that's beyond the scope of this column).

Now that it's clear where the sample bits are located, it's time to dig in. If you really want to understand how the samples work, as opposed to the features showcased in them, a basic understanding of how the sample framework works is required. Here I will perform a high-level discussion of the graphics sample framework. This is all that's necessary to understand and use the framework to write your own samples. The DirectX 8 graphics framework consists of five source modules, located in the Common\src folder that's contained in the Multimedia folder as shown in Figure 1. The files that contain the Direct3D Sample framework are:

• d3dapp.cpp implements the application class, CD3DApplication, which is the base class used for the D3D samples.

• d3dfile.cpp furnishes x-file support to enable samples to load x-files. Of particular interest are classes CD3Dmesh and CD3DFrame.

• d3dfont.cpp furnishes the CD3DFont class, which provides basic font output support, to enable things like statistics views.

• d3dutil.cpp provides generally useful 3d functions, such as material, light, and texture helper functions.

• dxutil.cpp provides generally useful DirectX functions, such as media, registry, and timer helper functions.

There are corresponding header files located in the Common\Include folder as well.

If you recall from the May article, each sample implements a subclass of CD3DApplication (typically named CMyD3DApplication) and set of "overridable" methods as shown below:

// Overridable functions for the 3D scene created by the app

virtual HRESULT ConfirmDevice(D3DCAPS8*,DWORD,D3DFORMAT) { return S_OK; }

virtual HRESULT OneTimeSceneInit() { return S_OK; }

virtual HRESULT InitDeviceObjects() { return S_OK; }

virtual HRESULT RestoreDeviceObjects() { return S_OK; }

virtual HRESULT FrameMove() { return S_OK; }

virtual HRESULT Render() { return S_OK; }

virtual HRESULT InvalidateDeviceObjects() { return S_OK; }

virtual HRESULT DeleteDeviceObjects() { return S_OK; }

virtual HRESULT FinalCleanup() { return S_OK; }

The prototypes for these methods are contained in d3dapp.h in the CD3Dapplication class. All you need to do to create a new D3D application using the sample framework is create a new project and new implementations of these functions; let's call them the "overridable" interface for a framework sample. That's exactly what the D3D SDK samples do. These methods are essentially the same as we covered in the May 2000 article; in the interest of brevity I'll refer you to the May issue for more detail. One important distinction to remember is between InitDeviceObjects/RestoreDeviceObjects, and between InvalidateDeviceObjects/DeleteDeviceObjects, Init/Delete are called when you are creating/destroying a device completely; Restore/Invalidate are called before/after calling Reset on a device, which happens when you change some aspects of the device or have to deal with a lost device. To make a well-formed new framework sample you need to understand where to put your code—for example, managed textures can be created/destroyed in Init/Delete, but unmanaged textures need to be created/destroyed in Restore/Invalidate.