To all of you who missed it, Joshua shared about the past year of OpenFL, and upcoming changes in his “off site” WWX 2014 talk, OpenFL 2.0: What Was, What Is and What Is to Come. In the past year, there were many architectural improvements that were made to position OpenFL for a bright future. Lime was introduced, and new targets were added. With this work complete, OpenFL 2.0 brings a clear focus on the stability and consistency of the platform.
Unit-Tests
We want to make sure that when you use OpenFL, you come away with a great experience, regardless of the target platform. We have expanded our unit test suite, and are continuing to make improvements to help ensure that OpenFL is a consistent platform across each target backend.
Build Server
We scrapped our previous build service, and have switched to using TeamCity. It is already possible for us to make and push new builds very quickly, and we plan to begin nightly builds once a few more things are sorted out. We have also begun considering options to allow for “dev” or “beta” repositories channels, to allow more developers to easily use “unstable” builds of OpenFL, and to allow us to push releases when they have received even more testing.
Moving to openfl.*
As part of our commitment to a consistent, tested API for all platforms, we have chosen to move from the default flash.* class package to openfl.*. If you have projects written for “flash.display.Sprite”, this will still resolve properly to the OpenFL version.
We have found that more and more users have been coming to OpenFL without previous Flash experience. For these users, the flash.* class package has been confusing at times. No matter how closely we follow the Flash API, OpenFL and Flash will always be different things, so it makes sense for us to use the openfl.* namespace.
By committing to our own API, we can focus on providing clear code completion, careful additions to the API, and Flash Player substitutes for any features we provide. For example, “openfl.display.OpenGLView” provides WebGL support for native and HTML5 targets. In Flash, OpenGLView is now provided, though with “isSupported” returning false. We may also be able to make minor modifications to core types, such as a “drawTiles” method for “openfl.display.Graphics”
A Combined OpenFL Library
With these above changes in mind, we have chosen to move to a unified OpenFL library. The unit testing, the Flash, native and HTML5 backends will all be a part of the same library, as we continue to focus on the consistency between them.
If you want to override a backend, this will be possible, just like before. If you would like to disable a custom backend, and force the use of the default target backend instead, you use the “no-custom-backend” define.
If you have need to upgrade or downgrade OpenFL, you will have one library, not three, to manage.
Live Asset Reloading
OpenFL 2.0 has initial support for live asset reloading when building projects on the desktop. While your application is running, “lime update” will not crash the application, but will refresh the assets and notify your application of the change.
OpenFL applications will automatically remove the openfl.Assets cache, so subsequent “getBitmapData” (and other) asset calls will grab the latest copy. Additionally, the openfl.Assets class dispatches an Event.CHANGE event, in case you want to perform a more advanced response to a new asset system. In the future, we plan to be able to trigger “update” calls automatically, so long as we can have efficient file watching in place.
The Road Ahead
We appreciate your support on Patreon, and your contributions on GitHub. If you would like to be a part of the OpenFL Slack chat, leave a comment or tweet us at @Open_FL for an invite.
Many of you have already told us that OpenFL is an ideal development environment, please help us make it even better. Thank you!
Changes
openfl
Version: 2.0.0
- Implemented support for live asset reloading (desktop)
- Many consistency improvements between target backends
- Combined “openfl-native” and “openfl-html5” into one “openfl” library
- Move from “flash” to “openfl” for all classes
- Fixed ByteArray embedding in HTML5
- Fixed issues in the Android JNI class
- Improved the behavior of FocusEvent
- Improved the behavior of Event.CHANGE on native
- Exposed “openfl.embed” to allow control of HTML5 embeds from JavaScript
- Fixed coordinates reported from HTML5 touch events
- Added support for OpenGLView when targeting HTML5 -Ddom
- Added a new fast Vector implementation
- Fixed an issue with Stage focus when leaving the Flash preloader
- Added Assets.list
- Added support for HTML5 “dependencies” to link additional scripts
lime
Version: 1.0.0
- Fixed support for OpenGL on Nvidia drivers for Linux
- Fixed a bug where OpenGL textures were freed improperly
- Fixed a GPU texture issue on iOS
- Fixed an issue with Android JNI
- Added support for custom user agents in URL requests
- Improved support for reading audio file length
- Improved support for iOS virtual text input
lime-tools
Version: 1.5.4
- Addressed an issue when using “lime upgrade” on Windows
- Improved the behavior of webfont generation
- Made fixes and improvements to the Lime extension template
- Fixed issues related to Firefox OS support
- Improved the asset manifest output to be more generic
- Added “force load” to third-party iOS libraries
- Fixed output directory for iOS debug binaries
- Added support for HTML5 dependency script files
- Updated the HTML5 server to node http-server instead of nekotools
- Added version values for haxelib defines (like -Dopenfl=2.0.0)
- Added the “final” build configuration, for final release builds
- Added ability to override haxelib paths (like –haxelib-openfl=my/path)
- Added a -nocolor flag to disable the ANSI text formatting
- Modified build behavior to copy NDLL files during “build”, not “update”
- Resolved an issue where too many build threads could freeze Windows systems
- Added live reload support
swf
Version: 1.5.2
- Updated for OpenFL 2.0 support
- Fixed support for Firefox OS
- Removed dependency on “format” library
