- OpenFl will generate swf files only if you target Flash. Otherwise it will be js for html5 target, etc. But you can still use Animate as a layout editor, compile it in swf, and use it in your OpenFl project thanks to the swf lib that will generate images from your swf (so the swf is kind of decompiled when you compile your OpenFl project).
- That depends on your project. In my own experience, I had to move TweenLite code to Actuate and BulkLoader to OpenFl own API, and I had to make some tweaks on filters.
- Yes, you can still use Adobe Animate for layout. Or you can use a UI lib like Feather or HaxeUI like you suggested. But you may have to make some tweaks on Filters because it doesn’t render the same.
It’s been two weeks since the previous update and although progress has been slower than expected, things are still moving forward!
Many of the improvements in develop-v9 have now been moved into feature branches. These are not all stable as most of the features intertwined and depended on each other.
The goal is to let the Haxe develop branch remain stable and target all currently supported platforms. The features we wanted in develop-v9 will be integrated one-by-one as they are ready.
One thing I wanted in develop-v9 was a change to the internal architecture of the library to make a standalone HTML5/Flash release. Instead of forcing this on the develop branch I am in the process of porting that code to Typescript instead.
I feel that Typescript is a good choice for the goals I have for this standalone version of OpenFL which include the ability to use it from Haxe. When complete I expect Haxe developers to be able to use -lib openfl and reference OpenFL (for Flash or HTML5 only) without any requirement for Lime tools.
I also think that this will provide a better development path for our NPM users who may want to contribute and make OpenFL a true open-source Flash replacement.
My first pass for the port is complete but it will still be a week or so before I expect to see our unit tests passing.
As I continue to see continued focus from our community of developers on HTML5 as the primary and only target of interest, I also want to begin planning to add features that are easy to implement on HTML5 but lacking on native platforms like webcam integration. ES6 weak maps also should allow the weak references we need for proper addEventListener implementation
Thank you everyone for your support and feel free to ask questions on our Discord server
8 Likes
Are you sure that DCE will still work when using -lib openfl in TypeScript ?
I’m asking because DCE didn’t trigger for my project when I was using my own Flash library : the full .swc file was included in the binary… Porting my library to haXe solved the problem, though 
So, since it’s important to keep HTML5 builds as small as possible, I think we should keep an eye on it.
At least, one solution (but not optimal) would be to let us disable/enable each “feature” with a specifc haXe define, e.g.-Dopenfl_video
I’m currently using ES6 modules which should be able to map to Haxe extern classes individually, so mostly it will be a matter of how independent (or interconnected) the classes really are.
Ultimately I think things will get smaller when it’s stable because we won’t need the Lime abstraction layer in the middle
Lime is awesome for mirroring functionality across HTML5, alternative runtimes (such as Neko and HashLink) as well as native C++, but should not be necessary for HTML5 only
3 Likes
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!
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:
- Limit changes
- 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:
- Lime will follow the “limit changes” approach for now to keep stability
- 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:
- OpenFL will focus on HTML5 as the primary platform
- Unit testing will be written around functionality before making changes
- Unit testing will be written and tested on the HTML5 target only
- We will try to keep other targets in mind and not break them purposely
- 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
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
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
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.
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
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
Improved HTML5 performance is definitely a plus
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.
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?
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
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.
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
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
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
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
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
We are going to keep all current platforms supported with the help of the developer community
4 Likes