The case for integrated, native physics in the Flash Runtime

Question

Hello everyone,
As hopefully many of you know, a community based feature request page was created a few months back (Feature request for Flash and Air - uplist) and we've had a number of great ideas added and voted on.  In an attempt to better understand the individual requests, we thought we'd start threads on particular subjects to allow us to ask questions and get community feedback.  These posts should not be taken as a commitment to a particular feature (or lack of commitment to any other feature.)  I can't stress this enough.   I don't want anyone to think that we're ignoring other requests or to assume that because we're asking about something, they can expect to see this done in a future release.  We simply want to better understand the request so that we can reduce the number of assumptions on our part.
To start, let's we've got a few questions regarding the request for "Integrated (native) physics" which currently has 142 votes.
When talking about physics, are you interested in a 2D or 3D physics engine?
Can you list native engines that demonstrate the features you want the Flash runtime to implement natively?
For instance, if you're interested in Box2D functionality, have you tried http://www.box2dflash.org?
Is there a huge performance gap between the native and ActionScript implementations of Box2D?
Are you looking for solutions for desktop or mobile?
Thanks,
Chris

Answer 1

I'm all for the addition of a native physics system, based on Box2D, that gives us native speed.
But, I'd also like to suggest that you make sure that you are committed to polishing and improving the new API's, and not leave them stranded at v 1.0.
For example, GameInput API is rife with bugs, and there seems to be no interest or pro-activeness on the part of Adobe to fix them. Zeh Fernando has put in a ton of work in standardizing the GameInput API, and he has been quite vocal about the issues, and as far as I know, no one from Adobe seems to care at all.
Here's a link to his gitHub repo, where he lists current issues with the API:
zeh/key-action-binder · GitHub
know that Flash's GameInput API is still severely ridden with bugs. You may run into some of them. Here's some more information.
Supported devices are not detected properly when added or removed (Bug #3709110): no workaround
Using GameInput add Timer overhead every second in Windows (Bug #3660823): no workaround
GameInput devices simply stop working when running on Android/OUYA: need to initialize things in the first frame of SWF (fixed in AIR 13.0.0.36/Flash Player 13.0.0.130?)
Quick button presses may not be properly detected on Macs (Bug #3702039): no workaround (need to test sampling rate changes and if button activation can always be assumed from the up event)
In addition to those, I have run into a major bug on nVidia Shield, creating huge lag in inputs. The bug is nearly 12mths old, and is very severe:
Bug#3673122 - Shield controller massive lag
I'd love to see the AIR team being much more pro-active about bug fixing. It seems to be like pulling teeth sometimes to actually get something fixed. I would think that the team, after putting in a big effort to implement GameInput in the first place, would be extremely pro-active in seeking out feedback and fixing the bugs in the first 3-6mths since release, to harden the API, but instead no one seems to care, and the onus is all on us to "file a bug report and vote", which seems code for "might get fixed, one day, maybe"
We love AIR so much because of it's consistency, but new API's need to be as consistent as old ones, and need constant iteration and improvement as well. I know it's flashier to add a new bullet point to the marketing check list, but consistency and reliability are much more important in this chaotic and fragmented landscape.
/2 cents