2 html5 build reports.
one in 1.2.179
the other one is in 1.2.180
All the settings are the same.
web.zip (340.9 KB)
It seems like for html5 build the new compression is worse than webp
4 Likes
When you say worse, I know you mean size on disc.
But what about the texture quality? And the fact that we support hardware textures is also a plus.
And, as I’ve mentioned before, the devs are working on more optimizations for the compression size.
3 Likes
True. You right. I take into account only one aspect.
7.29 vs 5.83 mb it’s a big difference for web. what about the idea to keep current webp lossy from 1.2.179 to 1.2.180 but with other title? 
4 Likes
I don’t see it as very likely that we’ll add WebP back as a builtin compression format. Supporting many separate technologies is an added extra development cost.
We will however be supporting custom resource formats later this year (and we’ll keep this feature in mind when we do). In that scenario you should be able to compress the data any way you want.
Another feature I would like to see as a saving for games chasing the last megabytes, is an api to supply a font with font glyphs. That would enable a game to avoid bundling with a lot of font data.
6 Likes
I want to raise this topic again, my html5 build report of (Raft Wars Multiplayer game)
this is a very big difference for html5 games + ~2.45 mb,
and we see 3.76 mb vs 6.07 mb of atlases size ( > 60% bigger)
we’ve tried for a very long time to reduce the final build size by every 1 megabyte, if check again the video posted by @aglitchman the video Size matters: how loading is losing you players in his topic, such a difference may affect income. 
5 Likes
I agree, it’s not ideal, and we’ll look into it.
Either the basis library update will improve the situation, or we’ll have to come up with a way to use webp again (e.g with an appmanifest).
4 Likes
UASTC is for extremely high quality (similar to BC7 quality) textures, and ETC1S is for very small files. The ETC1S system includes built-in data compression, while the UASTC system includes an optional Rate Distortion Optimization (RDO) post-process stage that conditions the encoded UASTC texture data in the .basis file so it can be more effectively LZ compressed by the end user.
Does it have features for compression amount?
Maybe reaching out to Binomial and showing them the Defold use cases would encourage them to improve compression amounts / have some advice.
@BunBunBun what is the Compression option you have set in your texture profiles when doing that test? Best?
Are you using Live Update already for minimizing initial load? Maybe worthwhile to do that in either case if you are not already.
They had very little. That’s what we’ve been waiting for.
Hopefully their new release adds the RDO optimization, which should have a parameter to tie more closely to our compression level.
Our current compression yields 8 bits per texel. With RDO, we should be able to get down to 4 bits with the optimization parameter.
4 Likes
Of course we can use the Live Update feature 
(and it is planned) but this topic about the texture compression.
4 Likes
Bundle size is very important for HTML5, 1MB makes a lot of difference. I think HTML5 is one of Defold’s strong suits over other engines, so reports of increased HTML5 bundle size are discouraging.
I also vote for still supporting WebP, at least until the new format supports better compression, so there is some transition period.
7 Likes
Thank you all for the feedback! We definitely take your opinions very seriously and I can assure you that we will look closer at this. For one, we will update to the recently released version of Basis. It will reduce size and increase speed. We will also look into reintroducing WebP but as an opt-in solution.
We will look into these changes soon, the Basis upgrade most likely for 1.2.181. Development of 1.2.182 will start on Monday and I believe we may be able to look at WebP then.
For now our recommendation is to stay at 1.2.179 if the increase in texture size isn’t acceptable.
7 Likes