adrix89
commented
9 years ago On the next frame, if there are any updates, the batch will be resorted before being drawn again, et infinitum.
You can have a hybrid. If an element is animated meaning it will always change you can treat it separately.
Find what elements are below it and what elements are above it and sandwich it between them. The number of spritebatches needed depends on how many animated elements are and how you need to blend them.
I don't think you will ever need more then 3 spritebatches.
Also if you are doing funky stuff and you know what is changing for some time you can separate that also from the spritebatch.
For example if you have a list that was static but now changes constantly its good to detach it from the batch process.
karai17
Batching elements is going to be key to efficiently drawing. If we have hundreds or thousands of individual elements, we sure don't want to draw them one at a time.
Since each element may have a relatively unique texture, it is going to be crucial to create texture atlases so we can batch as many elements together as possible.
With a large texture atlas, we can then sort all of the elements based on their Z-index position. All root elements will have a default Z-index based on their sequential order, starting from 1. All child elements will have a Z-index of parent.properties.z-index + 1 unless manually set.
Once every element is sorted by their Z-index, the elements will be buffered into a sprite batch and drawn.
On the next frame, if there are any updates, the batch will be resorted before being drawn again, et infinitum.
Does this sound right? Am I missing anything?