Tilemap layers and sprite ordering (DEF-1184)



I have a “map” game object (with z = 0) with tile map. It has two layers (foreground with z = 1 and background with z = -1).

I have a “character” game object (with z = 0) with sprite (z = 0).

I expect that a character sprite will be rendered between tile map layers, but all layers are rendered bellow or after the character (depending on character sprite z).

I found that i can move each layer to own tilemap and draw them separately, but it makes too hard to edit them and keep them synchronized.

Screenshots: https://yadi.sk/d/yCMCAZ7SoE5mM
On the first screenshot tilemap with two levels, foreground is active.
On the second — game screenshot with sprite z = 0 (you can see character position as a collision sphere).
On the third — game screenshot with sprite z = 0.5 (you can see that character is drawn on the top of both tilemap layers).

Tilemap Z order and graphic problem (SOLVED)

Yes, currently each component is sorted as a whole. Tilemap layers are not separated in sorting. We have discussed internally if that would be possible to solve but there is no definite plan as far as I know.


Hm, we should really look into fixing that. I think most developers would expect the behaviour described by @Aleksandr_Derbenev.


There’s already a Jira ticket for this: DEF-1184. No release date set.


Is it posible to increase priority of this issue? It will be really useful for isometric-view games.


@Ingela_Garneij is the one responsible for the backlog. Ingela, what’s the prio of this issue?


I’d be interested in this too.
Is it possible to do a parent/child relationship between the map and objects on the map?
For example - add the sprite as a child to the map and if the map moves the character will stay in place (relative to the map).


You can do that. Put the sprite and map in separate game objects and set one GO as parent to the other. See http://www.defold.com/ref/go#set_parent


I cannot be any more specific than during Q2, since priorities constantly change


@britzl Hm, we should really look into fixing that. I think most developers would expect the behaviour described by @Aleksandr_Derbenev.


Your question is exactly what I was looking for! I expected that the z-position of any layer inside a tilemap, is somewhat global, and I could render my dynamically spawned gameobjects in between of two layers of a single tilemap. But that’s not the case!

Some observations

I thought that material tags and render.predicates might solve that issue. I read about materials and render.predicates. As far as I understand the docs, predicates are only useful for controlling the draw-order of a bunch of components through the render_script. Given that a render.predicate has one tag (which is assigned to two different materials, which in turn are assigned to two separate components), I would have expected that both components would merge into a single draw-call (because of the same material tag). That’s not the case either!
Instead, a render.predicate is basically a selector that says: “draw components with certain material tags before|after others”. This way you don’t need to manage a ton of predicates, but rather sum some of them up to one predicate and manage that.


I ended up splitting my single “game-world-tilemap” into multiple “rooms”. Obstacles like pillars and walls (that I can go behind and in-front) are now each on a separate tilemap. At the end I stitched my world from all these building-blocks and done z-sorting on them when needed.

PS: I’ll see how performance will be, once the map grows. If it drops, I might be able to solve that with collections (chunks of “rooms”), which I’d load and unload at runtime, depending on current camera position…


Components in the same predicate are batched if they are the same type, has the same texture (atlas) and same Z. Batching is very aggressive for performance reasons but the currentl problem is that tilemaps are batched separately from sprites which causes the problem you see.


@sicher Good to know how they work. Thanks for the additional information on this!


It seems that this issue still persists?


Yes, I’m afraid so. Not sure when we’ll get around to fixing it. @Sara?


Just encountered this problem as well, would love to see it fixed :slight_smile:


Yes, we haven’t forgotten this, and we’d still like to revisit this. Hopefully, we’ll get to it when we will start working on culling for tilemaps etc. There are several things ahead of this in the queue though, so ETA is unclear :confused: