The case for integrated, native physics in the Flash Runtime

Not a huge priority for me. Only a small subset of games/apps. need a full-blown physics engine.  I would prefer to see more effort put into polishing existing APIs, fixing bugs, and improving mobile device integration (iOS mute button, native dialogs, SMS, etc.).

Hi Chris,

Here are my thoughts:

1. I'd like to see 2D physics integrated into the Flash & AIR runtimes if it would provide significantly faster performance than using a 3rd party library.

2. My preference would be an implementation of Box2D. I know Nape is an awesome physics engine but I'd rather Flash natively supported Box2D because of its popularity across other languages.

3. I'd only really be interested in physics being integrated into the runtime if it were to be properly maintained. For example, if there are updates to Box2D then I'd expect to see the updates to the ActionScript API also.

4. I would probably prefer to see physics integrated within the runtime rather than a separate ANE.

5. I use AIR primarily these days and target mobile. However, it's important that the physics engine is available across both Flash Player and AIR.

6. Some features that I'd really want to see over and above the absolute basic 2D physics engine stuff:

i. Ghost Vertices via b2ChainShape. (http://www.iforce2d.net/b2dtut/ghost-vertices)

  ii. Collision Filtering via categories and bit masks. (http://www.iforce2d.net/b2dtut/collision-filtering)

  iii. One-way walls.

  iv. Sensors (http://www.iforce2d.net/b2dtut/sensors)

  v. Joints - including revolute, distance, line, weld, pulley, friction, gear etc

Thanks.

With some of the AAA-Gameengines going Free-to_use (Cryengine, Unreal 4) or migrating to a renting model. I get the feeling Adobe is a little LTTP.

The moment Unity adopts a similar pricing model, Flash will not only be the most expensive but also the most "underpowered" Gameengine to integrate physics.

No thanks, bring back some really useful stuff (like AS2 support ) in CC++ (or whatever it mayb called) and leave the "serious" gaming stuff to adults.

Would love to see a native physics engine that runs smooth on mobile, but also like the idea that others suggested of supporting a third party existing engine.

I think the initiative is good!, we ended doing our own tiny physics lib for Flare3D because we couldn't find any solution that was suitable for our needs (Flare3D Collision detection and Physics simulation library. - YouTube) , it is super fast for some tasks, but it lacks of some mayor features already available in commercial or free libraries like Nvidia PhysX or Bullet.

The only 3d physics lib available right now is the Away3D port of Bullet, which is good, but slow, and not suitable for mobile at all.

There were other libs like JigLib (discontinued?), or Oimo which is very fast but too simple.

There are options for 2D like Box2D or Nape, but not much for 3D.

I don't think building an ANE is a good idea, Flash/AIR is not only desktop or mobile, is a cross platform solution and should remain that way.

Some more thoughts....

Building the collision detection tools only with native speed, could be good in the way we would have freedom to implement those as a building blocks, but physics is not only about collision detection...in fact...that's the easy part problems comes when integrating solvers, caching contact points, balancing the beast, tuning and hacking it to make it work....so having a single algorithm to detect collisions, its also limiting in sort of lots of different ways.

So, my conclusion is, having a well integrated 3D lib, native speed, full feature set, integrated with the runtime and ready to use, could be the way to go.

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

Not why advanced physics with NVIDIA PhysX support like on Adobe Director 12?

For Desktop and Mobile: Adobe Director

I don't think it's really the responsibility of the Flash Player and/or AIR runtime to implement physics (at a built-in level, at least).

An ANE extension project (particularly like the one demonstrated in the Bullet vs. Away Physics video in the comments) would certainly be awesome, provided it's cross-platform on both mobile and desktop.

Like others have mentioned, overall improvements on number-crunching performance in the FP and AIR runtime would be more desirable than simply focusing on just the area of physics, since it could benefit multiple aspects like faster for-loop iterations, collision detection, sound generation / effect-processor, file reading/writing/parsing, AND physics, etc.

It would be interesting to see other posts/questions from Adobe like this towards some of the other popular voted features that the community requested in the uplist page.

Personally I would like to see how much interest there is for a better Audio API (for handling DSPs, sound effect processing, MIDI I/O handling), again this could be a crossplatform ANE. But I won't wander off on a different topic too much here, just thought I'd mention it!

Thanks for listening to your community, Adobe!

Not a priority. Improving overall runtime performance should be a priority as it would benefit all AS3 libs, physics ones included.

I'm with pshtif and makc3d, there are already some libraries and ANEs out there, are you sure developing your own ANE or integrating physics in the core runtime is going to be beneficial and you have the resources to not leave it in oblivion or severly outdated? maybe in the long run it's cheaper to improve math performance/add new numeric data types/add generics/add native triangulation and geom functions. In the old days some of these were rejected because it broke compatibility with ECMA standards, does it really matter anymore? why not your own "ECMA standard" (does it matter if it's not even a standard? I guess getting a standard qualification costs money)? AFAIK, Micosoft did so with C#.

Just thinking aloud, I'd love to get more into gaming, but I make (a lot of) other types of apps, so physics is not that important to me, and the things I've proposed would also benefit other things, like encryption, which would also benefit games, although in other areas.