Global Variables Not Truly Global?

2»

Comments

  • : I don't know if this counts for when using Direct3D to draw...
    : Probably not, but:
    :
    : I was messing around with printing text on a window and I noticed it didn't draw until I 'triggered' the repaint code.
    : So I thought I would be smart and send a WM_PAINT with PostMessage.
    : However, then still the program wouldn't draw until I resized.
    :
    : I found out this is because Windows doesn't really draw it. It just 'remembers' what the code run by WM_PAINT did and then when it is need of a refresh it draws.
    : What I needed to do is mark the client area of my window as 'invalidated'. I had to tell Windows it was in need of an actual repaint (I did this with InvalidateRect API). And THEN I posted the WM_PAINT message.
    :
    : But like I said, I don't know if it's the same when using Direct3D (I would expect it to redraw automatically).
    :
    : Best Regards,
    : Richard
    :
    : The way I see it... Well, it's all pretty blurry
    :
    :

    Hello Richard:

    I appreciate the reminder about "Invalidate". That may have some bearing on why one approach to my work is drawing so slowly. I appear to be making some progress but the challenge is figuring out a way to get the work done without having the computer slow to a crawl. In the last 24 hours, I've made some good progress with one approach but when a 450-mhz Penthium II computer gets to the point where it takes more than a second on each frame to update an image only involving eight vertices, that's pretty bad. Clearly, I'm going to need to rethink my approach to the problem. I'll look into using Invalidate and see if that helps in some kind of way.

    Thank you for taking the time to post your reply.

    Mike
  • : [blue]Mike,
    :
    : So, my guess was correct... :-)
    :
    : The WndProc is a message receiver from Windows (and from other sources as your own code or other applications). Windows will call your WndProc function only when needed. But if you use a timer - Windows will send you a message WM_TIMER with an interval you specify.
    :
    : The drawing in Windows is not cyclical and all the time, but only when needed: window resized, window minimized and restored, maximized and restored, or other window was closing yours and been moved out uncovering your window... etc.
    : [/blue]
    :

    Yes, indeed you guessed part of the problem. 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 ultimately 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().

    I first began just 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 then able to incorporate if statements into the RenderLoop() that measured the KeyMode value as set in the WindowProc Loop. Finally, I was able to reference the global camera pointer directly in the SetPosition and SetOrientation commands 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 you personnally enough nor can I thank all of the others enough for that.

    Sincerely,

    Mike
  • : One thing that I think that you should look over your code very carefully for is multiple definitions of the same variable. I noticed that in the code you posted you have campos_x and campos_X. C/C++ is case sensitive.
    :
    : Also are you sure that the code that is supposed to move the camera around is correct and works?
    :
    Hello again, Frank:

    I'm sending you this update (which in all honesty includes some comments I sent in a messgae to another individual -- I did this to saVe me some time in typing) I wanted to let you know that, thanks in part to your suggestion that I look over the code more carefully, things are looking a little better as disussed 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, Frank. Thank you very, very much.

    Sincerely,

    Mike

  • 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
  • [b][red]This message was edited by Lundin at 2007-3-25 23:26:43[/red][/b][hr]
    Sorry for my late reply, busy weekend.

    I guess there is nothing to add except that I don't think "Invalidate" should be needed in DirectX. I don't know anything about DirectX but I have used OpenGL in the past which should be similar, and I don't remember using any invalidate functions.

    Regarding optimizing: if you know about multithreading, perhaps you could split the program in 3 threads. One main processing thread, one graphic updates thread and one keyboard thread (instead of the inaccurate WM_TIMER which accuracy depends on the speed of other parts of the code).


  • One more thing that I think that you should look into is DirectX immediate mode. It is a lot harder to use and requires a lot more work, but supposedly it is faster. I'm always glad to be of assistance.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories