It's rather hard to organize correct sprites render order (especially when there are a lot of them) with only two existing blocks ("go to back/front" and "go back N layers"). It would be great to be able to manually assign and read sprite layer indexes.
I agree that there should be a way to read the sprite's layer number.
Doesn't
work to go to layer n?
May be it works, but the whole layers logic remains unclear. How many layers are there? When a new sprite is added, what layer is it assigned to? And what about it's clones' layers? Can two sprites belong to the same layer? Does sprite's layer number change when another sprite receives a command "go to front/back layer"? I didn't find any mentions of layers in the Snap manual.
I think the good way of handling layers would be someting like this. Each sprite has a layer id that can be directly written and read. This id can be negative, the ids array can have holes (i.e. I can have three sprites with layer Ids -5, 0 and 100 for example). Sprites can have the same layer Id value. The only rule is: sprites are rendered starting from lower Id to higher. That is id = -5 will overlap id = -100 and will be overlapped by id = 10. When the Ids of two sprites are equal, then their render order is undefined.
No. What should be displayed if two sprites of the same layer overlap?
Yes, of course.
The number of sprites
(my [other sprites])
in the stage show all sprites in order from back to front.
Yes, it works. Thank you. Layer logic has become a bit clearer to me.
And what if a clone is created? What layer it becomes assigned to?
UPD: Tested it myself. A clone always appears at the top of sprites list. It's not very good when I have sprites with game elements, enemies for example, and sprites of game interface. Interface sprites must always be at the top, above enemies and other ingame objects. But when I clone them they go to top, and it is not an easy task to understand how much steps back I need to do for each clone to put them in the right place.
Hmm. Would everyone be happier if new clones go in front of their parent rather than all the way in front? I guess we should look at existing projects and see what they do about this.
Yes I suppose they may be happier. Because usually you have sprites of different classes and it is reasonable to expect that all the sprites of one class are in front of all the sprites of the other class.