[Ohrrpgce] SVN: james/2512 New commands "set sort order" and "sort children" for easy custom sortin

[Ralph Versteegen]

2009/1/31 James Paige <Bob at hamsterrepublic.com>:
> On Sat, Jan 31, 2009 at 07:15:50AM +1300, Ralph Versteegen wrote:
>> > New commands "set sort order" and "sort children" for easy custom sorting
>> > of sibling slices without need for fancy looping voodoo. Added examples
>> > to the docs.
>>
>> Great! I was just ranting to IM how without an easy way to draw by Y
>> and Z values instead of rearranging children, sprites wouldn't be any
>> better than NPC's for my needs; I hadn't noticed these.
>>
>> Firstly, EGADS! "Y sort children" and "sort children" do NOT perform
>> stable sorts as advertised in the wiki!
>
> Oops! What did I do wrong? Sorting is not my speciality :P

Me neither. I couldn't tell you which sort you're using, only that
it's not stable.

>> However, I think that wiping the sort value for sprites while sorting
>> them is a bad idea. Whether it's wiped MUST be an optional argument to
>> sortchildren. I really think it shouldn't by default. You'd only want
>> to wipe the sort values if you're using sort children as a hack to get
>> around the difficulty of using nextsibling.
>
> Hmmm... I guess it could persist.
>
> In that case we will also need a command to read the sort value.
>
> I guess my reason for making sort order a temporary value is because I
> wanted it to /only/ be used for sorting, and not used for manual depth
> control... but I don't have a good argument for forcing that limitation,
> so I am willing to change it.

Why would you want to do that? Because you have an even better
proposal for controlling depth, right? :)
Originally we discussed a far more flexible (and complicated) system:
using one tree for position and another for depth. I have to admit it
was overcomplicated.
Perhaps an O(n) traversable multimap implementation would be useful.

My complaint with using sort splices and y sort splices is that
everything you want to sort has to have the same parent. If you have a
3D scene (common in isometric games) you could do a Y sort followed by
a Z sort on the container that holds all the objects on the map. But
that means that you can't create logical groups and probably have to
split up large object into smal pieces. Also, doing something like
having the room half full of water and having a semi transparent water
surface sprite cover the whole map at a certain z level would be
impossible without manually partitioning everything into above water
and below water every tick.

Arrays (and especially associative arrays) are probably the answer to
the logically group problem. No more nextsibling!

>
>> Also, what about options (similar to fill parent) which automatically
>> sort children by Y or Z every time they are drawn? With a suitable
>> stable sort algorithm, sorting an already sorted list would be quick.
>
> Huh, that is kinda interesting. I can see how it could save some work.
>
> ---
> James Paige