- what's the class hierarchy
- what are the essential interfaces and activities
- who calls whom, to make things happen
A key structural fact is that there are two classes which are defined and instantiated to make up your program - SampleApp and SampleWin. The division of behaviors across these classes seems somewhat arbitrary, but allegedly the App will do most of the computing (of which there is none in this first example) and the Win handles the interaction with Windows.
First, look at the class hierarchy on page 94. Without this, nothing can be figured out. The executable code will start out by creating an instance of SampleApp, and then invoking SampleApp::InitInstance(). Everything for setup must automatically cascade from this event, or from some other event that will naturally happen when a Windows app starts running.
There's a chart on page 96 which attempts to explain what happens in what order. It's a bit confusing because it doesn't actually tell HOW the procedures get invoked. We'll explore that question via queries.
SampleApp::InitInstance() and RMWin:OnCreate()
Query 4.1. An instance of SampleApp is created and initialized to start the running of your sample program. Name and describe the specific actions that lead to the invocation of RMWin:OnCreate() as shown in Figure 4.6.
Query 4.2. The text then describes RMwin::CreateDevice(). How does this method get invoked?
I don't want to spend time on the insides of CreateDevice. You can just
briefly skim it and observe that it takes care of constructing a clipper
(to handle drawing into overlapping windows), a device which is
the software that actually takes care of doing graphics work in a particular
window, and finally calls CreateScene to create the scene itself
- the stuff to display. During the construction of the device, decisions
are made about the use of Gouraud shading and what kind of texture to use,
based on what hardware capability was discovered.
Query 4.3. Find the point in the source code at which the spiral is instructed to come up spinning. Modify the code so that the spiral is static, and run the code. Now modify the code so that the spiral tumbles end-over-end at 1/10 the speed of your previous (the original) demo, and run the code. By "tumble" I mean that the top of the object comes toward the viewer while the bottom goes away from the viewer (or vice versa.)
From this experiment, where are the X, Y and Z axes in the display space? What rotational direction is positive?
ANSWER
Query 4.4. Now make the spiral static, but rotate the light source about the X axis with the same parameters the object was once rotated. Report what you see.
Query 4.5. Does the mesh structure use the 'triangle strip' technique we discussed in Lecture 3? If not, briefly describe the technique it does use and comment on its efficiency in space and time relative to triangle strips.
Remember Query 1.9 (lecture 1) in which we discovered a viewer for .x files. Now you have two ways to see them (if they are ASCII .x files. Some of them are pure binary and won't display in the fashion we just used.
Query 4.6 - this is an 'extra' query, for those who quickly got to this point due to your diligence and extensive experience. Everyone should have done 4.1 through 4.5, but 4.6 is a volunteer exercise that is suggested by Trujillo on page 126.
Figure out a way to put two meshes into your program. You will need to experiment with the frame of the second one, and you can look around in the Cutting Edge D3d/src folder. I found a nice glass.x in the firefly folder which looks something likea chocolate wine goblet.