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!
2 Likes
Thanks a lot for working on the compression task! 
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)
1.2.179
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:
-
Very good news that no longer take 5-7 minutes to build project (Project → Bundle → HTML5 app).
-
Something weird with
etc1scompression, check 185_etc1s_high demo:
ERROR:GRAPHICS: Transcoding failed on level 0 for /main/main.texturec -
If to see the results and to compare the quality / size, we’re still love the
webplossyin 1.2.179 version. We’re still working on it because of that. as I know @Lampogolovii also.
6 Likes
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.
2 Likes
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.
5 Likes
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.
4 Likes
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.
4 Likes
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 
2 Likes
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.
4 Likes
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.
4 Likes
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 )
4 Likes
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”.
5 Likes
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. 
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 build-stage.defold.com (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.
Log:
(lldb) run
success
dyld: Library not loaded: /System/Library/Frameworks/AVFAudio.framework/AVFAudio
Referenced from: /var/containers/Bundle/Application/88543E5B-2554-4E45-AA65-9975913BCCCE/AdMob.app/AdMob
Reason: image not found
Process 337 stopped
* thread #1, stop reason = signal SIGABRT
frame #0: 0x0000000101912418 dyld`__abort_with_payload + 8
dyld`__abort_with_payload:
-> 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.
(lldb)
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.
5 Likes