Sign in to follow this  

DirectInput speed

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

Hi, I'm currently using standard windows functions such as GetCurPosition and GetQsyncState and my program does not seem to perform that fast, or at least not as fast as I could imagine direct X performing. For example i have a few buttons (simple DirectX sprites), and I wanted to see how fast I had to press the left ouse button in order for the code to see it as a click. It turned out that very fast click and even some above average speed clicks did not register as clicks and the buttons weren't pressed. So I was thinking that maybe it's because I'm using Win32 functions to poll the mouse. I mean after all, my whole scene is coomposed of 3 buttons (sprites), I'm not doing any rendering in the background or anything, so why is a moderately fast click slipping through unnoticed. I thought maybe if I use Direct X's way of input (DXInput) maybe I'd get better results. I havent even started writing the main code for my app and already the button calls are slipping through. I can't even imagine whats going to happen when I have a 5k poly model in the background. Also, maybe It's not that relevant, my fps something around 60. Is that normal, I mean I've seen full 2D shooter games running at 300 fps or something (I mean their max was that, obviosly all the aniation was in 30fps). Is that because DX is syncing my frame rate with the current refresh rate (which also happens to be 60)?

Share this post


Link to post
Share on other sites
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.


But isn't that slower? I have to wait untill the loop gets to that message, dispatches it, and only then can I catch it in WinProc

Share this post


Link to post
Share on other sites
You are normally going to have something like:

while( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
{
TranslateMessage( &msg );
DispatchMessage( &msg );
}

RunEngine();


which will take care of all messages before getting to your game loop.

Does your loop work differently?

Share this post


Link to post
Share on other sites
Quote:
Original post by VanillaSnake21
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.


But isn't that slower? I have to wait untill the loop gets to that message, dispatches it, and only then can I catch it in WinProc
And since when do you expect users to press keys faster than the screen updates? [smile]

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.

Share this post


Link to post
Share on other sites
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.


Thanks, thats what I wanted to know. So I' basically better off sticking to Win32 input. For some reason I though that interacting with the user through messages was such a slow process, I'll try to use them from now on.

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

[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;
}




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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.



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]

Share this post


Link to post
Share on other sites
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.

EDIT: In any case, Sleep(1) is pretty pointless, it'll make hardly any difference to the frame time and won't make other applications more responsive.

Share this post


Link to post
Share on other sites
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.


Thanks, I never thought of that, I'll try using GetMsgs intead. The goal of this tool is to let me keyframe the transformations of a sprite, and write that animation to an external script file. I will use that script file in my gae to play back the aniation. I suppose I can get away with GetMsg here since I'm not doing anything intensive. Thanks

Share this post


Link to post
Share on other sites

This topic is 3373 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this