Cause that would make sense.

I must have gotten the two confused, but of course if it worked life would be too easy wouldn't it?

I'm sure I know what my problem is, but I need help.

I've got my message pump in a separate thread (main) from my game thread (game). And it's in the game thread that I'm creating my window. So because my game thread doesn't have a message pump (it's in a separate thread) my WM_KEYDOWN isn't firing (I know this because I copied my message pump to my game thread and it did fire). Now I did this because I read it at: http://www.gamedev.net/reference/articles/article1249.asp (and in hindsight this makes sense as it allows the game to detect if the player presses the escape key and to stop rendering the credits (which is a big while loop).

So I read about 'AttachThreadInput' (http://msdn.microsoft.com/en-us/library/ms681956(VS.85).aspx) but my problem is I don't really know how to pass an argument to another thread (in this cause the 'main' thread's ID).

This is what I have (doesn't work):

-------------------------------------------------------------------------------

(main thread, IE: int WINAPI WinMain....)

...
// Thread variables:
HANDLE gameThreadHandle;
DWORD gameThreadId;
DWORD mainThreadId = GetCurrentThreadId();

// Creates the game thread.
gameThreadHandle = CreateThread(0, 0, &GameThread, 0, mainThreadId, &gameThreadId);
if (gameThreadHandle == NULL) {
MessageBox(NULL, threadCreateFailed.c_str(), errorTitle.c_str(), MB_ICONERROR | MB_OK);
exit(error);
}
...

-------------------------------------------------------------------------------

(game thread)

DWORD WINAPI GameThread(LPVOID startingParameter) {
// This is the game thread. All the code for running the game goes here.

// Local variables:
int height;
DWORD mainThreadId = (DWORD)startingParameter;
string name;
int width;
const string settingsFile = "settings\\settings.xml";


DWORD b = GetCurrentThreadId();
BOOL a = AttachThreadInput(b, mainThreadId, TRUE);
...

-------------------------------------------------------------------------------

As I understand I don't need to worry about syncing the threads as the game thread won't start until it's created and when it's created it should have the main thread's id passed to it.

Multithreading like this is usually a bad idea. What you should probably do is have your main thread processing all window messages, and then storing an array of bool's to indicate if a key is down or not. The game thread can then just test those bools to see if a key is currently pressed.

Alternatively, have some sort of mutex locked message queue that the main thread can add to and the game thread can read from. The only problem is if you try to store messages using the exact params passed to your window proc, since pointers will be invalidated.

EDIT: Bah! Too slow [smile]

Mmmmm, this is starting to get out of hand (the off topic-ness). I created a new thread pertaining to this at: http://www.gamedev.net/community/forums/topic.asp?topic_id=520315

I'll leave this thread for the alt tab problem (which as of now has been side-tracked for the input issue). That being said and with the first week of school now done, I want to at lest get the input issued resolved ASAP. Once that's done, my game will more than likely get put on the back burner until the term is over. Which means I'll prob not post anything more on this thread for the next 4-ish months (I'm assuming that won't be too long to 'resurrect' an old thread).

Quote:Original post by Gamer Pro
Mmmmm, this is starting to get out of hand (the off topic-ness). I created a new thread pertaining to this at: http://www.gamedev.net/community/forums/topic.asp?topic_id=520315

I'll leave this thread for the alt tab problem (which as of now has been side-tracked for the input issue). That being said and with the first week of school now done, I want to at lest get the input issued resolved ASAP. Once that's done, my game will more than likely get put on the back burner until the term is over. Which means I'll prob not post anything more on this thread for the next 4-ish months (I'm assuming that won't be too long to 'resurrect' an old thread).

Ok, the short answer is that if you're not doing rendering in the main thread (Where the message pump is), then that's going to cause all sorts of problems and is going to cause you a ridiculous amount of pain.

The only reasonable thing you can do is to put your rendering and window proc in the same thread, and everything else in another thread.