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.
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.
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.
@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.
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.
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.
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)
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 )
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.
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?
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.
)