Hi, we have found a bug with draw order. I’ve edited the original post to include the fix.
The change is on line 82. instead of #images we are using self.group.numChildren.
This bug reproduced when we had a hidden attachment that was suppose to be the back most image in the draw order but when it was added it was not pushed back properly.
Also we are not yet supporting key draw order which is a new feature in spine which we haven’t even tested or used…
thanks, gtt. I will update mine…this could fix an issue that
I was having.
thanks,
Dale
You definitely should consider forking the runtime on github, and making these changes into bite-sized chunks and send pull requests to Nate (the author of Spine). I’ve done some changes myself and he’s very welcoming, as he’s mostly spending his time on other runtimes and Spine itself these days.
Thanks for these though, I’ll be sure to test them out!
A question, though: Is :rotate :scale etc really faster than setting the properties? What sort of speed differences are we talking about?
Is there any way you can share a complete version of this? I am trying to get spine to work with image sheets. Also, how are you handling multiple resolutions? @2x and @4x?
thanks,
Dale
Hi Dale,
to handle multiple resolutions, make sure you check the ‘identical layout’ box in autoSD, which should enable you to use Corona’s built-in multiresolution support. Other option - which allows for different layouts and thus less textures - is to ditch the Corona side of things completely and just manually load the correct sheet and script according to the resolution, eg:
if ( display.pixelWidth / display.actualContentWidth ) \> 0.8 then sheetData = require("sheet@2x") sheetImage = graphics.newImageSheet("sheet@2x.png",sheetData:getSheet()) else sheetData = require("sheet") sheetImage = graphics.newImageSheet("sheet.png",sheetData:getSheet()) end
The 0.8 being the same ratios as corona’s config uses.
For loading spine images from imagesheet, a more complete (but a bit simpler) example would be:
local json = spine.SkeletonJson.new() skeletonData = json:readSkeletonDataFile(filename) animation = self.skeletonData:findAnimation(animation) skeleton = spine.Skeleton.new(skeletonData) function skeleton:createImage(attachment) local frameIndex = sheetData:getFrameIndex(attachment.name) return display.newImageRect(group, sheetImage, frameIndex, attachment.width,attachment.height) end skeleton:setToSetupPose() skeleton:updateWorldTransform()
The technique above by gtt extends this approach a little bit, allowing for quicker changes of the images through the Corona sprite system.
Hope this helps,
Matias
Is there any reason that you didn’t include this?
spine.AnimationStateData = require “spine-lua.AnimationStateData”
spine.AnimationState = require “spine-lua.AnimationState”
Just wondering.
Thanks Matias,
I was able to get it working with gtt’s system. I set up my spine character using the low res images and Corona is swapping out to the @2x, @4x as expected.
I am a little nervous using a new spine.lua as opposed to Nate’s just because I don’t know what I don’t know…know what I mean?
But it’s working, animation, image sheets, resolution, and skin swapping…woo hoo!!
Thanks, Dale
Happy to hear it works for you!
We are also releasing a game using our module soon. We are quite confident in this code as it’s really not touching the core Spine lua runtime and the code we changed is merely the code binding the image data created by the core lua runtime to Corona images. This seperation by Nate enabled us to manipulate only the part that links things to Corona which is as you can see a single loop that runs over all the slots after they’ve been computed by the generic lua runtime.
Not sure what these are:
spine.AnimationStateData = require “spine-lua.AnimationStateData”
spine.AnimationState = require “spine-lua.AnimationState”
I’ll look them in the original library not sure what they are used for…
@matias9, yes using the translate, scale, rotate function is much faster in Corona just read the Performance 101 tips (#2)
http://forums.coronalabs.com/topic/15165-tips-optimization-101/
Read the conversation about tests people have ran on this…
So I think this by itself is worth the change but you also get to work with the new sprite API and reduce a lot of image mangling + the support for dynamic resolution but that by itself can be done with the original runtime (just override the createImage and load your images from a sheet)
btw, do you know how to get the world position of a bone?
thanks,
Dale
Hi, we have found a bug with draw order. I’ve edited the original post to include the fix.
The change is on line 82. instead of #images we are using self.group.numChildren.
This bug reproduced when we had a hidden attachment that was suppose to be the back most image in the draw order but when it was added it was not pushed back properly.
Also we are not yet supporting key draw order which is a new feature in spine which we haven’t even tested or used…
thanks, gtt. I will update mine…this could fix an issue that
I was having.
thanks,
Dale
Has the official runtime been updated with these fixes?
[quote name=“richard9” post=“207435” timestamp=“1380545151”]Has the official runtime been updated with these fixes?[/quote] As far as I’ve seen the have not been added unfortunately.
Okay, I’ve replaced the Esoteric code with this, and it works great as far as supporting TexturePacker and ImageSheets.
However, all skeletons are coming in scaled quite large (I have to set xScale and yScale to 0.25 for the size to fit). So I’m guessing when you work with Spine itself, you have to use the (normal) assets and not the @4x assets. Blargh!
Thanks to everyone who contributed to this thread. It’s really made Spine somewhat usable
Hi guys, great work! I’ve merged the changes into the official runtime. Is that ok, gtt? I fixed a few bugs, eg typos that check the wrong variable, etc.
I’ll be implementing keyable draw order, events, and bounding boxes soon. Edit: done.
Thanks Nate! 
Has the official runtime been updated with these fixes?
[quote name=“richard9” post=“207435” timestamp=“1380545151”]Has the official runtime been updated with these fixes?[/quote] As far as I’ve seen the have not been added unfortunately.
Okay, I’ve replaced the Esoteric code with this, and it works great as far as supporting TexturePacker and ImageSheets.
However, all skeletons are coming in scaled quite large (I have to set xScale and yScale to 0.25 for the size to fit). So I’m guessing when you work with Spine itself, you have to use the (normal) assets and not the @4x assets. Blargh!
Thanks to everyone who contributed to this thread. It’s really made Spine somewhat usable
Of course it’s OK!! Thanks Nate this is wonderful! we are back to the official runtime!