Thread: Other Routines For Setting a pixel onto a Device context

* wonders why nobody has mentioned SDL , or GLUT*

When programming full-screen Direct3D, one thing that many has trouble doing is recovering from a minimization/application switch.

Not everything is easier in Direct3D, some things are (like loading images) but not everything.

When programming full-screen Direct3D, one thing that many has trouble doing is recovering from a minimization/application switch.

I agree, it was the one thing I had trouble getting to work even after reading the tech docs; is there even an example in the SDK documentation?

Yes, there is.

I put this in a seperate post because it is not related to the above.

When someone switches tasks there are several things you must do.

1. You must not present the image.
2. You must un-acquire the mouse.
3. You must not render anything with drawprimitive, direct access, etc.


This is simple to do. You only need to intercept the correct WM_xxxx message inside of your message loop. If your window is losing focus, Windows will send a message to it notifying you that it is about to lose focus. You should stop rendering, un-acquire devices, and only update non-graphical data - in other words only update the game situation in memory but don't present the final image to the user. Once you regain focus....Windows will also send a message letting you know your program is about to regain focus - you should then re-acquire devices (mouse, keyboard, etc), and set a flag that lets your game know it can now render to the primary buffer. You should also not respond to any keystrokes, change mouse cursors, etc.

If you do not do this when someone minimizes your program or alt-tabs or alt-enters it...you will crash your program. This is because D3D attempts to write to a surface that has lost the focus which results in a lot of problems. Check the SDK for more info...they explain it very well in there. Also Andre Lamothe explains this in his book Tricks of the Windows Game Programming Gurus. Even though that info is for DirectX 7, the techniques and principles also apply to Direct3D 9.0 or DirectGraphics 9.0. Switching tasks is not a D3D dependent task and therefore you should be able to respond to it in exactly the same way that Lamothe does for DirectX. Same idea.

Of course if you don't want to do this then simply trap for the right keystrokes and do not perform anything when they are detected. This, however, is not recommended by Microsoft but it is an approach that many games used to take. I'm finding more and more that newer games are able to handle ALT-ENTER and ALT-TABS as well as CTRL ALT DEL. If you are not handling the windows messages any of these will crash your code.

Sample of an D3D app that uses DirectInput to nullify default CTRL ALT DEL behavior
This may also need to be tested for in WndProc when a WM_KEYDOWN message is sent to the window. Simply do not pass control to DefWindowProc() and Windows won't know that CTRL ALT DEL has been pressed.

This can also be done to nullify other key combos as well.

DIKEYDOWN returns true if key <keycode> is set to true in the array keystate which is a member of class CDirectInput. By ANDing the return values we know if all are down. If one key in the sequence is up, it will change the final result since

1 and 1 and 0=0
0 and 1 and 1=0
1 and 0 and 1=0

1 and 1 and 1=1

Code:

...
if (DIKEYDOWN(DInput.keystate,VK_ALT) & 
DIKEYDOWN(DInput.keystate,VK_CTRL) &
DIKEYDOWN(DInput.keystate,VK_DEL) 
{
  //CTRL ALT DEL pressed - do not send to default processing
 
}
...