Defold 1.2.128 has been released


Defold 1.2.128

This release adds two features for Spine models and GUI Spine nodes. You can now set specific Spine slots to use different skins at runtime, effectively combining parts from multiple skins. In GUIs you will now also receive Spine events in on_message, the message argument will include a node field specifying which node the event originated from.

The web profiler now also includes a field indicating the total amount of size all the resources used.

In this release of Editor 2, we’ve worked on parallelizing some of the more time-consuming build tasks, which should result in significantly quicker builds for large projects.


  • DEF-3188 - Added: API to change Spine skin slots dynamically.
  • DEF-3056 - Added: Spine events in GUI scripts.
  • DEF-3279 - Added: Total resource sizes in the resource profiler.
  • DEF-3286 - Fixed: Added fix for null access in rare cases after calling iap.restore() on Android.
  • DEF-3283 - Fixed: WebAudio on HTML5 start on first mouse/touch interaction.
  • DEF-3198 - Fixed: HTML5 bug where clicks were not caught if canvas wasn’t selected.
  • DEF-3281 - Fixed: Sprite can now use 32-bit index buffers (which means each collection can have more than 16k sprites).
  • DEF-3277 - Fixed: Profile port 8002 may fail on certain network conditions.
  • DEF-2191 - Fixed: Memory leak in callbacks for models, particlefx and spine.

Editor 2

  • DEFEDIT-1354 - Fixed: Lost layout overrides after reordering Gui nodes.
  • DEFEDIT-1373 - Fixed: Font resources will now use all available processor cores to generate bitmaps.
  • DEFEDIT-1381 - Fixed: Assets tree refreshes faster in projects with many dependencies on Windows.
  • DEFEDIT-1387 - Fixed: Spine/Model animations sometimes sample outside of timeline data.
  • DEFEDIT-1388 - Fixed: File extensions are no longer case sensitive in the editor.
  • DEFEDIT-1391 - Fixed: The compile phase will now use all available processor cores when building.
  • DEFEDIT-1394 - Fixed: Script errors report line numbers when building.

pinned globally #2


DEF-3281 - Fixed: Sprite can now use 32-bit index buffers (which means each collection can have more than 16k sprites).

I am curious as to what this means. Does this mean that 16k sprites can be loaded at once when loading a collection? That up to 16k sprites can be drawn at once in a single collection? What impact does fixing this have on regular users?



It means you can have 16k sprite components active at once per collection.

It will probably have little to no impact on regular users… it’s just nice to have a much higher allowed limit for exotic applications.



… Sorry. Delete me.



more” than :wink:

Previously, we did an optimisation to make use of 16-bit index buffers, since most often, you don’t use more than 16k sprites in a collection. However, the code was unnecessarily restrictive, so we made it so that is checks the max number sprites (set in game.project), and allocates either a 16-bit or a 32-bit index buffer. This means you can have 2^32/4 number of sprites per collection.



This update seems to have caused an issue with sprite rendering in my game, see screenshot below:

For reference, this is what the same area looked like yesterday:

I am using Editor v1 (1.2.128) on Windows 7. @Mathias_Westerdahl - I think you still have access to the project ( “Project Iso”) on your dashboard in case you want to take a look.

Edit: Just opened the project in the up to date version of Editor 2, and I am seeing the same result.



Hmm, weird. I will look into it!



Thank you! In the meantime I have managed to revert to 1.2.127 with the help of @Axel and this page. Can confirm that building the same game in that version causes no issues.



I just confirmed it was my change DEF-3281 that made the sprites look weird.

The workaround I have for you is to change the max sprite count from 16384 to 16383. It will make it choose the “old” 16-bit index buffer path.



But what if I need that additional sprite?! …joke :wink:

Can confirm that this resolves the issue in Editor 2 on my end. I restarted Editor 1 but it’s not trying to push 1.2.128 again (yet?) so can’t confirm that it works there too right now.

Thanks for your help!



I’m having the same issue. @Mathias_Westerdahl workaround worked, however :slight_smile:

1 Like