Defold 1.2.185 BETA

Mathias_Westerdahl · July 12, 2021, 4:44pm

Defold 1.2.185 BETA

The latest beta is now released, and we invite those interested in beta testing the new features in the editor and engine to join now.
The beta period will be 2 weeks and the next planned stable release is two weeks from now.

We hope this new workflow will highlight any issues earlier, and also get valuable feedback from our users. And please comment if you come up with ideas on improving on this new workflow.

Please report any engine issues in this thread or in issues using Help → Report Issue

Thx for helping out!

Disclaimer

This is a BETA release, and it might have issues that could potentially be disruptive for you and your teams workflow. Use with caution. Use of source control for your projects is strongly recommended.

Access to the beta

Download the editor or bob.jar from Defold Downloads

Set your build server to https://build-stage.defold.com

Release notes

This sprint we’ve updated to iOS 14.5, MacOS 11.3 and Xcode 12.5. As always, please let us know if you find any issues with the updgrade.

We’ve also updated our Android build tools to use the d8 tool for creating the .dex files.

As a consequence of updating the Android build tools, we also had to update our LuaJIT implementation.
It is still 2.1.0 beta3 but it’s from a month ago. Our previous version was from 2017 (!).

Work in progress

We’ve also continued our work on our new Rive and Spine extensions (actually 2 Spine extensions).
They’re not quite ready just yet, but we’ll let you know when they are ready for testing.

Engine

Issue-5726 - Updated: Android dx to d8 migration
Issue-5900 - Updated: Luajit 2.1.0 beta3 update
Issue-5920 - Updated: Udated sdks to iOS 14.5, macOS 11.3, Xcode 12.5
Issue-5853 - Fixed: Fixed crash in Lua callstack logging
Issue-5859 - Fixed: Fail a build if the project contains more than one .project file
Issue-5887 - Fixed: Option for recursive check in gui.is_enabled()
Issue-5916 - Fixed: Don’t skip whitespace on single-line text
Issue-5922 - Fixed: Updated the texture compression levels

Mathias_Westerdahl · July 12, 2021, 4:54pm

In Defold 1.2.183, the RDO optimizations were turned on, but when testing, we didn’t notice the large jump im time spent in compressing these textures.
In this release we remedy that by having two levels “as before” without RDO optimizations, and two levels with RDO optimization.

Later, the updated documentation page will go live as well, but here are some explanations and numbers from the docs:

The NORMAL represents the BEST level from 1.2.182, and should be a good option for most projects.
If you’re willing to spend a little more time (e.g. on CI machines), you can save some extra bytes by using the HIGH or BEST compression levels.


| LEVEL    | Note                                          |
| -------- | --------------------------------------------- |
| `FAST`   | Fastest compression. Low image quality        |
| `NORMAL` | Default compression. Best image quality       |
| `HIGH`   | Slowest compression. Smaller file size        |
| `BEST`   | Slow compression. Smallest file size          |

The example below is for a 1024x512 image (kodim03_pow2.png).

Compression times

| Level      | Compression time | Relative time   |
| ----------------------------- | --------------- |
| `FAST`     | 0m0.143s         | 0.5x            |
| `NORMAL`   | 0m0.294s         | 1.0x            |
| `HIGH`     | 0m1.764s         | 6.0x            |
| `BEST`     | 0m1.109s         | 3.8x            |

Signal loss

The comparison is done using the basisu tool (measuring the PSNR)
100 dB means no signal loss (i.e. it’s the same as the original image).

| Level      | Signal                                          |
| ------------------------------------------------------------ |
| `FAST`     | Max:  34 Mean: 0.470 RMS: 1.088 PSNR: 47.399 dB |
| `NORMAL`   | Max:  35 Mean: 0.439 RMS: 1.061 PSNR: 47.620 dB |
| `HIGH`     | Max:  37 Mean: 0.898 RMS: 1.606 PSNR: 44.018 dB |
| `BEST`     | Max:  51 Mean: 1.298 RMS: 2.478 PSNR: 40.249 dB |

Compression file sizes

Original file size is 1572882 bytes.


| Level      | File Sizes | Ratio    |
| ---------------------------------- |
| `FAST`     | 357225     | 22.71 %  |
| `NORMAL`   | 365548     | 23.24 %  |
| `HIGH`     | 277186     | 17.62 %  |
| `BEST`     | 254380     | 16.17 %  |

Mathias_Westerdahl · July 13, 2021, 7:50am

The documentation for the texture compression levels is now updated (same as above):

And the example with images (to display the difference in image quality)

ross.grams · July 13, 2021, 12:46pm

@britzl I really appreciate you working on the trailing spaces issue!

…and I’m here to report some issues with it.

The editor doesn’t use the new behavior. (Not a blocker, but should be fixed at some point)
gui.get_text_metrics mostly works but is a bit buggy now.

The first trailing space actually reduces the reported width, but then it’s correct if you add a non-whitespace character at the end. It seems like one character is going missing somewhere. The discrepancy is a bit different depending on what the last character before the trailing space is.

test project: v185-trailing-space-test.zip (106.0 KB)

britzl · July 13, 2021, 3:30pm

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!

BunBunBun · July 15, 2021, 10:21am

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 etc1s compression, 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 webplossy in 1.2.179 version. We’re still working on it because of that. as I know @Lampogolovii also.

Lampogolovii · July 15, 2021, 11:08am

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.

britzl · July 15, 2021, 11:30am

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.

Mathias_Westerdahl · July 15, 2021, 11:44am

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.

BunBunBun · July 15, 2021, 11:45am

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.

kondr1 · July 15, 2021, 12:35pm

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

Mathias_Westerdahl · July 15, 2021, 12:38pm

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)

kondr1 · July 15, 2021, 12:54pm

Ok. I just noticed that. Thanks

britzl · July 15, 2021, 8:14pm

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.

Pkeod · July 15, 2021, 8:38pm

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.

Mathias_Westerdahl · July 16, 2021, 9:53am

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 )

britzl · July 16, 2021, 10:00pm

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

Lampogolovii · July 21, 2021, 11:26am

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”.

d954mas · July 21, 2021, 12:24pm

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.

Pkeod · July 21, 2021, 5:40pm

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.