Defold 1.2.181 has been released

In this version we’ve set the supported OpenGL version to 3.1+ (previously 3.3) for Linux and Windows. Note that this version is for the engine, not the editor.
Hopefully, this will improve the support for some users having issues.

We’ve also optimized the font renderer which will be good for the more text heavy projects.

Another great optimization is for the mesh components. They will no longer upload their vertex buffer each frame, but only if the buffer is modified. The Native Extension api got the new dmBuffer::GetCOntentVersion() and dmBuffer::UpdateContent.

Native extensions

We are currently working on a long running task on adding pipeline extensions.
As part of that, we’ve added two more apis to our dmSDK:

The component API will let you create a new component type, with the same life cycle functions as our in game component types.
To register such a type, you’ll also need to pair it with a resource type.

Note: We haven’t started documenting these yet, but we’ll do that as the task progresses.
In the meantime, you can look how we use these apis in the engine at
res_script.cpp and gameobject_comp.cpp

Work In Progress

As mentioned, this is part of a long running task, and we might need to change the api’s somewhat in the near future, although it’s not very likely as these are old api’s that we’ve used internally.


  • Issue-5010 - Fixed: Fixed crash issue with lingering http request at shutdown
  • Issue-5167 - Fixed: Fixed allocation when doing a reassignment of a mesh
  • Issue-5167 - Fixed: Mesh components can share vertex buffers
  • Issue-5313 - Fixed: Don’t upload font vertex buffer unless it has changed
  • Issue-5313 - Fixed: Only upload font vertex buffer data at the end of a draw command
  • Issue-5506 - Fixed: Http requests now prioritize max-age over ETag
  • Issue-5585 - Fixed: Updated the document
  • Issue-5615 - Fixed: Reset the frametime when coming back from iconified state to avoid a large delta time
  • Issue-5617 - Fixed: dmengine now supports -v and --verbose
  • Issue-5624 - Fixed: iOS: Enable codesign for dynamic frameworks.
  • Issue-5627 - Fixed: Use OpenGL 3.1+ on desktop
  • Issue-5640 - Fixed: Fix zero size canvas when open game in separate Chrome tab.
  • Issue-5644 - Fixed: Fix for large first dt when using variable dt
  • Issue-5655 - Fixed: Alignment fix for Basis Universal on non desktop platforms
  • Issue-5659 - Fixed: Improve require() parsing
  • Issue-5669 - Fixed: Http request settings now work on each individual request
  • Issue-5671 - Fixed: Close http request connection after the request timed out
  • Issue-8 - Fixed: Android: Added support for the d8 tool on the build server
  • Issue-5605 - ADDED: NE: Add resource api to dmSDK
  • Issue-4885 - Added: NE: Added component sdk
  • Issue-5678 - Fixed: Readded dithering to 16bpp image formats
  • Issue-5639 - Fixed: Added support for BC7 textures on HTML5


  • Issue-551 - Fixed: Fixed dialog layout when deleting multiple files
  • Issue-5091 - Fixed: Ignore Mouse 4/5 buttons in editor
  • Issue-5665 - Fixed: Add basic authorization from userinfo in build server url

Hello guys. I dont remember when, but I thought i read about feature that made possible to exclude dirs\files\resources from bundling process (editor and bob). Is it really planned or I’m just dreamed of it? Trying to seach it, but failed.

1 Like

Not sure what you exactly mean but it is possible to exclude resources (dirs/files…)?

1 Like

Perhaps you mean the “–exclude-build-folder=folder1,folder2” feature of bob.jar?

@selimanac AFAIK Bundle Exclude Resources is for Bundle Resources, not all resource in project. Or maybe I’m wrong
@Mathias_Westerdahl that probably what i want ( need to test it) Is there any plans for add this options as part of game.project files? (So it would work in editor bundling\html 5 running). This whould be userful for building several application from one source code.

I think you are looking for this feature request:

1 Like

Yes, thanks. Added some thumbs emoji into it

hmm, the “update” link is still not available on my macbook (1.2.180 alfa-channel). But if download package from site and replace old one to 181, there is “update available” link. But if click it, will downloading 180 again.


+1 here on Win10
Manual update to 1.2.181
Editor ff5b94e432eb58dabdb8e367bed9acc5e99e129b
Engine ff5b94e432eb58dabdb8e367bed9acc5e99e129b

“Update available” revert to 1.2.180
Editor 4c6112fb7a96af7104d87739c9f5130062b86bff
Engine f34b08dc12af1101ae62c6e880b6373a03206174


@Dragosha @AlexeyFeskov It’s because I forgot to push those changes :confused:
The autobuilder is now building the branch and I expect it to finish in ~20-30 minutes.


When testing a build with BASIS_UASTC texture comression on iPad mini 2 i found a visible bug in the release version (one texture not showing, black box):

In debug version this build crashing on that screen with an error:

As I understand it’s going on with RGB (without A) texture and 1024x512 atlas (it matter, cause 1024x1024 atlas with the same texture profile shows correct).

this atlas:

profiles {
  name: "rgb"
  platforms {
    formats {
      format: TEXTURE_FORMAT_RGB
      compression_level: BEST
      compression_type: COMPRESSION_TYPE_BASIS_UASTC
    mipmaps: false
    max_texture_size: 0
    premultiply_alpha: true

Without texture compression (default profile) all works correct.

UPD: added atlas image in post

1 Like

Good catch!
We have code to make the texture square, but it’s only triggered if the format is specified as PVRTC in the texture profile. That ofc, defeats the purpose of the generic format like UASTC.
I think we need to detect this case in the engine, and if the texture is not square, use uncompressed RGB as the target format instead. (Not sure I can make it square at runtime)


Especially interesting that I have an Android version on Google Play with UASTC enabled right now :crazy_face: with the same textures and it seems as workable, at least I have not reviews from players with visuals issues.


It happens every time but recorder doesn’t catch it every time.


Noticed an issue related to playing particlefx on the first frame in this case they glitch. Will try to get a minimal project where it happens to share soon.

This is really bizarre, this image is not even in the atlas but somehow is being used in the first frame of these particles when playing them, changing image doesn’t help.


It does not happen if Steam is closed.

It does not happen at all in 180.

1 Like

This is really bizarre, this image is not even in the atlas but somehow is being used in the first frame of these particles when playing them

If the engine doesn’t set the texture, it will use the texture already set.
If you do not have the steam logo in the app at all, then it’s weird I admit, but it might use whatever is in the GPU memory there then (I’m guessing).

It does not happen at all in 180.

We haven’t changed anything render related (only the OpenGL version from 3.3. to 3.1+). My guess is that we’ve uncovered an old issue that been working by chance before.

1 Like


It looks like the logo from the Steam overlay. So maybe that explains part of why it’s used in this situation where the texture isn’t right.


I cannot reproduce it using vanilla engine and the project.
Going to try using the steam extension now as well.

I can conform that doing this works for both the editor as well as the game when you launch it on Ubuntu 20.04 (meaning both the editor and game runs now work if you do this):


Thank you for this confirmation @ahmedmaawy!