Defold 1.12.0 BETA

Pawel · January 1, 2026, 9:18pm

The manual has been updated - especially according to @Hunter_Loftis feedback - thank you once again for it!

Regarding transform updates - by “component-type update” we mean update of each component type, so e.g. script components, model components, sprite components, etc. Each of those components in Defold have “transform” properties (position, rotation, scale) and these properties are updated before each “component-type” update, so e.g., when all components of type “sprite” are updated - their transforms are updated too. In my opinion it’s a little bit too detailed and too deep for most of the users - I think the only message for users from it should be that the engine just takes care to always have up-to-date transforms for users.

Hunter_Loftis · January 2, 2026, 2:49am

I opened a PR to illustrate the relatively minor change (at least, on top of an already breaking change!) required to support stable physics simulations in Defold:

github.com/defold/defold

sketch update flow pairing fixed_update with physics simulation

dev ← hunterloftis:stable-physics

opened 02:45AM - 02 Jan 26 UTC

hunterloftis

+7 -9

This is a sketch PR to provide a concrete implementation of an update loop with …stable, deterministic physics regardless of update frequency, for discussion. The current and planned implementation is update-frequency-dependent, such that "fixed_update" is a misnomer. Without pairing a `fixed_update` with a physics engine tick, it's not possible to create stable simulations in Defold, because the simulation state becomes dependent on the dynamic update speed. For example: --- Let’s say our `fixed_update` applies gravity to a kinematic sphere that is sliding down a 45-degree hill. Here’s a frame where N=2 (N being the number of fixed updates per frame): 1. `fixed_update` sees sphere at position 00, moves down to 01 2. `fixed_update sees sphere at position 01, moves down to 03 (gravity compounds velocity) 3. physics engine Fixed Update 4. `on_message` “contact_point_response” moves the sphere right from 03 to 33, projects velocity along the tangent 5. physics engine Fixed Update 6. collision already resolved, no movement, stays at 33 7. (new iteration of the update loop) 8. `fixed_update` sees the sphere at position 33 Now the exact same code across frames where N=1: 1. `fixed_update` sees sphere at position 00, moves to 01 2. physics engine Fixed Update 3. `on_message` “contact_point_response” moves the sphere from 01 to 11, projects velocity along the tangent 4. (new iteration of the update loop) 5. `fixed_update` sees sphere at position 11, moves to 12 6. physics engine Fixed Update 7. `on_message` “contact_point_response” moves the sphere from 12 to 22 8. (new iteration of the update loop) 9. `fixed_update` sees sphere at 22 Despite running the same code from the same starting situation, our first three `fixed_update` callbacks see different states: - N=2: 00, 01, 33 - N=1: 00, 11, 22 --- I apologize for pushing on this issue so much here, and on the forums. If it were work-around-able in user space, I wouldn't worry about it so much. But I believe that the 1.12 approach to a "fixed" update loop in Defold makes it impossible to build framerate-independent physics objects in the engine. I could be wrong about that, or I could be misunderstanding something else. I wanted to share this concrete example in order to communicate the issue more clearly. If it would be helpful, I could also put together an example physics-based Defold project that would run reliably and deterministically with this PR's update flow, but that would be unstable and non-deterministic when running in the 1.12 beta.

aglitchman · January 2, 2026, 12:16pm

You are absolutely right!
Thanks to the team for not releasing the beta before the New Year and giving us the opportunity to test everything.

I created a test project where an object is supposed to stay exactly in the center of the screen. In version 1.11.2 it works as expected, but in 1.12.0 the object flies upward because the fixed update scripts now run in their own cycle, making it impossible to continuously apply forces to physics objects.

test_gravity.zip (630.2 KB)

Mathias_Westerdahl · January 2, 2026, 12:38pm

Thanks! Yes, we’re discussing the resolution internally.

Mathias_Westerdahl · January 7, 2026, 1:27pm

Thanks for the input (you and everyone else)

Our current update is under review (with your last draft PR baked in there):

github.com/defold/defold

Make sure the script fixed update and physics fixed update are run in lock-step

dev ← fixed-update-cleanup

opened 01:15PM - 07 Jan 26 UTC

JCash

+45 -79

### Technical changes Removed PreFixedUpdate/PreUpdate again ## PR checkli…st * [ ] Code * [ ] Add engine and/or editor unit tests. * [ ] New and changed code follows the overall code style of existing code * [ ] Add comments where needed * [ ] Documentation * [ ] Make sure that API documentation is updated in code comments * [ ] Make sure that manuals are updated (in github.com/defold/doc) * [ ] Prepare pull request and affected issue for automatic release notes generator * [ ] Pull request - Write a message that explains what this pull request does. What was the problem? How was it solved? What are the changes to APIs or the new APIs introduced? This message will be used in the generated release notes. Make sure it is well written and understandable for a user of Defold. * [ ] Pull request - Write a pull request title that in a sentence summarises what the pull request does. Do not include "Issue-1234 ..." in the title. This text will be used in the generated release notes. * [ ] Pull request - Link the pull request to the issue(s) it is closing. Use on of the [approved closing keywords](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue). * [ ] Affected issue - Assign the issue to a project. Do not assign the pull request to a project if there is an issue which the pull request closes. * [ ] Affected issue - Assign the "breaking change" label to the issue if introducing a breaking change. * [ ] Affected issue - Assign the "skip release notes" is the issue should not be included in the generated release notes. ---------- Example of a well written PR description: 1. Start with the user facing changes. This will end up in the release notes. 1. Add one of the GitHub approved closing keywords 1. Optionally also add the technical changes made. This is information that might help the reviewer. It will not show up in the release notes. Technical changes are identified by a line starting with one of these: 1. `### Technical changes` 1. `Technical changes:` 2. `Technical notes:` ``` There was a anomaly in the carbon chroniton propeller, introduced in version 8.10.2. This fix will make sure to reset the phaser collector on application startup. Fixes #1234 ### Technical changes * Pay special attention to line 23 of phaser_collector.clj as it contains some interesting optimizations * The propeller code was not taking into account a negative phase. ```

We hope to ship this during the day.

Mathias_Westerdahl · January 7, 2026, 8:06pm

Edit: The beta has now been updated with these changes to the fixed update for script and physics.

Mathias_Westerdahl · January 8, 2026, 2:40pm

I have pushed two font related changes to the Beta now. It’ll land in ~1 hour.

hayeduce · January 8, 2026, 4:41pm

everything looks proper now regarding the lifecycle functions and how the physics interacts with them. this release will be huge for physics based games. thanks a lot

illo · January 8, 2026, 6:52pm

I’m putting together some animations, but I still can’t preview the tilesource animations (using Spacebar) in the editor. I can only preview them when I add them to a sprite in a collection, which makes the process cumbersome, especially when trying to tweak the FPS, for instance. So for the time being I’m having to set up the animations in 1.11.2, which still has this functionality. Any assistance would be really appreciated.

mats.gisselson · January 9, 2026, 9:08am

A fix has been merged for the tile source animation preview not working in the editor.

illo · January 9, 2026, 10:43am

It’s working perfectly, thank you so much!

aglitchman · January 9, 2026, 10:47am

Just wanted to point out that LSP doesn’t know about the late_update function:

Klaleus · January 10, 2026, 2:41am

Hello, when is this update planned to release? I see it has been in testing for longer than usual. The addition of late_update() will cure a lot of headaches. If soon, then I’ll wait, otherwise I’ll install the beta.

aglitchman · January 10, 2026, 7:11am

Do not wait - install the beta now!

Each engine beta must be downloaded and used from the very first day of its announcement, without waiting for the release. Otherwise, all beta versions will take as long to reach release as this one, or they’ll be released with bugs, and the team will have to spend time on urgent fixes.

Hunter_Loftis · January 10, 2026, 8:13am

Yeah, installing the beta takes about 2 minutes - just downloading and moving a file. If you want to install it side by side with a stable version you can do that too. Make a fit commit first and there’s no risk to your project.