Distant objects drawing on top of closer ones after updating to 2.3.0

[tomitukiainen]

Hello,

I just updated from toolkit version 2.2.x to 2.3.0 and distant objects started to appear on top of closer ones. It seems that 'Order in Layer' definitions in my tk2dSprites might be causing this.

I've used this ordering feature to define which sprites are drawn on top of each other when they have the same Z-value. For example right hand and right leg of a zombie have higher value than torso, so that they appear on top. 

This has worked fine with the old version. Now it seems that sprites with higher 'Order in Layer' value are always drawn on top of sprites with lower value, even when they are not on same Z. Actually the overdrawn sprites can be a lot closer to the camera. 

--
int SortingOrder [get, set]: Gets or sets the sorting order The sorting order lets you override draw order for sprites which are at the same z position. It is similar to offsetting in z - the sprite stays at the original position. This corresponds to the renderer.sortingOrder property in Unity 4.3.
--

Attached is a screenshot where you can see the problem and 3d version of the same scene. Sorting order of zombie left hand is zero and they are not drawn on top of the menu window but other parts with higher sorting order are (altough they're some 5 units deeper in the scene).


Best regards,

Tomi Tukiainen

[unikronsoftware]

Order in layer in Unity 4.3 ignores position, unlike older versions. If you don't care about compatibility with Unity 4.3 sprites and other sorting layer related behaviour, you can revert to old behaviour by changing a couple functions in tk2dBaseSprite.
SortingOrder - force it to use the (UNITY_3_5 || UNITY_4_0 || UNITY_4_0_1 || UNITY_4_1 || UNITY_4_2) path.
and comment out the line in tk2dBaseSprite.Awake that sets sorting order.

The intention was always to emulate 4.3 behaviour, but it wasn't possible to override the z ordering. The behaviour pre-4.3 is accidental.

[tomitukiainen]

Sorry to hear

I found the old functionality really useful for sorting sprites in my characters. When you define 2d characters hierarchially, ordering by minimal changes in Z position is not very convenient as it requires you to make a bit of calculations to get the overall ordering right when using local coordinates. For example, my wizard is composed like this (layer order before name):

1: Torso
5: -> Head
0:  |- Hat
4:  |- Beard
6: -> Left Hand
2: -> Right Hand
3:  |- Stick
 
But yep, I'll take the most compatible route and swap back to calculating Z positions to get the ordering right. Just note that your documentation of SortingOrder function is now out of date.

Thanks for the fast reply!

[unikronsoftware]

The point is you can get the same behaviour by not relying on z at all. Use the sorting order for everything. Pick increments of 10, eg. char1 gets 10, char2 - 20 and so on. It'll mean updating all children when you're sorting but you get absolute control over the whole process, which could be a good thing. Alternatively you can revert that bit of code and have it behave like it always did. Both will work fine.