Here is the current progress:
- Shader improvements are mostly stable to allow for GLSL array types
- Batch rendering has passed milestones for the “proof of concept” and is pending architecture changes to support it
- We’ve made big strides to develop the standalone OpenFL experience that supports HTML5 or Flash without Lime or Lime tools
There are two blocking issues which have slowed development but I am confident that the path forward will be positive.
There are a lot of exciting and positive changes coming in the pipeline for OpenFL, but many of these features require architectural changes that compromised the reliability of our development branch.
In response we reverted the primary development branch and hand-picked features to support in the 8.9.6 release. Now we have two major development branches – one with all changes (but not stable enough for all users) and one that’s stable but lacks the architecture changes needed to support the newer features.
In the interest of stability, we are currently favoring a solution where we stay with the stable development branch, then integrate features more slowly after they are fully mature.
The second problem is more embarrassing to discuss, but is another real limitation in development: mental overload.
All the features we’re most excited about require fundamental changes to the core architecture of the library. Personally, I load all of OpenFL (each language, each platform) into my head at once, imagine architecture changes and make changes with all the pieces in perspective, but I am reaching my limits lately.
They say that to “eat an elephant” you eat it “one bite at a time,” and that is how I would like to approach this problem. Allowing OpenFL to be used without Lime and without the Lime tools removes a lot of “cognitive load” by reducing the variables. Similarly, changes to SWF asset processing using the
The next wave of improvements we desire for OpenFL 9 shake the foundations of OpenFL’s architecture and stress the limits of my ability to handle complexity (in order to simplify it, of course).
As a result, this has led to a shift in attention. In order to finish the fun features planned, next we need to cut OpenFL into “bite size” pieces. “But can we please keep things stable?” Those are two different priorities – one to have stability and improved performance (so long as it does not introduce instability) and the other to have a laboratory where there is the mental room and agency to cook up the features and performance we need.
The result is that we are currently planning to let the stable development branch remain and will abandon most of the architecture changes in the v9 development branch. For the time being the stable branch will not allow use without Lime and the Lime tools. It’s stable and married to Lime forever.
The v9 development branch is going to develop into the standalone OpenFL and drop support for Lime, Lime tools or all platforms except HTML5.
This will let us make a stronger HTML5 target, simplify our code and create the workspace I need to cook up each new feature without being overloaded. Then new features can integrate back into “the everything” source code when they are good and mature