Spritekit Not Respecting Zposition

SpriteKit not respecting zPosition?

If they have the same parent that would be true. In case they can different parents, the z order of parents is also taken into account.

The standard behavior for scene rendering follows a simple pair of rules:

1. A parent draws its content before rendering its children.
2. Children are rendered in the order in which they appear in the child
   array.

When you take z positions into account, here is how the node tree is rendered:

1. Each node’s global z position is calculated.
2. Nodes are drawn in order from smallest z value to largest z value.
3. If two nodes share the same z value, ancestors are rendered first,
   and siblings are rendered in child order.

You can find it well explained here under Understanding the Drawing Order for a Node Tree

SpriteKit issue with zPosition

Here is how you are expecting your code right now

 -100: Node
     # 0: Node
        # 0: Blue
   0 : Node
     # 0: Node
        # 0:Red
 100 : Node
     # 0: Node
        # -200:Green
        # -150:Yellow

But what is really happening is this

 -100: Node
     : Node
     : Blue
     : Green
 -50 : Yellow
   0 : Node
     : Node
     : Red
 100 : Node
     : Node

This is because the zPosition is just subtracted from the parent, and the screen then draws in 1 pass all the nodes.

To combat this, you need to create a custom class that overrides the addChild function and do somethings that keep track of your zPosition in another variable (probably a dictionary), then set the child zPosition to zero, and use insertChild(node:, atIndex:) to place your children in order in the children array using this new variable to preserve your order. Then if you are going even more crazy, you would have to keep track of when a child changes its zPosition, and use the above style to set it correctly in the array

SKLabelNode with Children not affected by gravity - not respecting zPosition

Assuming that skView.ignoresSiblingOrder = true in the view controller (the default setting), some thoughts...

1. When ignoresSiblingOrder is set to true, Sprite Kit ignores sibling relationships when determining the order in which to draw nodes. It does not, however, affect the parent-sibling draw order.
2. In either mode, the parent is drawn first and then the child nodes are rendered. Normally, the children appear on top of the parent (if they're at the same location) regardless of the zPositions of the parent and children! The exception is if a child's zPosition is less than zero. In this case, the child will appear beneath its parent (even if the parent's zPosition is less than the child).
3. It doesn't appear that you are setting node.node.name nor the name of the sprite node. If the names aren't set, the if condition will fail and the physics body won't be attached to node.node.
4. The default settings for shapes only draws a white border around its path (in this case, a rectangle). You should see this as an white outline around the sprite node. Setting background.fillColor = SKColor.greenColor() will show the SKShapeNode filled with green.

SpriteKit - The child of my node does not appear to be changing its zPosition attribute

So, it turns out I was setting the zPosition for the shield in its method. Removing that restores normal behaviour when the parent changes zPosition, having it declared explicitly seems to override the nested behaviour.

SpriteKit grand-children of views overlap zPosition

well according to this SO answer, indeed all the zPosition values are calculated before drawing.

I ended up creating a counter for bubbles, adding 1 every time a bubble has been added, and assinging the counter value as its zPosition.
And inside the bubbles, I made sure every child has a zPosition in the range (0, 1)

SpriteKit: SKPhysicsJointLimit not respecting 'maxLength'

Be sure that the anchor points are in scene coordinates, as described in the documentation. The (0.5, 0.5) is likely intended to be "center of the sprite" or something like that, but that's not correct for a joint.

change zPosition of tiles

There is nothing in the definition that allows for zPosition change (Which would make sense since the idea is to draw the tiles as fast as possible)

I would recommend having another tile set overlay it, or have individual sprites that pop out.

---

Related Topics