I''ve read the article on decoupling your mouse from your frame rate and I want to try it out, however the article is vary vague as to the way this is done. There is some code there but the author did not say exactly where what goes. Has anyone tried doing this before and got it working? Please help. OneEyeLeftThanNone - Questions ancwer questions ancwer ancwer questions, questions anyone?

I haven''t read it and don''t know what article you are referring to,
but the basic concept is don''t move your cursor inside your game loop.

And you don''t need to create a new thread for your mouse, just use the
one you already got and process WM_MOUSEMOVE messages inside your
WindowProc like:

    case WM_MOUSEMOVE:         mouse_px = GET_X_LPARAM(lParam);          mouse_py = GET_Y_LPARAM(lParam);          // do screen boundary checking here         ...         //         return 0; 

You will notice that your mouse will move just as smooth as it does
normally in Windows, so you don''t have to do anything special like
trying to de-accelerate it or other weird stuff.

Anonymous Poster: Originally, I was going to say that what you''re doing wouldn''t solve the problem that the article addressed. Then it occurred to me that what you''re doing is just giving the mouse handler higher priority than the game loop, which is okay because it''s so small. Whenever there''s a mouse event, instead of going through with the game loop, it will go through the message loop. I would normally be processed there, but putting the code in that arrangement would indeed separate it somewhat from the frame rate.

However, that wouldn''t separate it completely from the frame rate, as would putting it in another thread. The difference lies in the Windows scheduler and the general design of multithreading.

OneEyeLessThanNone: To create a thread in Windows, you first create a ThreadProcedure, like so:


DWORD CALLBACK ThreadProcedure(LPVOID lpThreadParams)
{
while( g_bThreadStop != false )
{
// Provide your own function here -- just get the input
GetMouseInput();

// Don''t hog the CPU -- let other apps have some time
Sleep(0);
}

return 0; // occurs when the program tells us to shutdown
}



Then you create a global variable, bool g_bThreadStop, which just tells the thread to stop. You set this from WinMain or your game loop when you go to shutdown the program.

Second, you have to call CreateThread() with the ThreadProcedure function as the start address, and using most of the defaults. Save the HANDLE that you get back from CreateThread, and also the ID. The thread will start executing the function that you designed. That thread has access to your program''s global data, so you might want to create a global struct or just some global variables to hold the current mouse data. Have your thread store the current mouse data in those variables.

To use the thread, you just let it keep updating the mouse data. Think of it as a fresh supply of mouse data all the time -- you don''t have to do anything from your game loop except read it from the global variables.

When you go to shutdown the thread, set the g_bThreadStop flag you created earlier to false, which will end the thread''s loop. Use WaitForSingleObject(INFINITE) with the thread handle, and when it returns you can shutdown normally.



- null_pointer
Sabre Multimedia