Using GameInput adds big Timer event overhead to AIR app execution

[zeh]

When using GameInput by merely referencing GameInput.numDevices, an overhead of about 38ms for internal Timer event execution is added to Flash player once every second.

I have a "sandbox" AIR 3.8 Flash project that does nothing other than trace some properties to the console. Execution of this sandbox in Adobe Scout (with a non-debug SWF, using advanced-telemetry, and with all unnecesary options disabled to avoid overhead) looks like this:

It's all well and good. However, the mere addition of trace(GameInput.numDevices) once changes the execution radically. The result is this:

Every second, there's a ~38ms event overhead. Apparently, after the first reference to numDevices, the player starts checking for device addition/removal once per second, but it takes some time to do so (again, no other code is being executed).

To be fair, I'm not sure exactly of the impact of that in actual execution. Apparently, it's only adding 6ms to the time it takes to go from ENTER_FRAME to EXIT_FRAME. But even if that's the case, with a budget of ~17ms per frame, that's considerable overhead.

This was tested on a PC with Windows 7. Player/Air version was WIN 11,8,800,88. No devices were actually attached to the computer.

I haven't tested with Android/OUYA. I know GameInput works, but I haven't been able to test if the overhead is there.

I can provide more details, but it should be easy to reproduce on its own. All you need is a reference to GameInput.numDevices.

My question is: is this expected or is it part of something that's still being worked? The addition of the GameInput API to the desktop version of AIR is most welcomed, but a potential 223% execution budget overhead on a frame once every second is potentially disastrous for games since it'd mean constantly skipping frames.

[simplezeroec]

Thanks for your report. And this issue has been confirmed with the developer and an overhead is expected on windows. More info is here:

"  The Windows version of the GameInput API checks every 1 second if devices are attached (calling numDevices or instantiating the GameInput class does start this check).  This should not be an issue on Mac or Android since they listen for an event (Mac Chrome might see this issue)." --from dev.

[zeh]

Thanks simplezeroec. That is helpful. Do you mind if I ask where does this quote come from? I'm having a hard time finding more information on those APIs.

Also, even if it's expected - do you (or anyone else) know if this is gonna be the case when 3.8 is out of beta, or in next versions? A 223% budget overhead is... less than desirable in games, even if only once every second. I can understand why it's in there from a developer perspective, but from a player perspective...

[HypoLast_1]

I encoutered this exact same thing late last night. I'm also curious if there are plans for this to be fixed (I guess it's not exactly broke... improved?) with the full release of AIR 3.8? In the meantime is there a workaround? I would think that it isn't absolutely necessary to check for new connections every second most of the time. Is there some way to turn off this timer once a connection to the device has been created?

Like zeh said this doesn't really affect development, but it does make the app a little jarring to play. I'm experiencing a ~66ms frame once per second, so all of my sprite movements appear to jump around.

[simplezeroec]

Hi HypoLast,

Could you please share your app to Adobe so we could reproduce this performance issue? Our testing game is playing smoothly and sees no big performance problem.

And this overhead issue has been tracked in our inner bug database. If there is any status update, I will post the message asap. Thanks for your support.

[Dapalito19821992]

Oh man, this is an absolute must fix.

Does it occur in the Flash Player as well ?

You might also want to create a bug report at http://bugbase.adobe.com , linking to this thread, and then post back a link to the bug report in this thread

It will help getting things done faster when an Adobe staff person comes here.

[HypoLast_1]

Dapalito, I think that the GameInput and other relevant classes are AIR only, so these problems don't happen in the web player because they can't

I don't think a bug report is necessary since the performance issue is already being tracked (and I assume worked on?) and this isn't exactly a bug, but thanks for the suggestion!

[Dapalito19821992]

Hey,

Oh right, simplezeroec is apparently Adobe's staff. I failed to read his last paragraph properly and thought he was part of a game dev company interested in getting this issue fixed. (The "member" tag instead of "staff" tricked me)

So yes if Adobe is tracking this in private we don't need to create a public report and my intervention was useless

Now regarding Flash... Flash 11.8 supports gamepads. I'm yet to test it but, unless it's using another API, it looks like Flash now supports GameInput. Am I missing something ?

[HypoLast_1]

So it does, my mistake. If anything that means they should be focussing even more on getting them working properly on all systems. Thanks for pointing that out

[HypoLast_1]

Thank you for the fast reply. Here is a link to the github repo that my test project is at. It's pretty small and is just my first attempt at moving a ball around with a Logitech controller. https://github.com/HypoLast/GamePadTest

I also used Adobe Scout to profile the app and uploaded a sample result to TinyPic with one of the 67ms frames highlighted. http://tinypic.com/view.php?pic=2r4t084&s=5

Steps to reproduce:

1. Test project or publish, install, and run.

2. Move around with the d-pad or left analog stick on your gamepad. A to jump, triggers to dash.

3. Profiling with adobe scout or watching the text field in the upper left corner of the app will show large frame times about once per second.

[practical_code1549]

simplezeroec wrote:

Hi HypoLast,

Could you please share your app to Adobe so we could reproduce this performance issue? Our testing game is playing smoothly and sees no big performance problem.

And this overhead issue has been tracked in our inner bug database. If there is any status update, I will post the message asap. Thanks for your support.

Hi, any update on this? As you can see, the issue is quite obvious when using Scout to profile:

In this state, the API is unusable. We're dropping 4 entire frames every second! Visually it completely ruins the smoothness of the game.

65ms is an INSANE amount of overhead. In order to not effect the frameRate of the game, you need to be shooting for 2-3ms at most. What could you possibly be doing that takes 65ms in native code?? It's mind boggling...

[simplezeroec]

Dev is fixing this issue. And please wait for the future release.

[zeh]

As of Adobe AIR 3.9 beta 790, this problem has to been resolved - I'm running a game with GameInput support, using my XBox 360 controller, and I see no discernible slowdown or timer events tracked by Scout.

Can anyone else verify if that's the case?

[practical_code1549]

Yep, just tried tracing the numDevices and the huge lags are totally gone. Thanks guys.

[HypoLast_1]

It's working great for me too. Thanks a bunch I'm looking forward to making some cool games that have gamepad support!

[zeh]

Aaaand the problem is back on 3.9.0.1030 (3.9 stable).

[simplezeroec]

Confirmed with dev, yes , this code change has not been submittted into 3.9.0.1030 considering some other bugs. I will update this comment once there are new updates about the schedule.

[esDotDev]

Hi Any update on this?? It's been like 3 months now where this API is basically unusable on Desktop (it's primary use-case I imagine).

What's going on Adobe? I don't understand why you would put in all the work to create a feature, and then leave it functionally broken for 3mths due to some minor bug.

Is there any chance this can be fixed in the next release? We are launching on Steam soon, and really _really_ need this API fixed ASAP.

[practical_code1549]

+1, this is long overdue.

[JunWu123]

This issue has been raised to high priority, and have been fixed internally and in beta release. Formal release with the fix would come out soon.

[chris.campbell]

Hi Guys,

Sorry that this is occuring.  I am going to let the team know about this thread to make sure we are aware of the issue.  Does anyone have a bug number that I can reference?

Thanks,

Chris

[zeh]

Hi Chris, thanks so much.

There's one bug report about the same problem:

https://bugbase.adobe.com/index.cfm?event=bug&id=3660823

I'd say this thread has more information on the problem, though.

[3134957]

Thanks for your bug reporting.

I am investigating the issue and confirmed the issue reproduced on AIR3.9.0.121 but fixed in AIR 4.0.0.139 beta build, please try to download beta build from http://labs.adobe.com/downloads/air.html to verify your issue or be patience for our next release build.

[zeh]

I can confirm that as of 4.0.0.1390 the problem seems to be gone again. There are no timer events hindering performance and it seems to be working as expected.

[zeh]

As of FP 12.0.0.44 the problem is back again.

https://dl.dropboxusercontent.com/u/16044357/scout_gameinput_again.png

https://dl.dropboxusercontent.com/u/16044357/scout_gameinput_again_2.png

On top of that, it's not even recognizing all the devices I have installed properly. But that's another discussion I suppose.

I'm trying to be optimistic, but GameInput really needs some love. Not to add features, but to make it work like it's supposed to. I don't think it has ever been the case, except under very specific circumstances.