Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
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

Bookmark It

Search this book:
 
Previous Table of Contents Next


Class Design

Now, let’s move away from Direct3D COM interfaces and talk about C++ classes. We’ll be using C++ classes to manage the complexity of our programs. These classes are not substitutes for the Direct3D interfaces. The C++ classes will contain and manage the Direct3D interfaces.

The code in this book uses MFC. The strategy is to use MFC’s functionality without using the MFC Document/View architecture. We will use two MFC classes: CWinApp and CFrameWnd. CWinApp represents a Windows application, and CFrameWnd represents an actual window. We’ll use CWinApp as the base class for a Direct3D specific application class and CFrameWnd as a base class for a Direct3D specific window class. We’ll name the CWinApp derived class RMApp (RM for Retained Mode) and the CFrameWnd derived class RMWin.

We won’t, however, put all of an application’s functionality in these two classes. Instead, we will put only the standard Direct3D functionality—the functionality that remains the same from one application to another—into these classes. Then, we’ll create two more classes where we’ll put the application specific code. The names of these last two classes is up to you (the AppWizard makes recommendations, but you can override them). We created the Sample application for this chapter using the suggested class names: SampleApp and SampleWin. Figure 4.5 is an inheritance tree for the classes that we’ll be using.


Figure 4.5:  Class functionality and inheritance.

The figure includes four classes that we haven’t discussed: CObject, CCmdTarget, CWinThread, and CWnd. CObject is the fundamental MFC base class. Almost every MFC class is derived from CObject. The CCmdTarget (command target) class supports the bulk of the message handling functionality that MFC provides. Classes derived from CCmdTarget inherit the ability to use message maps. The CWinThread class provides multithreading support. The CWnd class is the MFC window class. CWnd provides the vast majority of window-specific functionality.

Division Of Labor

Before we take a closer look at any of the member functions that we will be using, let’s divide the member functions into four categories. Each category corresponds to a stage or phase in the program execution. The four stages are:

1.  Initializing Direct3D
2.  Creating a scene
3.  Maintaining a scene
4.  Shutting down

Most of our discussion in this chapter focuses on the first stage, because it is the most complicated step (for now anyway). Once Direct3D has been initialized, it is pretty easy to use. Stages 2 and 3 are covered in detail in the next five chapters. Stage 4 is just a matter of releasing any interfaces that we’ve created.

Initializing Direct3D

Earlier in this chapter, we determined that there is a specific order in which Direct3D interfaces should be created. Figure 4.4 illustrated the order and which steps were standard steps and which were application specific.

Now that we’ve introduced the classes that we’ll be using, it is a good time to revisit the interface creation order, this time with classes and member functions in mind. Figure 4.6 is just like Figure 4.4 except that it lists the member functions that are responsible for the step.


Figure 4.6:  Interface creation order with regard to interface categories.

As promised, the RMWin class creates the standard objects, and the SampleWin class creates application objects.

Now, let’s look at all of the functions involved in program initialization in the order that they are invoked.

The InitInstance() Member Function

The InitInstance() member function is a CWinApp virtual member function that is overridden in order to perform initialization tasks. Both RMApp and SampleApp provide versions of InitInstance().

The SampleApp version of InitInstance() is responsible for the creation of the window object. Several settings can also be specified at this time. The SampleApp::InitInstance() function looks like this:

BOOL SampleApp::InitInstance()
{
#ifdef _DEBUG
    afxTraceEnabled=FALSE;
#endif
    SampleWin* win=new SampleWin;
    if (!win->Create( "Sample Application", IDI_ICON, IDR_MAINMENU ))
        return FALSE;
    win->SetColorModel( D3DCOLOR_MONO );
    m_pMainWnd=win;
    return RMApp::InitInstance();
}

The first three lines of the function initialize the TRACE MFC functionality. TRACE macros are handy for displaying diagnostic messages during program execution. By default, TRACE macros are enabled, but TRACE macros are slow. If you use them frequently, they can visibly affect the performance of your application (especially if you use them in functions that are called for each screen update). The afxTraceEnabled variable can be used to activate and deactivate TRACE macros. Setting this variable to FALSE disables the TRACE functionality. Notice that the variable assignment is placed inside a conditional compilation block. This is because TRACE functionality is only available in programs that are compiled in DEBUG mode. In release mode, the afxTraceEnabled function doesn’t exist, so a check is made to insure that the afxTraceEnabled variable is assigned only in DEBUG mode.

Next, an instance of the SampleWin class is created. The Create() member function is then called to initialize the window. The Create() function takes three arguments. The first is a string that will appear on the title bar of the window. The second argument is a resource identifier for the icon that is to be used for the program. The third argument is a resource identifier that identifies the program’s menu.

After the Create() member function is called (and checked for success), the SetColorModel() member function is called. The D3DCOLOR_MONO constant is used to indicate that we will be using the Ramp or monochrome lighting model instead of the RGB model. The default color model is Ramp, so this function call isn’t necessary, but it is included here to indicate the proper point to specify the color model. Calling the SetColorModel() member function later in the program’s execution will have no effect.

Finally the CWnd::m_pMainWnd data member is assigned to point to the new window. This is an important step, because MFC uses this data member to access the window.


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.