Jump to content
  • Advertisement
Sign in to follow this  
roloenusa

Window doesn't recover after regaining focus

This topic is 3702 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone, I'm fairly new to game programming. I'm currently having an issue with my game window. When I first run the program all input works. However when the window loses focus (alt+tab, etc) does window doesn't seem to recover properly. The game window comes back up, but no input is accepted. I tested my game loop as well as some other functions. I think i narrowed down the issue to Key_Down(int) and/or Poll_Keyboard(). It seems that no information is passed to this two functions when the window regains focus. Anyone has any idea why this might be? I'm not sure what piece of code to post here: void Poll_Keyboard() { dikeyboard->GetDeviceState(sizeof(keys), (LPVOID)&keys); } int Key_Down(int key) { return (keys[key] & 0x80); } edit: Forgot to put a title =) [Edited by - roloenusa on June 27, 2008 1:33:38 PM]

Share this post


Link to post
Share on other sites
Advertisement
If you don't already, you need to trap WM_KILLFOCUS and WM_SETFOCUS. KillFocus should set a flag or otherwise stop I/O processing. SetFocus should restore processing.

When your window loses focus, it loses user input so there's no sense polling input it shouldn't be receiving. Depending on what your program does when it's active, you may want to suspend all activity (except for WM_PAINT, which should just Present the last frontbuffer and nothing else).

Share this post


Link to post
Share on other sites
This isn't necessarily related to your problem here, but make sure you're also set up to recover from a lost device. There's detailed info on how to do that over in the documentation.

Share this post


Link to post
Share on other sites
Quote:
make sure you're also set up to recover from a lost device

Absolutely! If you trap WM_KILLFOCUS and suspend activity, then the first DX-related activity to do on WM_SETFOCUS is to check the device status.

Share this post


Link to post
Share on other sites
Thank you so much for the prompt responses!

I apologize, i'm fairly new to DirectX and game programming. I set up a case under my winproc function. Is this correct? It seems to work perfectly as per my testing!

Now, i only set WM_SETFOCUS as follows:

case WM_SETFOCUS:
static bool init_Setfocus = 0; //false= Initialize with the proper functions
//true= get the keyboard and mouse back

if (init_Setfocus != 0)
{
if(!Init_Keyboard(hWnd))
MessageBox(hWnd, "Error initializing the keyboard", "Error", MB_OK);
if(!Init_Mouse(hWnd))
MessageBox(hWnd, "Error initializing the mouse", "Error", MB_OK);
}

init_Setfocus = true;
return 0;

This works and serves the purpose for now i guess. At least until i learn a better way to handle things.

Now, is it necessary to set up WM_KILLFOCUS as well? is it just a responsible thing to do, or only if it's require by the gameplay? What should be included in WM_KILLFOCUS? i imagine just the release the device statements.

Share this post


Link to post
Share on other sites
Sorry, the "device" we were referring to is the IDirect3DDevice9 (or whatever version of DX you're using). Your application should have routines to be called when the D3D device is lost and when it is reset, perhaps named OnDeviceLost() and OnDeviceReset().

Each loop through your application's run code should test for a lost device before the device is used for anything, perhaps using something like

pDevice->TestCooperativeLevel();

One of the reasons for trapping WM_KILLFOCUS and suspending activity is that another application may cause your device to be lost. If you continue running when the device has been lost, the result will be indeterminate.

Another reason for trapping WM_KILLFOCUS and suspending activity is that the user has implicitly stated that it's not your application s/he wants to be using at the moment. Out of courtesy, you should stop what you're doing until the user returns attention to your app![smile] If you don't suspend activity and you have a proper run loop, testing for a lost device, your code could reset your device, causing the other application's device to be lost, causing your app to reset, etc. That's just not good practice.

If you have a proper run loop, WM_SETFOCUS isn't as important as WM_KILLFOCUS. If setfocus resumes activity, then the run loop will take care of "discovering" the lost device and doing the proper recovery. That recovery would include checking the keyboard device, etc.

Suggestion: if you're not too invested in DInput (actually, even if you are), don't use it. Use the normal windows messaging system to get input from the user (WM_CHAR, WM_KEYDOWN, WM_KEYUP, WM_MBUTTONDOWN, etc.). That will be plenty fast enough in the vast majority of cases.

That will also take care of a loss of focus as your window won't receive character input.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!