Author Topic: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!  (Read 16964 times)

eragon2890

  • Posts: 1887
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #60 on: December 21, 2016, 12:44:33 pm »
What's wrong with me for not noticing any thing? I can't notice a difference, no matter how hard I try, between playing blazblue or astebreed on my GPD Win or on my desktop with xbox360 controller, and my performance is also identical...

my WIN has driver crashes sometimes but I can live with it (most games recover and it doesn't happen every 5 minutes and it never powers off and only in intensive games) but otherwise it's perfect...

Then again, there were people complaining android had horrible input lag and they couldn't play snes games or at least missed all their super mario world jumps on their GPD Q9 or XD... but personally I can switch between a real snes, Q9, WIN, and my desktop, and I don't even notice the difference... not even when trying to speedrun. :-/

Something wrong with me? XD am I getting slow on my advanced age of 25?

jimboton

  • Posts: 35
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #61 on: December 21, 2016, 01:13:32 pm »
Ok, so feeling a bit frustrated at not having a reliable way to test xinput response, I decided to build my own. Sakya's test is ingenious but I don't really know how the polling rate is obtainted, and whether it is valid for game controllers and not just mice.

I downloaded XinputDotNet (https://github.com/speps/XInputDotNet), which is a C# wrapper library around XInput that's used in .Net and Unity games.

This library has a 'Dotnetdemo' application that simply shows the xinput controller status via console. I modified this console application to measure the time the 'A' button is registered as pressed. Code I wrote is really simple. So simple I'm copying it right here so we all know what it does:

Quote
class Program
    {

        static bool counting = false;       
        static Stopwatch sw = new Stopwatch();
        /// <summary>
        ///
        /// </summary>
        /// <param name="args"></param>
        static void Main(string[] args)
        {
           
            System.Timers.Timer aTimer = new System.Timers.Timer();
            aTimer.Elapsed += new ElapsedEventHandler(OnPoll);
            aTimer.Interval = 1;
            aTimer.Enabled = true;
            while (true)
            { }               
            }

        private static void OnPoll(object source, ElapsedEventArgs e)
        {
            GamePadState state = GamePad.GetState(PlayerIndex.One);           
            if (state.Buttons.A.Equals(ButtonState.Pressed))
            {
                if (!counting)
                {
                    sw.Start();
                    counting = true;
                }
            }
            else
            {
                if (counting)
                {
                    sw.Stop();
                    Console.WriteLine("'A' button depress time:" + sw.ElapsedMilliseconds + " ms");
                    sw.Reset();
                    counting = false;
                }
            }

        }
    }

How does this work? I execute Xinputdemo and then I press A button for as short a time as I can. The lowest press interval detected is an upper bound to the time between polls (the inverse of which would be a lower bound to the polling rate).

What happened?

On my desktop, with a xbone controller, the minimum depress time I could get consistently was 15 ms.

On my Win, with that same controller plugged in, the minimum depress time I could get consistently was also 15 ms.

On my Win, with the Win's controller set to Xinput mode, the lowest depress time I could get was 46 ms.

tl;dr: I do not think the firmware fixed the issue. Perhaps it's not the polling rate (riiight), but the thing is, it was not possible to time a button press for less than 3 frames, and still isn't.

If someone wants to test this on their Win, you can download XinputDotNet and the code above and build it or just get the executable from here (1 executable, 2 dll's): http://s000.tinyupload.com/?file_id=19924952393845576851

If someone sees a flaw in my code or my method I'll be very happy to know. I'm not an expert in game controller programming.
« Last Edit: December 21, 2016, 07:56:59 pm by jimboton »

Mountainmohawk

  • Posts: 80
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #62 on: December 21, 2016, 06:13:13 pm »
Ok, so feeling a bit frustrated at not having a reliable way to test xinput response, I decided to build my own. Sakya's test is ingenious but I don't really know how the polling rate is obtainted, and whether it is valid for game controllers and not just mice.

I downloaded XinputDotNet (https://github.com/speps/XInputDotNet), which is a C# wrapper library around XInput that's used in .Net and Unity games.

This library has a 'Dotnetdemo' application that simply shows the xinput controller status via console. I modified this console application to measure the time the 'A' button is registered as pressed. Code I wrote is really simple. So simple I'm copying it right here so we all know what it does:

Quote
class Program
    {

        static bool counting = false;       
        static Stopwatch sw = new Stopwatch();
        /// <summary>
        ///
        /// </summary>
        /// <param name="args"></param>
        static void Main(string[] args)
        {
           
            System.Timers.Timer aTimer = new System.Timers.Timer();
            aTimer.Elapsed += new ElapsedEventHandler(OnPoll);
            aTimer.Interval = 1;
            aTimer.Enabled = true;
            while (true)
            { }               
            }

        private static void OnPoll(object source, ElapsedEventArgs e)
        {
            GamePadState state = GamePad.GetState(PlayerIndex.One);           
            if (state.Buttons.A.Equals(ButtonState.Pressed))
            {
                if (!counting)
                {
                    sw.Start();
                    counting = true;
                }
            }
            else
            {
                if (counting)
                {
                    sw.Stop();
                    Console.WriteLine("'A' button depress time:" + sw.ElapsedMilliseconds + " ms");
                    sw.Reset();
                    counting = false;
                }
            }

        }
    }

How does this work? I execute Xinputdemo and then I press A button for as short a time as I can. The lowest press interval detected is an upper bound to the time between polls (the inverse of which would be a lower bound to the polling rate).

What happened?

On my desktop, with a xbone controller, the minimum depress time I could get consistently was 15 ms.

On my Win, with that same controller plugged in, the minimum depress time I could get consistently was also 15 ms.

On my Win, with the Win's controller set to Xinput mode, the lowest depress time I could get was 46 ms.

tl;dr: I do not think the firmware fixed the issue. Perhaps it's not the polling rate (riiight), but the thing is, it was not possible to time a button press for less than 3 frames, and still isn't.

If someone wants to test this on their Win, can download XinputDotNet and the code above and build it themselves or just get the executable from here (1 executable, 2 dll's): http://s000.tinyupload.com/?file_id=19924952393845576851

If someone sees a flaw in my code or my method I'll be very happy to know. I'm not an expert in game controller programming.

Good to see some more confirmation of it. I noticed something was off as soon as I tried playing some rythym based games.

shinkamui

  • Posts: 395
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #63 on: December 21, 2016, 06:50:18 pm »
What's wrong with me for not noticing any thing? I can't notice a difference, no matter how hard I try, between playing blazblue or astebreed on my GPD Win or on my desktop with xbox360 controller, and my performance is also identical...

my WIN has driver crashes sometimes but I can live with it (most games recover and it doesn't happen every 5 minutes and it never powers off and only in intensive games) but otherwise it's perfect...

Then again, there were people complaining android had horrible input lag and they couldn't play snes games or at least missed all their super mario world jumps on their GPD Q9 or XD... but personally I can switch between a real snes, Q9, WIN, and my desktop, and I don't even notice the difference... not even when trying to speedrun. :-/

Something wrong with me? XD am I getting slow on my advanced age of 25?

Try  running street fighter 3 or any of the alphas in retroarch, or your favorite FBA emulator.  The arcade perfect emulation requires the order and  timing of the dpad rotations to be accurate, where pc ports tend to be more forgiving with the key combinations.  Try to execute Ryu or kens supers with the dpad, then try your plugged in 360 controller.  You will find that you can do it every time on the 360, and you may luck into pulling it off with the gpd dpad.  Thats the lag people are complaining about.  If you record the gamepad strokes and roll the dpad in a qcf or qcb over and over repeatedly, you'll find the 360 controller produces the rolling motion every time showing all 3 directions in the quarter circle, where the gpd will only register down and left, or down-left and left quite frequently, missing one of the directions altogether.   This is where the polling concerns come in.   Even if you don't play fighters this rate introduces a nasty bit of lag that breaks a lot of classic games being emulated.  Try super meatboy at the higher levels and see how quickly frustrating the controls get.
« Last Edit: December 21, 2016, 06:56:12 pm by shinkamui »

jimboton

  • Posts: 35
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #64 on: December 22, 2016, 08:55:12 pm »
Small update concerning my testing of the Win's controller response in xinput mode.

The code I wrote was using the System.Timers.Timer .NET class that is generally assumed to have a precision of only 15 ms. I suspected this was the reason why I could not register a depress time lower than 15 ms with the Xbox One controller.

Lucky for me I stumbled upon Ken Loveday's MicroTimer class in CodeProject (https://www.codeproject.com/articles/98346/microsecond-and-millisecond-net-timer). Using this class it was possible to rewrite the code so my little test could be done with a precision of around 1 ms. And this is the result:

Xbone controller in desktop: 7-8 ms
Xbone controller in GPD Win: 7-8 ms
GPD Win controller in XInput mode: 47-48ms

Like I suspected, the Xbone controller's polling was faster than 15 ms (8 ms should be the true minimun with the known USB 125 Hz polling rate). The Win controller, on the other hand ... :(

Guys... it's still ~ 20 Hz. In XInput mode.

If someone wants to have a go at the test the new one is here: http://s000.tinyupload.com/index.php?file_id=60622687031905020596


Sinael

  • Posts: 75
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #65 on: December 23, 2016, 12:05:28 pm »
@jimboton
Thanks for your contributions to the topic!

Can you also test the poll rate for DInput and mouse modes? Would it be possible to remap keys from mouse/dinput mode to emulate xinput at higher poll rate?

shinkamui

  • Posts: 395
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #66 on: December 26, 2016, 08:22:15 am »
well, this thread is stalled for now... looks like   Jan 10th is the day of reckoning.  Im cautiously optimistic they managed to fix the problem.  The windows driver doesn't appear to be the problem, the polling rate is set to default for the usb device.  We can only hope they fixed whatever they're doing in the firmware to actually match the driver rate in the next update.  I suggest you guys don't let this die, we finally got some traction and while GPD is putting eyes on the issue, we need to press forward with letting them know how important this is.  For those of you playing games that "aren't affected" at some point you will probably be affected, and if your voice isn't heard it will be too late then.  Once they move on, don't expect updates.  Lets get this fixed now, and correctly, this might be our last and only X86 gaming handheld of this form factor.
« Last Edit: December 26, 2016, 08:24:23 am by shinkamui »

Kilrah

  • Posts: 58
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #67 on: December 26, 2016, 11:21:25 am »

jimboton

  • Posts: 35
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #68 on: December 26, 2016, 12:19:37 pm »
Aaaaand.... it's fixed! I can get 7-8 ms timings now with the Win's controller using my xinput test :)

Playing Shantae 1/2 now she seems to jump before I press the button  ;D


SacaSoh

  • Posts: 85
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #69 on: December 26, 2016, 02:45:17 pm »
Kudos for GPD, and thanks for you guys here that took the time to scientifically test the gamepad  :) without you I bet GPD wouldn't even be aware of the issue.

Exhumed

  • Posts: 5
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #70 on: December 28, 2016, 10:01:59 am »
And this, my friends, seals the deal for me. Nice job from both the users and the company. Thank you!

shinkamui

  • Posts: 395
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #71 on: December 30, 2016, 01:43:56 am »
Im still seeing dropped inputs when i record dpad qcs.  Its night and day better, but its still not matching the 360 for reliability.  Perhaps there is something to the 2nd part of their revision, the membranes may just plain stink... Im hoping they can tweak a little further, my gpd shipped with a stripped screw and I'd rather not have to drill the head off to open it.

frostedfires

  • Posts: 5
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #72 on: January 11, 2017, 12:28:56 am »
Can someone test the new firmware for the gamepad and see if the polling rate was enhanced at all?

Maniac

  • Posts: 421
Re: Increase polling rate for GPD Win controls? It's REALLY SLOW right now!
« Reply #73 on: January 11, 2017, 10:40:55 am »
Can someone test the new firmware for the gamepad and see if the polling rate was enhanced at all?

It was fixed with the last one, why would they fix it again? Unless you're testing for regressions.

 

Post a new topic
Post a new topic