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

[James Paige]

On Sat, Jan 31, 2009 at 09:29:46PM +1300, Ralph Versteegen wrote:
> 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.

What is a good test for stable sorting? If I have that, I can figure it 
out from there.

> >> 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? :)

Well, simply collecting things in containers and organizing those 
properly is the way to do depth, but I guess I don't need to restrict 
people from sorting siblings using a non-temporary sort order.

> 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.

Yes. 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.

I would rather keep the scope of this to 2D stuff, not 3D or psuedo-3D 
isometric. I think simply grouping things in layers allows everything 
you would need for a 2D minigame.

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

Yes, I agree.

---
James Paige