Quote:Original post by SimonForsman
Win32 is perfectly fine for for input, just remember that you shouldn't poll the state of the mouse using GetAsyncKeyState, just use the normal WM_LBUTTONDOWN / WM_LBUTTONUP events instead.

Quote:Original post by Evil Steve
The point is that your window is passed these messages anyway, so you're getting them for "free". If the user types "hello" during a single frame (That's going to be 18000 chars / minute or 3600 words per minute, which is stupidly fast), then you'll get 5 WM_CHAR messages in one frame. So long as you buffer them appropriately (Which you should be doing anyway for text input) you're not going to miss any.
GetAsyncKeyState however is only as fast as you call it, so if you were using it, you'd only see a single keypress (if you were lucky).

DirectInput just hooks your window and uses window messages anyway, just in a thread. So it's actually slower than doing it yourself from the overhead of switching threads.

[source = cpp]while(true)	{		//Call the main pump to ditribute messages		MessagePumpReturn = 0;		MessagePumpReturn = WslMessagePump(msg);		//check for application shutdown or proceed to main loop		if(MessagePumpReturn == WSL_MP_QUIT_APP)		{			break; 		}		else if(MessagePumpReturn == WSL_MP_PROCEED)		{			//App code here		}				//Allow windows to take care of other stuff		Sleep(1);	}//located elsewhere int WslMessagePump(MSG msg){	// if there is a message retrieve it	if(PeekMessage(&msg, NULL, 0,0, PM_REMOVE))	{		// check if the message is not a quit message		if(msg.message == WM_QUIT)			return WSL_MP_QUIT_APP;		// deal with message		TranslateMessage(&msg);		DispatchMessage(&msg);		return WSL_MP_QUEU_NOTEMPTY;	}	else // if there are no more messages on the queu then the game could be processed		return WSL_MP_PROCEED;}

Quote:Original post by Evil Steve

Quote:Original post by VanillaSnake21
[By the way an earlier post by Peter5897 mentioned message loops, so do you guys mind looking at mine? Thanks.

*** Source Snippet Removed ***

Is it better for me to process one message, run the game loop, then process another and so on, or just keep what I have now, the game loop doesn't get processed untill the mesgae queu is empty? Thanks

That looks fine, but I wouldn't bother with the Sleep() call (And just let your app run at full speed). You definitely want to process all messages, and then do your app logic, since your app logic could produce one or more messages, which means you'll get a lagging effect.

Quote:Original post by Evil Steve

Quote:Original post by VanillaSnake21
The sleep is there because this app is not really a game, but more of a tool (in windowed mode), and without sleep the cpu just runs at %100, my ingame code doesn't have it though. Thanks for fast feedback [smile]

I'd suggest using GetMessage() instead of PeekMessage() and removing the Sleep(). Then your app will still be repsonsive, and will use hardly any CPU time. If you need to do other processing, you could start a timer that only runs every 100ms or so, then you can handle WM_TIMER to do your logic.

There may be other, better ways to do this, but it really depends on what your app / tool is for.