• Editor

  • Keyable draw order!

    anglais
Related Discussions
...

Greeeeeat!

Now, the expected question:

How much is the performance hit of a keyed draw order vs using more slots?

I guess it depends how much one would change the order, which I think won't be too much, but I would like to hear your opinion 🙂

Without being an expert on the subject. I'd say that keyable draw order is faster than using two slots.

Shiu a écrit

Without being an expert on the subject. I'd say that keyable draw order is faster than using two slots.

I see, thanks. Well, gonna change some animations 😛 but this is sweet.

Awesome news!

Seriously impressed with the updates in Spine - thanks Nate keep up the good work! 🙂

error exporting~~when I do some tests...

It's what happens when export more than one keyable Draw order

@Snow_storm, oops, fixed!

@Cuellarjmcg, the difference is negligible. Two slots means 2 timelines, one for each slot, and a map lookup to find the attachment. Keying draw order means 1 timeline which does 3 array accesses per slot that the skeleton has:
https://github.com/EsotericSoftware/spi ... .java#L597
Two slots is slightly more efficient since a map lookup is O(1), but you will never have enough slots to make DrawOrderTimeline slow. However on some runtimes the "map" lookup is actually an O(n) search through an array. Either way, this will never be a bottleneck in your application. 🙂

@Nate ,I have been updated. but there are still "error exporting" problems..

Very nice.

I'm a bit confused by the implementation.
Are alternate draw orders (slot arrays) being built and stored in Animation objects on load time? Or is the original draw order modified based on the offset values when Animation.Apply is called? Or an alternate one is built on Apply?

That's great!

@Nate I have been updated to v5.010 , the problems is fixed!!

Thanks you~

Oh, I get it now. An array of ints is built and stored in the animation when then json is loaded. Then the skeleton's array of slots is reordered based on the stored array of ints on Apply.

Is anyone using libGDX and using AnimationState? I have a possible AnimationState quirk I'd like to confirm that interacts with draw order.

(also confirm if the recent changes to the draw order timeline loader is working correctly?)

Yes, DrawOrderTimeline has to use ints and then reorder the skeleton's draw order. It can't store a list of Slots because the DrawOrderTimeline is stateless and Slot is specific to a Skeleton. It could store a list of SlotDatas, which aren't Skeleton specific, but then it has to look up the Slot in the Skeleton, so using indexes is better.

I'm happier with the draw order loader code now. My first go at it had some problems. It is still pretty hairy, but I wanted to avoid storing ALL the slots in the JSON/binary for every draw order key. The JSON isn't very concise, but the binary is (just two ints (slot index and offset) for each draw order change). I might rename "offsets" to "changes" in the JSON.

I see, I see.

I was having a hard time understanding what the new code was trying to do so I don't really know what's up with it. Anyway. No rush.

I'll just keep using the old one which is working fine, I guess except it was breaking for that other guy.

EDIT: Working fine now. The offset export format/numbers changed (in case anyone's reading this out of context.)