* wonders why nobody has mentioned SDL , or GLUT*
* wonders why nobody has mentioned SDL , or GLUT*
there used to be something here, but not anymore
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.
Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling
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?When programming full-screen Direct3D, one thing that many has trouble doing is recovering from a minimization/application switch.
there used to be something here, but not anymore
Um......last I checked DJGPP was a COMPILER, not a library. Maybe you meant Allegro and SDL?Originally Posted by Bubba
hehe. Good point, Bubba. If nothing else, I can definitely say that this board (and the people here) have helped me learn more than any single textbook!Originally Posted by Bubba
Jason
I meant Allegro combined with DJGPP GCC are a valid combo for learning graphics/game programming because they expose you to how modern graphics are created. Even though scan conversion and texturing are done for you in modern APIs and cards...knowing how to do it in DOS helps a ton.Allegro and DJGPP are extremely valid libraries to use for graphics and games
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 } ...
Last edited by VirtualAce; 07-16-2004 at 08:25 AM.