• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Stephany

Issue when game starts unfocused (Windows)

5 posts in this topic

Hello,

 

I've run into an issue involving windows focusing and Input, but the problem is more related to windows focus. Basically, I've programmed the mouse cursor to freeze onto the center of the screen when the game starts, to allow the user to rotate the camera. The user can then switch back and forth between camera mode and cursor mode by right clicking. However, the game relies on the WM_ACTIVATEAPP message to forcibly switch back to cursor mode so the mouse doesn't get locked up while the game is unfocused. The game also goes into a low-processor mode at this time. This is all fine, and seems to work most of the time.

 

 

The problem I'm encountering only seems to happen when the game starts unfocused. I know this is a rare situation, but I'm hoping there is a solution, nonetheless. When the program's window is created while another window is on top of it, it starts up without ever receiving a WM_ACTIVATEAPP message, so I'm not sure how to detect the situation.

 

Is there any other way to detect your app starting in the background? Or maybe a better way to handle the whole focus/unfocus situation? Or should I just ignore this problem, knowing that very few players will ever start the game and immedately jump to another window?

 

Thanks much for any advice

0

Share this post


Link to post
Share on other sites
You can use the GetFocus() function to determine if any windows owned by your program have focus. If you initialize based on this state and then handle WM_ACTIVATEAPP as you currently do, you should have your bases covered.
2

Share this post


Link to post
Share on other sites

Yes, that will help significantly. Thank you. I think I'll create a CheckFocus() function that can be called anytime something (such as input polling or graphics locks) doesn't succeed, then this function can check the focus state using GetFocus() and manually trigger an unfocus when another window is above it. My input system was already spamming its text log with "GetDeviceData() failed" messages, so this sort of fixes both problems. Thanks again.

0

Share this post


Link to post
Share on other sites

Ok, really strange thing to report. GetFocus() appears to be returning my window's handle, even when it starts in the background. The titlebar to my application is color-coded as per unfocused windows, yet the function continues to return my app's window handle. Does this make any sense?

 

Microsoft's description of GetFocus() is that it shows the focus for the keyboard. Is it possible that my application has the keyboard focus even though its being covered up by several other windows with mouse focus? edit: I can type into text boxes while its happening, so it seems unlikely.

 

Note that once I focus my game and then click on another window, everything responds correctly as it should. Its just the starting up unfocused part that is really throwing me off. Has anyone else run into this issue?

 

Its pretty tricky to actually test this (start an app and then bring another one into the foreground before the first app's window is created). I've actually been relying on Visual Studio's "Start Debugging" command to slow it down for me. Is it possible that Visual Studio is interfering with the focus states? edit: nope, I just tried using Sleep() before my window is created, and it has the same effect.

Edited by Stephany
0

Share this post


Link to post
Share on other sites

I haven't set up a test for this, but you might try calling GetForegroundWindow() after you create your window to see if the user is still with you. You should also keep track of WM_SETFOCUS messages.

1

Share this post


Link to post
Share on other sites

You cannot rely on the titlebar color to tell you that your window has focus. The titlebar only tells you that a window is active. A window can be focused without necessarily being active. Also, the active window is usually indicated by the titlebar color, but some floating-toolbar implementations (like those in MFC) usually override this as well (by suppressing the WM_NCACTIVATE message or changing some flags in it, IIRC). The only way to tell if your window has focus is via the WM_SETFOCUS message (or with the GetFocus API).

Also, the mouse doesn't have much to do with all this. It might be that the window needs to be focused first, before it can acquire the mouse capture (SetCapture, assuming you're using this), but I'm not 100% sure about this - I haven't tested it in recent Windows versions. In windows XP, I think any window could have the mouse captured. Even so, any other window is free to take away the mouse capture at any time. I think you can stop that from happening by not calling DefWindowProc for WM_CANCELMODE - "the system sends this message to the active window when a dialog box or message box is displayed".

 

And by google-ing all these window messages, I found this article, which seems to do a better job at explaining things than I did: http://www.drdobbs.com/avoiding-trouble-with-mouse-capture/184416474 smile.png

Edited by tonemgub
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0