Defold 1.2.185 BETA

Thanks! And thank you for testing it so that we can fix issues before the release!

Ah, true!

Thanks. I need to add some additional unit tests to catch this!


Thanks a lot for working on the compression task! :slight_smile:
Today I found a time to check out the compression in 1.2.185 beta, here results:
(tested as before in real project with 12 atlases with different sizes)

WEBP_LOSSY_HIGH:		size 3.76 mb	| time ~22s
WEBP_LOSSY_NORMAL:		size 2.65 mb	| time ~22s
WEBP_LOSSY_FAST:		size 2.30 mb	| time ~20s
WEBP_LOSSY_BEST:		size 4.55 mb	| time ~50s

1.2.185 BETA

BASIC_UASTC_HIGH		size 5.43 mb	| time ~2m34s
BASIC_UASTC_NORMAL		size 6.03 mb	| time ~0m48s
BASIC_UASTC_FAST		size 5.89 mb	| time ~0m34s
BASIC_UASTC_BEST		size 5.08 mb	| time ~1m15s

BASIC_ETC1S_HIGH		size 2.28 mb	| time ~1m10s
BASIC_ETC1S_NORMAL		size 2.13 mb	| time ~1m17s
BASIC_ETC1S_FAST		size 1.90 mb	| time ~1m15s
BASIC_ETC1S_BEST		size 2.43 mb	| time ~1m26s

DEFAULT_HIGH			size 9.12 mb	| time ~0m26s
DEFAULT_NORMAL			size 9.12 mb	| time ~0m27s
DEFAULT_FAST			size 9.12 mb	| time ~0m26s
DEFAULT_BEST			size 9.12 mb	| time ~0m30s

WEBP_HIGH			    size 9.12 mb	| time ~0m25s
WEBP_NORMAL             size 9.12 mb	| time ~0m27s
WEBP_FAST			    size 9.12 mb	| time ~0m27s
WEBP_BEST			    size 9.12 mb	| time ~0m27s

WEBP_LOSSY_HIGH			size 5.43 mb	| time ~2m22s
WEBP_LOSSY_NORMAL		size 6.03 mb	| time ~0m45s
WEBP_LOSSY_FAST			size 5.89 mb	| time ~0m34s
WEBP_LOSSY_BEST			size 5.08 mb	| time ~1m17s

Some thoughts:

  1. Very good news that no longer take 5-7 minutes to build project (Project → Bundle → HTML5 app).

  2. Something weird with etc1s compression, check 185_etc1s_high demo:
    ERROR:GRAPHICS: Transcoding failed on level 0 for /main/main.texturec

  3. If to see the results and to compare the quality / size, we’re still love the webplossy in 1.2.179 version. We’re still working on it because of that. as I know @Lampogolovii also.


Yes, we build html5 versions of our games in 1.2.179. Because of the build’s size. (webp lossy + best)
In web production every 10% of size matters.


Thank you for taking the time to test!

@JCash might know more

Yes. We will bring webp back as an extension or similar at some point this year.


HI @BunBunBun !
Thanks for testing.

Note that the WEBP_HIGH/WEBP_LOSSY_HIGH etc are the same as the BASIC_UASTC_HIGH.
We only kept the names in order to keep older projects working.

As @britzl mentioned, we aim to add an extension later that will allow you to switch out the texture compiler (and engine loader), to something else.
WebP might be a good first choice.

We currently don’t support BASIC_ETC1S_HIGH/etc.
It was an oversight to include it (and I will remove it now).
We did a special build where we could test it, but nothing was released.
Instead of adding it by default to the engine, we will possibly add it as an extension later on.


Awesome! What about the idea to create issue on github about it?
I watch regularly the roadmap for versions on github. it is very convenient to follow and see what is expected in the next version.


At this moment in steam 1.2.178 version. Can you update plz?

Hi @kondr1 !
We don’t maintain that Steam page, it’s @Pkeod who’s doing that.

Also, the initial download is just that, initial.
Any further updates to the editor is done from within the editor.
Check for a blue link at the bottom right corner of the editor (or on the splash screen when you select projects)

1 Like

Ok. I just noticed that. Thanks :slightly_smiling_face:


The Defold Foundation owns the Steam page but @Pkeod has helped out with some of the setup.

Managing and distributing content via Steam is an absolutely horrible experience as a content creator and I’m surprised people accept the crappy UI and overall bad user experience.

As @JCash pointed out the editor will auto update as soon as you start it. We should make this clear on the Steam download page.


Maybe first time running the editor could include a mini guide? A few pages with images and small amounts of text. One of the pages could explain how updating works. Another could explain beta releases / beta build server.


I like things like this!
Is there a link/source online for others to read?

Also, since we moved to Basis Universal (from WebP), have you seen any size related effects on your project?
If so, are there any numbers or details you can perhaps share?
(I understand if you can’t share it, I just think it’s interesting for both us and our community :slight_smile: )


Created: Add WebP compression as an extension · Issue #5938 · defold/defold · GitHub


We publish games on Poki, and they shared this video Size matters: how loading is losing you players on Vimeo about game’s size.
For me - it is really hard to make a correlation between size and popularity/plays-count/money based only on my 10 games.
So for me it’s easier stay on 1.2.179 for now. As “just in case”.


webp is have very long loading time(decompression) in game. On html it is super slow.
In one my big game. We use webp only for backgrounds. Because when we use it for everything, loading was slower then without webp. :thinking:

We have 5 different background, 1 for every zone.
So when game start we load in memory only one.

Not sure about loading time of BASIC:)
Is someone make tests?

Some old tests.

1 Like

If you run a game portal powered by Defold I strongly believe it would be worth enforcing every single game runs on the same game engine version file. Then build the games on the portal with dynamic scripting / whatever so they can all point to the same engine files for JS/wasm. This would enable you to make micro web games with Defold that really do load instantly once the initial engine files load. If the game files itself are bigger than 10MB it’s not really worth it though. Another thing you can do (can be messy or clean depending on how you organize it) if you have a portal with many micro web games that should load instantly is to have all games live within a single project but load them based on Live Update / app id boot loading.

Of course doesn’t work as well on 3rd party portals.

1 Like

@totebo reported an issue for DefVideoADS about crash on some iOS devices.

I investigated this issue and found that crash is happening when I build DefVideoADS or AdMob using (I tried it using both 1.2.184 and 1.2.185) and then run build on older iOS version. @totebo tested it on iOS 14.4.2, I tested on iOS 12.5.2. I assume it’s for all iOS lower than 14.5 but I’m not sure.


(lldb)     run
dyld: Library not loaded: /System/Library/Frameworks/AVFAudio.framework/AVFAudio
  Referenced from: /var/containers/Bundle/Application/88543E5B-2554-4E45-AA65-9975913BCCCE/
  Reason: image not found
Process 337 stopped
* thread #1, stop reason = signal SIGABRT
    frame #0: 0x0000000101912418 dyld`__abort_with_payload + 8
->  0x101912418 <+8>:  b.lo   0x101912430               ; <+32>
    0x10191241c <+12>: stp    x29, x30, [sp, #-0x10]!
    0x101912420 <+16>: mov    x29, sp
    0x101912424 <+20>: bl     0x101911850               ; cerror_nocancel
Target 0: (AdMob) stopped.

I tested 12.5.4 on iPhone 6 Plus and AdMob crashes.

1 Like

Thanks for the report, I’m looking into it.

Not sure where the AVFAudio dependency comes from though.

1 Like

Sorry, it was a false alarm.
AVFAudio should be added as weakFrameworks in ext.manifest and than it works fine.

Now we need to fix it for DefVideoADS and AdMob not sure if some other extensions affected.