• 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
Erlex

DirectInput stops reading keys after backgrounded

12 posts in this topic

Hello,

I am fairly new to game programming, especially with DirectX. I am an experienced programmer, but not with DirectX or Windows. Like so many, I am going through Beginning Game Programming 3rd, and I have run into a few recurring problems. But before just posting a giant block of code, I thought I would at least ask if anyone has encountered similar problems.

1. I am unable to get my program to read key presses after the program window is back grounded. Everything works until I bring one window up to the front, and bring my program back. Perhaps there is something wrong with my WinProc function?

2. Not a serious problem, but a rather annoying one; the minimize, maximize, and exit buttons that are supposed to be at the top right of the window are not showing up. My WinMain is consistent with the book's. I haven't a clue on this one.

Any help would be very much appreciated. Thank you in advance!
0

Share this post


Link to post
Share on other sites
If you're not using exclusive access to the device then you'll need to re-acquire it before reading from it any time another process has taken control of it.

Re-acquiring when you already have the device acquired produces no negative results, so it's best to simply re-acquire the device every time before reading its state.

DInput bypasses the winproc. It reads the device state from the hardware rather than from windows messaging, so no worries there.

As for part 2, we'd need to see your window creation routine.

Hope that helps! [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Edited by Khatharr
1

Share this post


Link to post
Share on other sites
Reaquiring the keyboard at the beginning of the game loop did the trick! Thanks Khatharr.

And here is my WinMain. Keep in mind that this is the same code from the book, and that I have only a surface knowledge of windows. Thanks again for the help.
[source lang="cpp"]int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow){
//set the new window's properties
WNDCLASSEX wc; //create window class structure

wc.cbSize = sizeof(WNDCLASSEX);
wc.style = CS_HREDRAW|CS_VREDRAW;
wc.lpfnWndProc = (WNDPROC)WinProc;
wc.cbClsExtra = 0;
wc.cbWndExtra= 0;
wc.hInstance = hInstance;
wc.hIcon = NULL;
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH)GetStockObject(BLACK_BRUSH);
wc.lpszMenuName = NULL;
wc.lpszClassName = APPTITLE.c_str();
wc.hIconSm = NULL;

RegisterClassEx(&wc);

//create new window
HWND window = CreateWindow(
APPTITLE.c_str(),
APPTITLE.c_str(),
WS_OVERLAPPED,
CW_USEDEFAULT,
CW_USEDEFAULT,
SCREENW,
SCREENH,
NULL,
NULL,
hInstance,
NULL);

//check if window could be created
if(!window){
MessageBox(window, "Cannot create window", "Error", MB_OK);
return 0;
}

//display the window
ShowWindow(window,nCmdShow);
UpdateWindow(window);

//initialize the game
if(!gameInit(window)){
MessageBox(window, "Cannot initialize game", "Error", MB_OK);
return 0;
}

//main message loop
MSG message;
while(!gameover){
if(PeekMessage(&message, NULL, 0, 0, PM_REMOVE)){
TranslateMessage(&message);
DispatchMessage(&message);
}
gameRun(window);
}
gameEnd();

return message.wParam;
}[/source] Edited by Erlex
0

Share this post


Link to post
Share on other sites
[quote name='Khatharr' timestamp='1339626780' post='4948955']
DInput bypasses the winproc. It reads the device state from the hardware rather than from windows messaging, so no worries there.
[/quote]
No, actually DInput just runs a message loop for keyboard and mouse input in a separate thread.

Unless you're working with joysticks (and even then), you should be using [url="http://msdn.microsoft.com/en-us/library/windows/desktop/ms645536(v=vs.85).aspx"]raw input[/url], not DirectInput. DirectInput is both deprecated and not recommended for use by [url="http://msdn.microsoft.com/en-us/library/windows/desktop/ee417014(v=vs.85).aspx"]Microsoft[/url]. Edited by Washu
1

Share this post


Link to post
Share on other sites
The only significant difference I see between your window setup and my own is that I ZeroMemory() the struct before setting its values and I don't set a brush. I'm too lazy right now to look the struct up, but I reckon those two changes would probably fix it either way.

As for using XInput instead of DirectInput, a lot of the affordable books out there still refer to DirectInput. Frankly my experience so far has been that anything Microsoft puts out is deprecated 3 days prior to its release. Maybe that's just me. Either way, DirectInput still works. Once you're on your feet you can pick up XInput later.
0

Share this post


Link to post
Share on other sites
I've never used DirectInput for keyboard, but when working with joysticks (maybe it's similar to keyboard), you can use this line:
[CODE]pJoystick->SetCooperativeLevel(m_hWnd, DISCL_EXCLUSIVE | DISCL_BACKGROUND);[/CODE]
and you'll be getting input even when your application is without focus.

BUT - please note that this may not be the same behaviour as you want. As I said, this will mean that your application will be getting the input all the time, when focused and when on the background. In my cases this was exactly what I needed, because my application had to be working always, even when minimised and not visible.

[quote name='Washu' timestamp='1339630036' post='4948978']
Unless you're working with joysticks (and even then), you should be using [url="http://msdn.microsoft.com/en-us/library/windows/desktop/ms645536(v=vs.85).aspx"]raw input[/url], not DirectInput. DirectInput is both deprecated and not recommended for use by [url="http://msdn.microsoft.com/en-us/library/windows/desktop/ee417014(v=vs.85).aspx"]Microsoft[/url].
[/quote]
DirectInput is completely fine for joysticks and other game controllers. It is not recommended by Microsoft for mouse and keyboard. And Microsoft also recommends XInput instead of DirectInput, BUT read my next paragraph below...

[quote name='Khatharr' timestamp='1339643491' post='4949025']
As for using XInput instead of DirectInput, a lot of the affordable books out there still refer to DirectInput. Frankly my experience so far has been that anything Microsoft puts out is deprecated 3 days prior to its release. Maybe that's just me. Either way, DirectInput still works. Once you're on your feet you can pick up XInput later.
[/quote]

You make it sound like if XInput was a replacement of DirectInput. XInput works ONLY with XInput compatible devices - Xbox 360 compatible controllers. There already are some gamepads compatible with this new standard from other manufacturers (I personaly have one from Logitech).
But you still NEED DirectInput to work with other/older devices like joysticks etc.

DirectInput works with everything, including XInput compatible devices. There are just some limitations (for example the two triggers on the Xbox 360 gamepad work as a single axis in DirectInput and thus there will be no difference between both triggers released and both fully pressed).
On the other hand, XInput works ONLY with Xbox 360 devices.

And quoting from the msdn page linked by Washu in his post:
[quote]
By supporting XInput only, your game will not work with legacy [url="http://msdn.microsoft.com/en-us/library/windows/desktop/ee416842%28v=vs.85%29.aspx"]DirectInput[/url] devices. XInput will not recognize these devices.
If you want your game to support legacy [url="http://msdn.microsoft.com/en-us/library/windows/desktop/ee416842%28v=vs.85%29.aspx"]DirectInput[/url] devices, you may use DirectInput and XInput side by side. When enumerating your DirectInput devices, all DirectInput devices will enumerate correctly. All XInput devices will show up as both XInput and DirectInput devices, but they should not be handled through DirectInput. You will need to determine which of your DirectInput devices are legacy devices, and which are XInput devices, and remove them from the enumeration of DirectInput devices.
[/quote]
That doesn't sound like Microsoft not recommending to use DirectInput at all, does it? Edited by Tom KQT
1

Share this post


Link to post
Share on other sites
Thanks for everyone's help.

Khatharr, I tried both zeroing the struct, and messing around with the brush types, unfortunately to no avail.
0

Share this post


Link to post
Share on other sites
Sure thing.
[source lang="java"]LRESULT WINAPI WinProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam){

switch(msg){
case WM_DESTROY:
gameover = true;
PostQuitMessage(0);
return 0;
}
return DefWindowProc(hWnd, msg, wParam, lParam);
}[/source]
0

Share this post


Link to post
Share on other sites
OMG, I failed, lol. Good catch, Endurion. I saw "overlapped" and didn't even finish reading the thing all the way.

@Tom KQT - Sorry, I just assumed that they had upgraded XI to replace DI since it's been quite a while since I downloaded the SDK. You say they don't recommend it for mouse and KB? What do they recommend then? Or was I reading that incorrectly?
0

Share this post


Link to post
Share on other sites
DirectInput is still useful in that it bypasses mouse acceleration (which may be highly desirable if you're doing an FPS), automatically clips to the window's client rect, and automatically hides/shows the cursor for you. It's also extremely well-documented, which is a LOT more than can be said for Raw Input. MS may consider it deprecated, but they have yet to produce anything that fully replaces it's functionality.
0

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