The latest beta is now released, and we invite those interested in beta testing the new features in the editor and engine to join now.
The beta period will be 2 weeks and the next planned stable release is two weeks from now.
We hope this new workflow will highlight any issues earlier, and also get valuable feedback from our users. And please comment if you come up with ideas on improving on this new workflow.
Please report any engine issues in this thread or in issues using Help → Report Issue
Thx for helping out!
This is a BETA release, and it might have issues that could potentially be disruptive for you and your teams workflow. Use with caution. Use of source control for your projects is strongly recommended.
Download the editor or bob.jar from Defold Downloads
Set your build server to https://build-stage.defold.com
The biggest change this sprint is that we’ve now moved the Spine from the engine itself, into
Apart from adding the dependency to the extension, there should be no other changes needed by the developer.
This is a big change, and we’ve worked many months to put all the pieces together.
If you encounter an issue with this release and your project, please let us know!
Use new path to the Spine material folder
/defold-spine/assets/ instead of
builtins/materials for all the spine models in your project.
Rive.app support - Beta Release!
This sprint we’re also officially releasing the first beta version of the extension-rive.
The actual rive implementation is also still under development, and there are still things to solve, but we feel it’s time for our users to be able to play around some more with it.
It supports playing regular animations, as well as statemachines and controlling the state machine inputs.
- The scenes generate a lot of draw calls. The Rive team is working on implementing mesh+texture support, which will remedy this.
- Some clipping and blending issues. Some scenes experience these issues, and we’re looking into this.
Since the available open source tools sometimes doesn’t work out of the box with the Apple software,
we have decided to use dedicated
macOS build servers for macOS/iOS builds for the time being.
As a Defold user, you don’t have to configure anything, our regular servers will redirect to the builds automatically, and your builds should work as usual.
We’ve added the setting Temporarily disabled in waiting of a unit test fix.
physics.velocity_threshold in order to allow the developer to control when slow moving objects should stop.
sys.deserialize(buffer) (used internally in our
sys.save()) functions for the cases where the developer uses custom functions to store or retrieve data.
We’ve added a fix for our builds using bob.jar that optimizes memory usage (at runtime) for each component type by calculating the number of instances needed for each type (if not using factories).
This allows us to also optimzise the running performance for component types if the collection doesn’t contain the type at all.
Also, we’ve made some smaller typos and fixes in the documentation
We are now working on implemention a Spine extension that supports the official (latest) Spine runtime.
* Currently awaiting a unit test fix
Issue-3775 - Fixed: Fix for slow moving physics objects getting stuck
Issue-5843- Fixed: Disable component types that are not used in a collection
Issue-6031- Fixed: Increase debugger connect timeout from 2 to 10 seconds
Issue-6036- Fixed: NE: Added dmRender::EnableRenderObjectConstant + Disable to dmSDK
Issue-6049- Fixed: Expose Lua table serialization functions sys.serialize()/sys.deserialize()
Issue-6058- Fixed: Do not close the ssl socket twice
Issue-6060- Fixed: Allow window size change at initialization phase
Issue-6067- Fixed: Bob: Don’t create tasks for files in excluded folders
Issue-6052- Fixed: Bob: Asset cache: Added optional user and password to remote cache access
Issue-6074- Fixed: Removed Spine support from engine
Issue-6081- Fixed: NE: Added JNI thread attach/detach struct and LoadClass to dmSDK in