Teaser Fridays and Roadmap talks


Epic update! :+1:

Maybe you can do that, too… -> "Visible" and "Z" control via Tilemap API



I’ll look into it for sure!

What is the use case for setting Z of a layer at runtime?



Next step for tilemaps must be ability to assign custom convexshape for particular tile.
What is generated from opaque pixels is good for nothing (unless it’s just rectangles).

1 Like


Yes, the tile collisions can definitely be improved.



I was working on a sandbox game.
There’s a change of day and night in the game.


I planned to make the top layer of “Night” with tiles of certain transparency and red shade. When night fell, I planned to turn on this layer and change the alpha through “tilemap.set_constant”. Of course, “tilemap.set_constant” refers to the whole tilemap, but I would create several layers with pre-defined transparency, so I asked you to at least turn the layer on/off or change the Z so that you can hide the layer.

In short, I had to create a separate “tilemap” light1, see the picture.

The performance has been decreasing significantly.
You can put a lot of things into additional layers:

  1. Night-day (alpha layers)
  2. Special full screen effects.


very early tease…


TexturePacker support and polygon sprites (DEF-3055)

Is that polygonal sprites? That’s super cool! Congrats! :heart:



Will you support the latest Spine features?



Which features do you need?



Mesh scale like the vine grows up.



Do you mean the vine Spine example?



Yes, something like it.



We planned the 1.2.163 release today. Three items planned for the release in two weeks:




Those would be great especially sound completed callback! We will no longer have to guess based on counting time to know when music is probably done. :slight_smile:

What I need more personally to switch back to using Defold audio directly:

  • Audio on its own thread, not lockstep, to avoid audio glitches when the engine hiccups especially when loading assets (still happens even with improvements to loading that were done at some point)
  • Ability to designate certain audio as to be streamed instead of being fully loaded into memory, designate how much buffer to keep loaded at once

Beyond those an audio profiles system (similar to texture profiles) would be useful. To modify the audio compression (especially selectively) when bundling would be super convenient. Being able to select platform specific audio types for bundling so that hardware playback can be used. Ability to have more lazy loading of audio so engine can load/unload as audio samples are used, and some samples can be marked to be loaded immediately/always loaded while others can be easily auto loaded as they are played and unloaded if not used for a while.



Audio on its own thread

Regarding threading, it’s not in our roadmap (yet). It’s a good suggestion though, and given that it’s message based, that should make it easier to do.

“Ability to designate certain audio as to be streamed instead of being fully loaded into memory, designate how much buffer to keep loaded at once”

The sound is specifically memory mapped directly from the archive files, so it shouldn’t have all the data in memory at once.
So when creating a sound resource, it should only get a raw pointer to the file on “disc”. It’s not duplicated in memory (at least it shouldn’t be)
Is this an issue you actually have and something you can reproduce?

Audio profiles

In what scenarios do you need to resample the audio upfront?
Also, I think prebundling scripts (aka editor extensions) should help with those things.

hardware playback can be used

It’s not in our roadmap, and we’ve always favoured one code path to make things small and platform independent. I can see the value for it, but I’d rather add support for this through extensions, as opposed to adding this internally in the engine. (A good example is the hardware video player extension the Pet Rescue Puzzle team implemented)



This pretty cool! Btw. I’ve noticed that some profilers (I remember htop doing this) include memory mapped files in the app’s memory usage number, which is misleading, so be careful which metric you’re looking at.



I do not know for sure about the audio memory issue at the moment, I will test sometime soon to see if it’s a real issue. It is mostly an issue on mobile if it is. So this means we should not need to worry about unloading audio currently we can keep it all “loaded” in a main collection and it would have similar memory impact as that collection not being loaded at all?

Audio profiles would be big ask, and less important than other things. It is the same benefit as using texture profiles. Being able to test out different compression quickly and modify multiple files at once without needing to use external editors. Of course external tools can be used, but the same could be said for textures. Texture profiles are a crucial feature of Defold. FMOD Studio has something similar for audio, but using it has catches and expensive.

I have not yet but I do plan to contribute to the OpenAL extension. Add more format support, and make some helper scripts (for direct bob bundling) to do the audio per target pre-processing with open source software available. Hardware playback can also be done with the extension I think. For Android it is most important.



it would have similar memory impact as that collection not being loaded at all

There’s ofc some overhead for a collection and its components, and you might still want the organisational help of using multiple collections.



I tested this now and it looks to not be the case, Defold loads all of the sound components into memory all at once. Am I misunderstanding something in how this should be setup? It seems like the only way to not keep everything in memory at once is to have a collection proxy per song, which sucks because changing songs makes the game hang and any other audio playing glitch still.

Before adding sound components for songs





Otherwise it is a blank project, not even playing the sounds.

What I want is a checkbox on some sound components to not load them at all and only stream data as they are played. Then in game.project be able to say how much buffer to keep loaded at any time.



Well, tbh, I’m not sure why we’d reallocate the data again, since it’s already memory mapped, but I’ll look into it soon.