Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualHodgman

Posted 17 February 2013 - 12:36 AM

that meant you could use AsyncGetKeyState for keyboard, INT 31h for mouse, and didn't need a windows message processor at all.

Implementing a keyboard handler via AsyncGetKeyState rather than the windows message queue is a really bad idea. If the user presses and releases a key for a short period of time that doesn't overlap with the point in time where you poll for that key, then you won't detect that keypress. The user will have pressed a button and you game will have missed it. If you listen the the message queue, you'll correctly receive the press and release messages, no matter how frequently/infrequently you poll the queue. You also get some other useful stuff, like the ability for keys to be converted into characters according to the user's locale for text input, as well as keypress inputs...

 

What's wrong with using the message queue? It's there for a reason -- to separate applications from the hardware so that device drivers can correctly exist in the middle. This way, the device driver can be responsible for knowing how to handle the many different types of hardware out there and translating their inputs into a common structure. As above, it also ensures that your application doesn't miss out on any messages (unless you receive a LOT of messages and poll the queue VERY infrequently).

 

the nice thing about this was that Alt-Tab messages no longer got processed

You could just, listen for that message in the message queue, and return the return-code that indicates that you handled the message, so that the OS won't pass it on to the default message handler.

However, if you're going to do this, you should really make it an option that the user can enable in your menu, because it's a standard convention when doing anything on Windows that the alt+tab combo will work at any time. Breaking conventions like that is really unfriendly to your users; giving them the option to disable alt+tab if they choose to is much nicer. You can also give them the option to disable the windows key if you like.

 

right now, instead of attempting to recover a lost device, i simply exit with a message saying a background process took vidcard access away from the game, and recommend closing any interfering processes and restarting the game.

That's really bad. It's my PC. If I need to quickly alt+tab to reply to an email or order a pizza, and your game quits as a result, then your game is at fault. It would have to be pretty amazing for me to keep playing tongue.png If I want to be restricted to only running one program at once, I would still be running DOS instead of Windows.

 

It's not hard to manage a lost device -- whenever you create any of the resources that need to be recreated, store a pointer to them in some kind of "manager". When you handle the lost device, you've then got a list of resources to recreate in the one spot.

 

If you want to reduce the chances of a lost device occurring in the first place, you can use a "fullscreen window" instead of actual fullscreen mode. You can run your game in windowed mode, but create a window that fill the entire screen, has no border or title bar, and is on top of everything else. This makes it as stable as regular windowed apps (which means it plays nicely with alt+tabbing) but looks like a fullscreen app.


#1Hodgman

Posted 17 February 2013 - 12:34 AM

that meant you could use AsyncGetKeyState for keyboard, INT 31h for mouse, and didn't need a windows message processor at all.

Implementing a keyboard handler via AsyncGetKeyState rather than the windows message queue is a really bad idea. If the user presses and releases a key for a short period of time that doesn't overlap with the point in time where you poll for that key, then you won't detect that keypress. The user will have pressed a button and you game will have missed it. If you listen the the message queue, you'll correctly receive the press and release messages, no matter how frequently/infrequently you poll the queue. You also get some other useful stuff, like the ability for keys to be converted into characters according to the user's locale for text input, as well as keypress inputs...

the nice thing about this was that Alt-Tab messages no longer got processed

You could just, listen for that message in the message queue, and return the return-code that indicates that you handled the message, so that the OS won't pass it on to the default message handler.

However, if you're going to do this, you should really make it an option that the user can enable in your menu, because it's a standard convention when doing anything on Windows that the alt+tab combo will work at any time. Breaking conventions like that is really unfriendly to your users; giving them the option to disable alt+tab if they choose to is much nicer. You can also give them the option to disable the windows key if you like.

right now, instead of attempting to recover a lost device, i simply exit with a message saying a background process took vidcard access away from the game, and recommend closing any interfering processes and restarting the game.

That's really bad. It's my PC. If I need to quickly alt+tab to reply to an email or order a pizza, and your game quits as a result, then your game is at fault. It would have to be pretty amazing for me to keep playing tongue.png If I want to be restricted to only running one program at once, I would still be running DOS instead of Windows.

 

It's not hard to manage a lost device -- whenever you create any of the resources that need to be recreated, store a pointer to them in some kind of "manager". When you handle the lost device, you've then got a list of resources to recreate in the one spot.

 

If you want to reduce the chances of a lost device occurring in the first place, you can use a "fullscreen window" instead of actual fullscreen mode. You can run your game in windowed mode, but create a window that fill the entire screen, has no border or title bar, and is on top of everything else. This makes it as stable as regular windowed apps (which means it plays nicely with alt+tabbing) but looks like a fullscreen app.


PARTNERS