Hello again, Lundin:

I've made some recent progress and, being that you kindly took the time to post a reply to my message, I thought you might be interested in the progress I've made. I'm including some comments I made to another individual so as to save me some typing time. Thanks in part to your suggestion about using the debugger, I've made the progress discussed below:

"In the last 24 hours or so, I have made significant progress. I went through with the debugger and stepped through the code and found out that one appearent factor behind the fact that the camera moved only once when I "forced" it to was the fact that the program cycles through the drawing instructions only once as part of its initialization and then moves the already-set-up image with the "Direct3DRM::Move command in the RenderLoop() function after that. By placing commands to access nearly all of the drawing functions in the RenderLoop() function, I was able to set things up in such a way that the program still initializes the image as part of its initialization but also calls the same drawing functions each time through the RenderLoop(). By placing a KeyMode global variable in a structure whcih also stores some of the pointers for the scene, camera, and so forth, I was able to incorporate if statements that measured the KeyMode value as set in the WindowProc Loop and thus move the camera to either side and toward or away from the image just fine. Needless to say, I was very happy about that.

"However, when I went to rotate the camera -- to "look" to one side or the other or to "look" up or down, the image dissappeared as soon as soon as the camera was no longer pointed directly at it. This is when I decided to incorporate the commands in the RenderLoop() to call on the drawing commands on each cycle through it. Through experimentation with the "AddRotation", I was able to rotate the camera. However, the end result was totally unexpected. Rather than the camera rotating on a Y axis as planned, the camera rotated on a Z axis and the image spun like a whirling dervish! Finally, once I incorporated sufficient code into the loop and global structure to allow the object's frame to be part of the loop and referenced the rotation to that frame, it worked great -- except for one thing. The rotation would start out fast but would slow by half each time the object appeared and dissappeared on the screen as the camera rotates. Eventually, it got to the point where the computer -- a 450-mhz Penthium II -- takes more than a second on each frame to update an image which cureently involves only eight vertices. So, now I need to figure out a different way to tackle the problem.

"Also, when I tried to call the SetPositions function from the RenderLoop() function, something in it still does not allow the information in the global variables to be accessed by it. That's why part of my solution to get this far was to include the code from within the SetPositions() function in the RenderLoop() to access the global KeyMode and pointer variables for the frames with it.

"The bottom line is that, thanks to you and the other people who have taken the time to post replies, I am making progress and am no longer hitting the proverbial brick wall I was before and I cannot thank all of you enough for that."

And, as just mentioned, the thanks go to you also, Lundin. Thank you very, very much.

Sincerely,

Mike