Development Update: OpenFL 9

Announcements
#21

It would be great to have Matrix3D in DisplayObject for a real Flash replacement. DisplayObject operations like RotationX, RotationY, RotationZ, and z are really needed. Thanks for the your excellent job and for the experts in the community that know how to implement this wonder!

#22

Thank you EVERYONE who responded to the current OpenFL Developer Survey. If you have not already, please respond and help your voice be heard!

Your voices are being heard clearly that “Improved stability” and “Faster performance” are the top priorities for your needs.

There are two ways that I know to preserve stability:

  1. Limit changes
  2. Establish thorough testing

The previous work on OpenFL (before the 8.9.6 rollback release) began to increase our performance at the price of stability and edge-case performance regressions that became too difficult to track down.

The contributors in the OpenFL Discord and I have discussed strategies for increasing the ease of contribution and how to better isolate code testing and (in a worst-case scenario) rolling back portions of code instead of the whole. We are targeting a change internally to move OpenFL into multiple private packages or modules. This changes nothing about how OpenFL is used but lets us break OpenFL into smaller logical pieces such as “the OpenGL renderer” or “text” or “the event dispatcher”.

We also have these units of code isolated in order to be able to run tests independently. Herein lies another catch. Historically OpenFL has supported so many target platforms that it is difficult to test. Eventually it landed on manual testing to determine if OpenFL was operating properly before a release. As we seek to increase the number of direct contributors to the OpenFL codebase I want to more heavily on automatic testing.

Here are my current expectations for OpenFL and Lime:

  1. Lime will follow the “limit changes” approach for now to keep stability
  2. OpenFL will follow the “establish thorough testing” approach to preserve stability as we seek to improve the library

I also expect a shift in focus on OpenFL:

  1. OpenFL will focus on HTML5 as the primary platform
  2. Unit testing will be written around functionality before making changes
  3. Unit testing will be written and tested on the HTML5 target only
  4. We will try to keep other targets in mind and not break them purposely
  5. Native platforms will be a collaboration with the broader OpenFL community but will not be officially “rubber stamped” and guaranteed

#5 may come as a bit of a shock but this is actually an honest admission of where things currently stand. OpenFL lacks broad automated testing and the chaos of every supported platform is a mental drain that is slowing down the development of the project. I’m of the mind that developing a fast, stable, robust HTML5 target (then patching as needed) is going to produce much better results than stagnating with every platform officially supported.

These decisions aren’t final, and I’m happy to discuss them more on Discord.

6 Likes
#23

I think that makes sense because Flash is less used now. Most of my projects are made for HTML5 because there is currently a high demand on porting flash project to HTML5 right now. But I hope to become full gamedev soon, and I’ll probably stop using HTML5 and use native targets instead.

Beware that lack of native support can lead some people elsewhere. There is a big need of documentation on how native targets work. I would like to help more but I’m often lost in the code :slight_smile:

Hashlink can become a solid target imho (fast build et good performance).

And what about consoles? Is the console target still working? Who is in charge? I currently don’t use this target but once my game will be finished, I hope it will be still possible.

1 Like
#24

Mister @larsiusprime knows about console backends for OpenFL. It’s a little hard to track down info because a lot of it is under NDA.

#25

Wii U is stable and used in production, it uses a minor fork of Lime that is a version or two old and the OpenFL version that pairs with it. It would not be a huge effort to move it up to newer versions

#26

We are continuing to have conversations in Discord around the clear direction for OpenFL. I found myself describing it this way today that I believe may be helpful:

I don’t have the bandwidth to give both Lime and OpenFL the attention they deserve

So I’m choosing OpenFL

By nature this means less focus on native (for my part) since OpenFL minus Lime has no native backend

Please visit Discord if you have any concerns. We still are writing code in Haxe, we still allow targeting all current platforms and the native code is still stable.

Here’s another list shared in our discussions:

Here are some examples of features we can work on focused on HTML5:

  • Weak references in EventDispatcher and Dictionary
  • Improved cleanup code for “unembedding” OpenFL
  • Simpler embedding code
  • OpenFL without Lime tool bootstrapping (flexibility)
  • Emphasis on OpenGL
  • Better video support
  • Generative sound support
  • Webcam support
  • Microphone support
  • ApplicationDomain support?
  • Loading OpenFL apps within OpenFL apps support (using Loader)?
  • Eventually even AVM support
3 Likes
#27

Improved HTML5 performance is definitely a plus :slight_smile:

I was wondering if there are any plans for OpenFL to support the new JVM target with Haxe 4.1+? I figure it might serve as a nice alternative to AIR or C++ for those of us with plans to target desktop.

#28

That’s a Lime matter and not OpenFl now:) I think it’s better to improve Hashlink target (more or less same performance as JVM but faster compilation) and the target already exists.

Who’s gonna merge the PR in github for Lime now?

#29

I will still be around to merge pull requests

I do hope that there will be a broader number of contributors who can commit directly to the project

1 Like
#30

What are the ideas for all of the Lime dependency/ifdefs in the codebase? Even if the focus is HTML5, the HTML5-specific parts would have to be conditionally left out for other targets.

#31

I am having more conversations on Discord to consider the consensus of the group on the features and priorities that matter most to us personally.

I am hearing a lot of developers saying that OpenFL is not a Flash Player alternative but actually is closer to an Adobe AIR alternative and moving forward that is their priority.

@MSGhero The plan today is to move forward with the internal package structure which will allow each package to handle priorities and conditional code a bit differently.

6 Likes
#32

I would just like to mention that when I voted for improved stability, I was mainly thinking of stability across platforms, or more specifically, Android and iOS.

Those are the most important platforms for me, and what I would like most is to just have some confidence that I can continue to update my apps throughout the years without any major issues.

I understand that these platforms are more difficult to maintain since the APIs and whatnot keep changing, and mobile may not be the main focus of most OpenFL devs, but it is what I personally value most.

Either way, I think the work being done for OpenFL is amazing; it’s definitely a huge undertaking to support so many platforms, and I’m sure the most sensible approach will be taken.

3 Likes
#33

I think that we should let OpenFL 9 be more minimal and stabilize workflow changes then advance from there on OpenFL 10 with features previously discussed

I’d appreciate feedback and discussion around anything I’m missing or that you would like to see before a new stable release

Again – the goal is more to get a new stable foundation for future releases

Though I’m open to feature additions/changes if they’re well defined and tested

#34

I hear your concerns for the long-term support of the Android and iOS platforms – particularly maintaining (and improving) stability.

We have many talented developers in the OpenFL community and many who responded in the poll expressed a desire to increase code contributions.

My goal is to “get out of the way” and help cultivate a faster development cycle, write contribution guides and sort out a better work environment where we can all collaborate and perfect OpenFL as a community.

I think that many in the community feel as you do and love these platforms. I believe that by leaning more into our workflow as a whole and supporting a broader set of direct contributors we’ll receive a better result.

10 Likes
#35

I second Vasco’s comment about the importance of Android and iOS platforms. Mobile is super important and future proof solutions need to continue supporting the native mobile platforms.

Thanks!
Bruno

#36

We are going to keep all current platforms supported with the help of the developer community

4 Likes
#37

Hi, Whether Openfl9 optimizes drawcall, using the same picture seems to still have high frequency drawcall. :thinking:

//3000 drawcall, Shouldn't it be 1 drawcall?
for (i in 0...3000) {
			var bitmap = new Bitmap(Assets.getBitmapData("assets/pen.png"));
			this.addChild(bitmap);
			bitmap.x = Math.random() * getStageWidth();
			bitmap.y = Math.random() * getStageHeight();
		}
#38 
var bitmapData = Assets.getBitmapData("assets/pen.png");
for (i in 0...3000) {
  var bitmap = new Bitmap(bitmapData);
  this.addChild(bitmap);
  bitmap.x = Math.random() * getStageWidth();
  bitmap.y = Math.random() * getStageHeight();
}
#39

The result should be the same.

#40

Have you ever tried another Math class? The built-in “Math.random()” is not stable at all and it did not work well on 64bit Android devices and seem to be slowed on Windows!