So for all the little DirectX test programs I've been writing up to now, I've been having this problem. Now that I've finished this other little problem, it's time to tackle it. First I will show what the problem is by means of pictures. So this is what I see when I "Start Debugging" in Visual C++. My program running fine. All is nice and well, and I do something like, oh, click on Visual C++. Ignore that currently focused is actually the little notepad in the corner, I did that to successfully take a screenshot. Now Visual C++ has focus. Obviously my program is behind it. What's not pictured, and what I couldn't take a screenshot of, is that if I go down to the bottom and click on AIDemo, it doesn't come up. If I Alt-Tab to it, it doesn't come up. Also let it be known that if I Alt-Tab to it or click on it on the bottom, I can still control it. It's successfully reacquiring the Keyboard. So what about if I minimize Visual C++? There you see, it looks very messed up around the borders. But the funny thing is that it's still running. The program is still going with renders and circles moving back and forth and you see it all just fine. You just can't switch to it, can't alt-tab to it, can't select it from the bar at the bottom, etc. I've been doing some research and have found a couple useful links about Lost Devices ( Link1, Link2 ), but my problem does not seem to be that. From what I gather about lost devices, if such were the case, I wouldn't be seeing anything when I minimize Visual C++. It shouldn't be going. All the Vertex Buffers ( mainly for the text, which is a vertex buffer with a text texture, the circles themselves are using an offscreen surface and a StretchRect, although I would like to go back and make them textured quads ) should be needing to be reacquired or something. I am really quite confused about how devices get lost in what circumstances and exactly how I should deal with it. So I don't think it's a lost device problem. Any ideas? Maybe it's not even a DirectX thing, maybe it's a Windows thing. I don't know. My first thought would be it's something DirectX related, because of the possibility of losing one's device. Seeing as how something like that can happen, something like this might be related, too. Also, could any light be shed on device losing, and getting them back and all that? What I have looked around and read about is fairly vague as to in what conditions a device is "lost", what "lost" means, and what to do about it. Even if my problem isn't DirectX related, this would be useful information.

My "Pause" just skips the update() function, if you get what I mean. I don't think that will help much.

Bump for the afternoon/evening crew.

It almosts looks like your program is not handling system messages correctly. Things such as redrawing the window or gaining focus are not being processed. Do you have a function which eats all those messages and is it being called every frame?

Ah. Yes, your hunches are correct.

My original game loop was a mere while loop involving update(), handleInput(), render(), and stuff to calculate the time it took to do all that, for timing purposes. I recall when I did use Peek/Translate/DispatchMessage, and I certainly know of them, I did not know their purposes were for things like that. I also seem to recall the DirectX book I used to learn from stating that I could get rid of them, but it didn't. It just said replace GetMessage with the superior PeekMessage. That was why I didn't have them in there.

And here I thought it would be a complicated problem. Seems like all the bugs I've had in fixing this thing have been fairly simple, which I guess is like how most things are.

I was almost about to post that this wasn't helping, until I realized where my program was freezing. I dont think this little loop in handleInput() was being very nice in letting my function return so I can handle a switching in message or whatever:



Thanks for the help.