Archived

This topic is now archived and is closed to further replies.

bilsa

ALT-TAB?

Recommended Posts

Hello! I have been reading some posts on the "alt tab" issue here on the gamedev forums. What I have come to is that when my application gets activated, a WM_ACTIVATE message is sent. Then in my messagehandler I take care of this message by first restoring all surfaces, then releasing them and then recreating them again? so this is what I have done...
      
case WM_ACTIVATE:
{
.
.
.
	if ( dx.ps->IsLost() ) //checking is the primary surface is lost... 

	{      
		dx.Restore(); // restores all "default surfaces and stuff created with my DX object". The dx object handles all shiet about DX surfaces and such...

		dx.ReleaseSurfaces(); // here I release all surfaces that might have been created...

		dx.InitSurfaces(); // here I init the released surfaces...

		currentGame->Restore(); //currentGame is a pointer to the "gamestate interface" that is currently active


		currentGame->ReleaseObjects(); // Releasing all Bitmaps that have been loaded to a surface and other stuff...

		currentGame->InitObjects(); //Init all the Bitmaps and stuff that I just released...

	}
.
.
.
}
      
But still I get only a black screen. Have I got the idea right or am I still missing something? What might I have done wrong? Thx! [edited by - bilsa on April 28, 2003 11:44:41 AM] [edited by - bilsa on April 28, 2003 11:45:09 AM]

Share this post


Link to post
Share on other sites
How about an alternative...

Have you considered not going for a really 'D3D-fullscreen' application? Several big names in the game industry
(and smaller ones too) will instead pull a stunt of resizing the desktop to the resolution requested by the game, and put it into a borderless window that covers the desktop.

Sure, you lose a tidbit of processor power since the windows under your own still 'exist' on the desktop, BUT there are good points too:
-Eases initialization of Direct3D.
-'Available modes' are more trustworthy through the Win32 API than through DirectX's caps. (Trust me, I've made a test app who said I could run at 1280x768 32bits 120 Mhz, the Win32 API said I couldn't)
-Alt-Tab will no longer invalidate stuff.
-Visual C++'s debug mode is more friendly.

Of course this option is very arguable, but I told myself "If it's good enough for John Carmack/Quake3, it's good enough for me."
I managed to do it in a little experiment of mine. www.geocities.com/francois_dion/CodePage.html puts up a link to Mechaengine. (I'll update it to the latest version around April 30th)

(edit
Darn, I just noticed: Be careful, WM_ACTIVATE will change its wParam depending if you are entering your app, or leaving it. As in:

  
case WM_ACTIVATEAPP:
// This message is sent when the application is

// either entering the foreground or leaving it.

bForeground = wParam;
if (bForeground){
// This API call will 'restore' the window.

ShowWindow(hWnd, SW_SHOWNORMAL);
} else {
// Despite the API's name, this will just minimize the window.

CloseWindow(hWnd);
}
break;


I'm not sure you want to rebuild your surfaces when you -leave- by alt-tab, right?

[edited by - Spacecat on April 28, 2003 2:55:13 PM]

Share this post


Link to post
Share on other sites
Detecting Alt-Tab is not the way to go about this -- it''s only one of many ways that the device can be lost. Investigate TestCooperativeLevel and checking for D3DERR_DEVICELOST on Present.

One problem with using a full-screen window is that it can be quite a bit slower because the pixels have to be copied from the back buffer to the window. In full-screen with D3DSWAPEFFECT_FLIP/DISCARD the back buffer can be presented directly (nearly instantaneously).

Share this post


Link to post
Share on other sites
Use functions that comes with DirectX to detect lost focus such as TestCooperativeLevel(), and restore you game only in responding to the return value of that function.

Use WM_ACTIVATE only to know whether your application is on active or not. If it''s not active, you should call WaitMessage() to reduce memory usage while your game isn''t active. If it''s active, you should call TestCooperativeLevel() to see if you game resources need to be restored or not.

You can check whether you app is active or not in WPARAM (or LPARAM? I don''t remember, check MSDN).


Current project: A puzzle game.
% completed: ~0%
Status: Active.

Share this post


Link to post
Share on other sites