Ideas and suggestions for new roadmap

[Frédéric C.]

Hi,

Now that Harman will manage new versions of AIR, and are asking for community feedback, I thought it would be nice to gather here all ideas, suggestions, bug reports or any brainstorming that could help Andrew and his team plan their next steps.

PLEASE, DON'T use this thread for opinions, ego wars or pure speculations about Adobe or pessimistic views about AIR. There are already two big threads dedicated to this, we don't need a third one. For once, let's try to be factual and constructive. Thank you.

I think we could split the points in three categories:

- Short term actions

- What new features would be appreciated

- Long term plans

1) Short term actions:

- Implement Android 64bits support

- Create a website dedicated to AIR, presenting its features and gathering as much resources as possible. Possibly create also dedicated forums, as Adobe forums may be a cursed place, now.

- Anticipate iOS SDK upgrade for requirements that may come with iOS 13

2) Cool new features:

- Adaptive icon support on Android

- Assets.car generator for iOS developers using Windows platform

- Add more texture RAM for mobile

- Improve Android audio support

- Make some AS3 methods compatible with object pooling like for example Matrix.transformPoint

3) Long term plans

- Market AIR and spread the word about this tech. Provide tutorials, examples, videos...

- Keep Android and iOS SDK up to date

- Maintain compatibility with current toolchains, including Adobe Animate

- Linux target ?

- Web target ?

Those are the points I had in mind, but I'm sure you all have specific needs and ideas. So please, share!

[dmunsie]

Targets: Consoles (Xbox, Sony, Nintendo, etc...)

[gmarkowski]

As @dmunsie suggested - consoles support would be a game changer for Adobe AIR.

We are forced to move away from AIR just because of it

[ASWC]

I'd like to know more on this, why using a cross platform tech to do console dev? What is the advantage of using a cross platform tech for that? How much do you use/share of your console project code base with other project types?

[Leo Kanel]

I share his opinion. My company worked as a consultant last year for a gaming studio. It was so easy to get the game from Android & iOS to Steam and then prepared for Nintendo Switch. It took literally a couple of weeks to move from Mobile to desktop and then to the first console. Now we are working to bring it to Facebook Gameroom. As the platform supported all this target, the work needed was minimal.

[rewb0rn]

Which engine / tech was that? We have released our games to iOS, Android, Microsoft Store, Steam, Facebook Gameroom and HTML5 with Haxe and Air with minimal code changes as well. Theoretically we should be able to release the Haxe code on the Switch as well, although admittedly I haven't looked into it at all and Air itself certainly does not support it.

[Leo Kanel]

rewb0rn  wrote

Which engine / tech was that? We have released our games to iOS, Android, Microsoft Store, Steam, Facebook Gameroom and HTML5 with Haxe and Air with minimal code changes as well. Theoretically we should be able to release the Haxe code on the Switch as well, although admittedly I haven't looked into it at all and Air itself certainly does not support it.

Last we did was with Unity3D but we have also done similar with Game maker studio 2. With AIR we stick to Android & iOS, 99% for Apps and not games.

ASWC wrote

Oh gee, I had a brain fart it seems, I thought all along this was about console command dev. No Console games of course! Forget I commented on this.

Lol no worries. We were discussing xbox, ps, nintendo

[ASWC]

Oh gee, I had a brain fart it seems, I thought all along this was about console command dev. No Console games of course! Forget I commented on this.

[Flipline]

Here are a couple more suggestions:

- Getting display cutout information on Android, so we can reposition our content if it's overlapping a notch/cutout.  With iPhone we know the one spot that the notch can be, but on Android there are devices with wide or narrow centered notches, the Galaxy S10's circular corner cutout, etc.

(https://developer.android.com/guide/topics/display-cutout#choose_how_your_app_handles_cutout_areas)

- Fixing Chromebook responsiveness issues with Android apps.  Many Chromebooks can purchase and install Android apps from the Play Store by default, but there has always been an issue with AIR Android apps not responding to user input when played on a Chromebook.  (More info here: Tracker ).  Not exactly a big priority since I don't know if that's a large market/userbase, but we've had to deal with negative reviews and refund requests on occasion from users buying our apps on a Chromebook.  Also not quite clear if it's a Google issue or an AIR issue.

[Frédéric C.]

Flipline  a écrit

Here are a couple more suggestions:

- Getting display cutout information on Android, so we can reposition our content if it's overlapping a notch/cutout.  With iPhone we know the one spot that the notch can be, but on Android there are devices with wide or narrow centered notches, the Galaxy S10's circular corner cutout, etc.

(https://developer.android.com/guide/topics/display-cutout#choose_how_your_app_handles_cuto ut_areas)

It makes me think that the same would be nice for iOS: I know we can do this by identifying the device name, but it would be better if we could get the iOS safe area for notch-equiped devices.

[William Spence]

I know that it is not a small ask, but I think at some point the webkit needs to be addressed.  With ANEs I am fine on mobile, but for desktop apps, the webkit is getting quite long in the tooth.  The webkit I believe is nearly 10 years old, which in software terms is an eternity.  I have run into a few problems where I have had unexpected problems, especially with some web animations and Google Maps, which is a very popular technology to have in an app.  Google stays on top of things and is constantly pushing their map technology, and our webkit is not keeping up.  I get nervous about the prospect of Google Maps not working at all anymore in my desktop apps, which would put a stake in my business.  In one of their announcements a long time ago, Adobe mentioned they were working on incorporating a new webkit, but it never came to pass.  I don't know what happened.

[hferreira80]

• Linux again, updated to the current version of AIR in Captive Mode (for me 32 bits and shared runtime is unnecessary);
• WebView component updated (Google Maps inside my App).
• SQLite upgrade;
• Toast on Desktop.

[JoãoCésar]

Hi.

Great thread.

My humble suggestions are:

- A forum that can be more than just Q&A. We need a central place for everybody to ask questions but also to showcase released works, WIP, post tutorials, tips, news, and so on;

- I also agree that AIR needs a powerful market boost;

- With all these discussions about AIR, I'm noticing that there are so many users with a great amount of knowledge that don't usually frequent the regular Animate forums. I think it would be nice if these very skilled AIR/AS3 users could drop by sometimes to help keeping the community alive and cause a very good impression on newcomers;

- I saw that some users mentioned this but I would like to emphasize that we need frameworks for games and apps that are based on the regular Display List for Animate users;

- Web output (WebAssembly) is a must;

- [DREAM] Haxe is a phenomenal language. I wish there could be some kind of partneship/integration/collaboration between the AIR/AS3 world and the Haxe world. I know Haxe outputs to AIR but I'm thinking on some initiative from "our" part if this makes some sense. Something that Animate users could benefit from.

[Frédéric C.]

Not sure how advanced it is, but I just found a project aiming at translating AS3 / Flash to JS / Html5: GitHub - AntonovSergey2211/guepard: flash to html5 converter, as3 to javascript translator

There are interesting demos. Might be worth a look...

[rewb0rn]

Based on what Andrew has posted so far I think it will be unlikely that we will see additional platforms any time soon (except maybe Linux, since he said they support Linux already for their business clients). They are probably a small team as well and he stated that they are in the process of setting up even iOS, so I don't think console platforms are likely at this point.

I think generally it is too early to expect a number of additional features added soon. They will probably need a while to get the process going and keep up with app store requirements. Also for things like assets.car we already have solutions, so I would prefer to have them work on other things rather.

I fully agree on the marketing thing, it would be great to finally have a single standalone website (maybe even with a 3rd party asset / ANE store?) that bundles everything, and I would definitely volunteer to help with tutorials.

We are also using Haxe for our games. We have ported 99% of all AS3 code to Haxe and use Haxe to deploy to HTML5 and swf, so we have full platform coverage. We are very happy with the outcome so I can recommend it to anyone who considers that an option. Would be great to get that involved a bit more with Air.

[chaky]

I would like following features as well:

1) Improvement in multi threading. Currently FPS is locked to 4 FPS on all mobile devices inside worker. Also there were some bugs with shared byte array where clearing byte array was not working in some cases.

2) Improvement in performance. Adobe was focused mainly on adding new features and keeping up with iOS/Android changes in compatibility. I would like to see performance improvements so that AIR can be used for games. Currently my biggest bottleneck in performance is not GPU but AS3 itself or the way it is translated to iOS/Android when compiled. Also there are bugs like using triple equals for number on iOS causes memory allocations.

3) Improvement in Context3D on Android so that context is not lost easily on Android like on iOS where is almost never lost.

4) Improving performance for Windows 64 captive. Currently Windows 64bit captive is slower than Windows 32bit captive. https://forum.starling-framework.org/d/20719-air-win-64-bit-captive-much-slower-than-air-win-32-bit-...

Regards,

Caslav

[chaky]

Also can someone give their experience with implemented game controllers with AIR?

I do not have experience with this but I heard from other devs that compatibility with game controllers is not so good.

[Leo Kanel]

I think we should do a trello roadmap/feature request. This kind of threads, tend to get a lot of features repeated over and over again, and it ends up being a wishing bucket.

[chaky]

So here is the code of the test that shows how much slower Windows 64bit captive is when compared to Windows 32bit captive:

package

{

    import flash.display.Sprite;

    import flash.display.StageAlign;

    import flash.display.StageScaleMode;

    import flash.events.Event;

    import flash.text.TextField;

    import flash.text.TextFormat;

    import flash.utils.getTimer;

    import flash.utils.setTimeout;

    [SWF(frameRate="60", width="1280", height="720", backgroundColor="0x000000")]

    public class Windows64BitPerformanceTest extends Sprite

    {

        private static var i:int = 0;

        private static var c:int = 0;

        private static var m:int = 0;

        private static var f:int = 0;

        private static const ITERATION_COUNT:uint = 500000000;

        private var _logTextField:TextField;

        private var _logTextFormat:TextFormat;

        public function Windows64BitPerformanceTest()

        {

            stage.align = StageAlign.TOP_LEFT;

            stage.scaleMode = StageScaleMode.NO_SCALE;

            this.loaderInfo.addEventListener(Event.COMPLETE, this.loaderInfoLoadCompleteEventHandler);

        }

        protected function loaderInfoLoadCompleteEventHandler(event:Event):void

        {

            _logTextFormat = new TextFormat('Verdana', 40, 0xFFFFFF, true, false, false, null, null, 'center');

            _logTextField = new TextField();

            _logTextField.setTextFormat(_logTextFormat);

            _logTextField.defaultTextFormat = _logTextFormat;

            _logTextField.width = stage.stageWidth;

            _logTextField.y = stage.stageHeight / 2;

            addChild(_logTextField);

            setTimeout(runTest, 1000);

        }

        private function runTest():void

        {

            var time:int = getTimer();

            for(i = 0; i <= ITERATION_COUNT; i++)

            {

                f += incrementC();

                f += incrementM();

            }

            _logTextField.appendText('Completed in ' + (getTimer() - time).toString() + ' milliseconds.');

        }

        private function incrementC():int

        {

            if(isModule2(c) == 1)

            {

                c += 1;

            }

            else

            {

                c += 2;

            }

            return c;

        }

        private function incrementM():int

        {

            if(isModule2(m) == 1)

            {

                m += 1;

            }

            else

            {

                m += 2;

            }

            return m;

        }

        private function isModule2(v:int):int

        {

            if(v % 2 == 0)

            {

                return 1;

            }

            else

            {

                return 0;

            }

        }

    }

}

On my machine this test completes in around 15 seconds for 32bit but for 64bit it took 43 seconds so this difference is very huge. This test was run on Windows 10 with Intel i7 CPU. This was tested with latest AIR 32 SDK.

Also here are the download link for executable files of this test for both 32bit and 64bit so guys please test it if you have AMD CPU to see if there is difference:

http://bit.do/eUCzx

[zwetan_uk]

I would advise if people report things to spend the time investigating it and have a sample to demonstrate the problem

instead of just adding the so called problem to a pile of thing that only gonna get bigger with time.

Whatever the size of the HARMAN dev team, if you made them investigate "bugs" that are not really there,

you basically make them lose a lot of time they could have spent doing other things.

so my opinion is whoever report a bug, should have a sample, details on how to compile it,

pass it around to few other dev (not just 2, at least 3 or 5), so it can be confirmed,

and then you report the bug to HARMAN.

the "I heard someone had a bug so I report it", sorry I don't think this help at all.

[Frédéric C.]

zwetan_uk​ Yes, I agree, reporting minor or new bugs is not what I was suggesting. I was more thinking of well known, long-standing bugs that were never fixed by Adobe,and that some people have been waiting for a long time (I'm sure there are a few).

@Leo Kanel: Yes, that's actually what I proposed in the other thread, but I think it would be better if this Trello was created and managed by Harman. This thread is a first attempt at gathering most popular requests from the community, to then fill the Trello with (or whatever solution is used).

[ASWC]

Not sure this is the correct format to post ideas but for me AIR would be more attractive (not especially better) to new developers if it had:

- a fixed SoundAPI (since FP9 the AS3 SoundAPI has been the worse on the market, even HTML5 beats it in every way)

- a web target. (if this was NOT relevant I think flutter and Unity would NOT have it)

[zwetan_uk]

Another thing, in term of new features to add
try to think in "points"

it is very easy to just throw a "oh just add a web target", "oh just target PS4 and XBOX", etc.
it is one line to write, but the development of such feature is extremely big and time consuming

I would say a fixed sound API would be along the 5 to 10 points
and a web target would be around the 500 points mark (if not more)

and "console support", let's say for just one console around the 2000 points (if not more)

whatever ratio/weight you decide to apply to those points
if 5 points is 2 month of development effort, then 500 points is 200 months

also those points should ultimately be decided by HARMAN
they know how hard/easy such and such feature would be to develop

so even if you (asking for a new feature) estimate something at 2 points
but then HARMAN (investigating it) estimate it to 10 points, then 10 points it is

I would say the one who actually develop the features win in the estimate

we can not just ask anything and everything, eg. asking a lot of features requiring a lot of points

just gonna give the impression that "nothing is done" when in fact people are just asking for "too much too soon"

remember also that Adobe in their release schedule moved from 1year+ release to quarterly release
that also influence how much or how big can be shipped per release

[ASWC]

A few years back an Adobe engineer told me that yeah the SoundAPI is crap but fixing it would be a huge undertaking and Adobe would never go for it. Based on that I'm not sure the 5 to 10 points work here but maybe he was wrong and if he was how come this has not been fixed since FP9 if it was so easy?

[The_DA]

- Increased or uncapped (with desktop) texture memory limit.

- 8k x 8k image support.

- Updated media support: VP8/VP9/Vorbis/Opus
- VP8/VP9 with alpha.  FLV supports alpha.  Dropping FLV export from Adobe products back around 2012 has left us without a means to export video with alpha channel, something that has never been replaced!
- 4K camera support (desktop, but maybe mobile too?).
- Linux support again.

- Native serial communication (micro-controllers).

- Funding for projects like Starling, Feathers, perhaps even a re-awakening of Away3D if you're really serious about this.