Jump to content
  • Advertisement
Sign in to follow this  
Gamer Pro

Input help

This topic is 3588 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

Okay, I got a pretty much off topic on another topic and starting asking questions about input so I figured I should just start another thread and keep the other one for it's own issues. I was using directInput for my input but that was pretty much shot down so I'm switching to using WM_KEYDOWN/KEYUP/CHAR/etc in the window procedure (right now I'm focusing on getting the keyboard working, a few other issues, THEN the mouse). I read an article at: http://www.gamedev.net/reference/articles/article1249.asp. At first I really didn't want to bother with mulit-threading but now as I'm getting more and more comfortable with it, I can't really think of now NOT to use multi-threading. That being said I have two threads (main & game). Main handles the message pump and game handles the game. Now because the message pump is in a thread, the game's window needs to be in that thread (main). I've been told repeatedly (or at lest read repeatedly) that directX should be in the same thread as your window (or else there will be a hit to performance and speed). Which means my directX needs to be in main (my window is in main because my message pump is in main). So I need help on how to handle my input. I want to have my input (keyboard, mouse, etc) to be handled in a SEPARATE thread than my game so the window always detects input and changes to the window itself (such as the window being minimized) so I can choose how to handle it (or simply ignore it) in my game thread (directInput let me do this (for input), but if I'm going to learn how make a game, it may as well be the right way; and if even Microsoft is saying 'don't use directInput' well, nuff said). So far, the only way I've come up with is to have this format: (main thread) create window, create directX object (my wrapper for directGraphics) create game thread message pump.... Using this format (which is copied straight from the article link above), I can only think to pass my directX object to my game thread via the create thread function or via global variable. Is this viable? Or does this still have to same problem as 'your directX needs to be in the same thread' as all my manipulations of directX will be in my game thread? Also with this format, when a key is pressed I figure I'll have a global object handle it (EG: with an array of zeros representing the keyboard and 1 means the key is pressed down, or something) and have my game thread query this via 'getKeyDown' member function or something. My only problem with this is that it uses a lot (well, only really 2) global variables and I was always told don't use them. 99% of the time they are bad style/programming other 1% can be worked around. That, and the hit to performance (from passing my directX object to my game thread). Ideas? Suggestions? Completely different way to do things?

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Gamer Pro
Using this format (which is copied straight from the article link above), I can only think to pass my directX object to my game thread via the create thread function or via global variable. Is this viable? Or does this still have to same problem as 'your directX needs to be in the same thread' as all my manipulations of directX will be in my game thread?
That's a bad idea. You want to only touch any D3D functions or classes from a single thread. If you're in another thread and you touch a D3D object, you're going to give yourself lots of problems.

Quote:
Original post by Gamer Pro
Also with this format, when a key is pressed I figure I'll have a global object handle it (EG: with an array of zeros representing the keyboard and 1 means the key is pressed down, or something) and have my game thread query this via 'getKeyDown' member function or something.
My only problem with this is that it uses a lot (well, only really 2) global variables and I was always told don't use them. 99% of the time they are bad style/programming other 1% can be worked around. That, and the hit to performance (from passing my directX object to my game thread).

Ideas? Suggestions? Completely different way to do things?
Have a message queue going from your main thread to your game thread. The main thread can catch WM_KEYDOWN window messages, and add an input message to your queue. The game thread can then read messages out of that queue, and process it appropriately.
However, going for the array of bool's would be more efficient. You can pass a pointer to your main thread class to the game thread, so you won't be touching globals anywhere.

Share this post


Link to post
Share on other sites
Okay, if I only want to touch D3D from a single thread then I got a problem (surprise, surprise).

Like I said, I want (not really necessarily need but REALLY, REALLY, REALLY want) to handle my input in a separate thread (so it can be detected an any given instant in time).
But I need to handle my window in the same thread as the window procedure (they should change that, lol), I need to handle my D3D in the same thread (because of the window) BUT my input is handled by the window procedure, therefore multi-threading goes out the window.

Ideas? Perhaps for another input method? How's everyone else doing this?

I suppose I can use an insane amount of 'if-else' controls for my rendering so I have:

If (message in queue)
translate & dispatch
else
if (openningCreditsRendered == false)
renderOpeningCredits();
else if (mainMenuRendered == false)
mainMenuDecision = renderMainMenu();
else if (mainMenuDecision == 0)
mainMenuDecision = getMainMenuDecision();
else if (mainMenuDecision == 1)
startNewGame = true;
else if (mainMenuDecision == 2)
return 0;
else if (startNewGameRendered == false)
renderNewGame();
...

and have functions such as 'renderOpeningCredits' render 1 frame at a time, return and continuing to get called until they are finished (letting me get input such as the escape key being pressed, between rendering frames, to skip rendering credits by setting the variable to true).

I'd rather not do this as, if I can get my cake and eat it too, I can simply go
renderOpeningCredits(); // renders credits with an internal loop.
int choice = renderMainMenu(); // renders with internal loop and updates as user presses the arrow keys (EG: new game is highlighted, down key pressed, quit game is highlighted).
My preferred way has been done (by me with directInput, before I had to start from scratch again) but doesn't let me get system messages such as the window is being minimized (such as from alt-tabbing, which started this whole thing).

I find it funny how articles such as the one I posted in my first post and in e-books such as 'Game programming gems 2' (http://books.google.ca/books?id=1-NfBElV97IC&pg=PA82&lpg=PA82&dq=the+%27alt+tab%27+problem+%2B+programming&source=web&ots=SOojdpm_lC&sig=4qDZfZ-VylGByNp0xmO4Bn9pSq0&hl=en&sa=X&oi=book_result&resnum=3&ct=result#PPA83,M1) give you (what I really think is) a gem such as separating the window pump from your game via threads but don't mention the down side (such as performance hit by D3D in a different thread) or whatever.

How bad of a hit is this? Because this is a learning thing (I'm not going to 'publish' this) I'm tempted to just take the performance hit, but at the same time if I do, it negates the whole 'learning the proper way to do things'.

So again, how is everyone else handling this?

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!