Sprite z-ordering

[xaviershay]

Currently to control z-ordering I remove a sprite from a scene then re-add it to place it on top (example). This is kind of hackish.

Did you envision this library handling such a thing? I might have a crack at it if you're interested. I was thinking of adding a z-attr to Sprite then sorting by that before drawing at https://github.com/PistonDevelopers/sprite/blob/master/src/scene.rs#L84

Thanks! Xavier

[xaviershay]

Appears to be related to https://github.com/PistonDevelopers/sprite/issues/31

[bvssvni]

This is a good idea!

[xaviershay]

I tried adding a z attribute to Sprite, and then sorting children in the draw step. This has two issues:

1. Seems bad to be sorting all sprites every draw loop. This could be fixed by tracking z changes in the scene rather than the sprite, but that's pretty weird.
2. I don't know how to in-place sort the grandchildren, since you can't have &mut self on Scene.draw when iterating through an already mutated Scene.children ... if that makes sense. There is likely a way to do this I just don't know rust well enough.

The ideal way to do this would probably be to pass z info down into opengl (or other backend) and have it deal with it. I'm pretty sure this is a thing opengl is good at. Blocker for this appears to be Graphics.tri_list-uv (caller) doesn't have a way to pass this information through. I don't have a good suggested interface.

An alternate method would to be provide move_to_front and move_to_back methods on Scene, which could just rearrange the children vector. I'm leaning towards this at the moment, since it's pretty simple and covers at least my use case really well.

[bvssvni]

Sorting in draw loops should be fast enough.

Can't handle sorting by depth in the backend if the blending operation is not communative. Additive blending supports this but not normal alpha blending. Therefore any sorting should happen before sending it to Graphics.

[LuisAyuso]

Passing down the z values to OpenGL may not perform as well as sorting the scene tree.

OpenGL will render the correct scene with the right visibility, nevertheless, this comes a the price of redrawing the same pixels and writing in the z-buffer. In the worst case, we can end up drawing each sprite just to be overwritten with the next one drawn. Of course, this performance issue may only be noticeable with very large number of overlapping sprites.

Sorting the scene tree is usually a good technique.

In any case, I see a great value on implementing a z value for the sprites. Looking forward to see this feature.