Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualL. Spiro

Posted 16 March 2014 - 06:26 AM

According to stackoverflow delays of the order of 50 ms or so are common in processing key presses through the normal Windows message queue.

That has nothing to do with 2 keys being pressed at once, which should be consistently as far apart in microseconds as you are actually pressing them.


The problem is your method of timing. You should be timing only the point at which WM_INPUT is caught, not all the other code that is run inside WM_INPUT.
In other words, good:

                case WM_INPUT:
                {

                        unsigned long long MsgTime = GetTime();
                        // Do stuff and log MsgTime.

Bad:

                case WM_INPUT:
                {

                        // Do a bunch of stuff, allocate some memory (this is likely why your timings vary so much).
                        …
                        …
                                                Records[Count].Time = GetTime();

You’re aren’t currently timing when the key was pressed, you are timing when the key was pressed, plus some logic plus a call to new.

 

 

V-sync isn’t helping either.  It will lag your input thread unless you are rendering from another thread.  This can easily add 16 milliseconds to your timings, but your first test case does not have this problem.

 

 

L. Spiro


#4L. Spiro

Posted 16 March 2014 - 06:24 AM

According to stackoverflow delays of the order of 50 ms or so are common in processing key presses through the normal Windows message queue.

That has nothing to do with 2 keys being pressed at once, which should be consistently as far apart in microseconds as you are actually pressing them.


The problem is your method of timing. You should be timing only the point at which WM_INPUT is caught, not all the other code that is run inside WM_INPUT.
In other words, good:

                case WM_INPUT:
                {

                        unsigned long long MsgTime = GetTime();
                        // Do stuff and log MsgTime.

Bad:

                case WM_INPUT:
                {

                        // Do a bunch of stuff, allocate some memory (THIS is likely why your timings vary so much).
                        …
                        …
                                                Records[Count].Time = GetTime();

You’re aren’t currently timing when the key was pressed, you are timing when the key was pressed, plus some logic plus a call to new.

 

 

V-sync isn’t helping either.  It will lag your input thread unless you are rendering from another thread.  This can easily add 16 milliseconds to your timings, but your first test case does not have this problem.

 

 

L. Spiro


#3L. Spiro

Posted 16 March 2014 - 06:23 AM

According to stackoverflow delays of the order of 50 ms or so are common in processing key presses through the normal Windows message queue.

That has nothing to do with 2 keys being pressed at once, which should be consistently as far apart in microseconds as you are actually pressing them.


The problem is your method of timing. You should be timing only the point at which WM_INPUT is caught, not all the other code that is run inside WM_INPUT.
In other words, good:

                case WM_INPUT:
                {

                        unsigned long long MsgTime = GetTime();
                        // Do stuff and log MsgTime.

Bad:

                case WM_INPUT:
                {

                        // Do a bunch of stuff, allocate some memory (THIS is likely why your timings vary so much).
                        …
                        …
                                                Records[Count].Time = GetTime();

You’re aren’t currently timing when the key was pressed, you are timing when the key was pressed, plus some logic plus a call to new.

 

 

L. Spiro


#2L. Spiro

Posted 16 March 2014 - 06:21 AM

According to stackoverflow delays of the order of 50 ms or so are common in processing key presses through the normal Windows message queue.

That has nothing to do with 2 keys being pressed at once, which should be consistently as far apart in microseconds as you are actually pressing them.


The problem is your method of timing. You should be timing only the point at which WM_INPUT is caught, not all the other code that is run inside WM_INPUT.
In other words, good:

                case WM_INPUT:
                {

                        unsigned long long MsgTime = GetTime();
                        // Do stuff and log MsgTime.

Bad:

                case WM_INPUT:
                {

                        // Do a bunch of stuff, allocate some memory (THIS is why your timings vary so much).
                        …
                        …
                                                Records[Count].Time = GetTime();

You’re aren’t currently timing when the key was pressed, you are timing when the key was pressed, plus some logic plus a call to new.

 

 

L. Spiro


#1L. Spiro

Posted 16 March 2014 - 06:20 AM

According to stackoverflow delays of the order of 50 ms or so are common in processing key presses through the normal Windows message queue.

That has nothing to do with 2 keys being pressed at once, which should be consistently as far apart in microseconds as you are actually pressing them.


The problem is your method of timing. You should be timing only the point at which WM_INPUT is caught, not all the other code that is run inside WM_INPUT.
In other words, good:

                case WM_INPUT:
                {

                        unsigned long long MsgTime = GetTime();
                        // Do stuff and log MsgTime.

Bad:

                case WM_INPUT:
                {

                        // Do a bunch of stuff, allocate some memory (this is why your timings vary so much).
                        …
                        …
                                                Records[Count].Time = GetTime();

You’re aren’t currently timing when the key was pressed, you are timing when the key was pressed, plus some logic plus a call to new.

 

 

L. Spiro


PARTNERS