Hello,
I'm building a GUI using spine. Let's say I have a settings button with the name of btn_settings and have a slot and attachment with the same name.
before the runtime update I was able to get this item's display group with following code:
local btn_settings= skeleton.images[skeleton:findSlot("btn_settings")]
btn_settings:addEventListener("touch", onClickBtnSettings)
well, now with the update this is not working as we are not using the images table anymore; but I wasn't able to find how to get the related mesh or display group. Should I implement a table to keep all the meshes created or are they already being kept in a table?
Thanks
Page 1 of 1
cemleme
5.5 years ago
- cemleme
- Posts: 16
Mario
We now try to batch as many region/mesh attachments into a single Corona Mesh as possible. We store these meshes in a group internal to the Skeleton, called drawingGroup spine-runtimes/spine.lua at master · EsotericSoftware/spine-runtimes · GitHub
Every time you call Skeleton.updateWorldTransform, we clear the drawingGroup, and generate new Mesh instances that we then reattach to the drawingGroup spine-runtimes/spine.lua at master · EsotericSoftware/spine-runtimes · GitHub
Since we are recreating the Mesh instances on which you'd set your event listener on every call to Skeleton:updateWorldTransform, you'd have to re-register your listener after every call to that function.
The old way of giving each attachment its own image was nice for event handling, but was incredibly slow, almost rendering the spine-corona runtime unusable. With the new method of batching multiple attachments into a single Mesh, event handling has become somewhat more complicated, but its now possible to draw a lot more skeletons, especially on mobile.
Every time you call Skeleton.updateWorldTransform, we clear the drawingGroup, and generate new Mesh instances that we then reattach to the drawingGroup spine-runtimes/spine.lua at master · EsotericSoftware/spine-runtimes · GitHub
Since we are recreating the Mesh instances on which you'd set your event listener on every call to Skeleton:updateWorldTransform, you'd have to re-register your listener after every call to that function.
The old way of giving each attachment its own image was nice for event handling, but was incredibly slow, almost rendering the spine-corona runtime unusable. With the new method of batching multiple attachments into a single Mesh, event handling has become somewhat more complicated, but its now possible to draw a lot more skeletons, especially on mobile.
5.5 years ago
-
Mario - Posts: 3035
cemleme
ok...
sooo one way comes into my mind is to create invisible rectangle on top of the related skeleton (easy on rectangles)
self.rectangleSettings = display.newRect( self.group, 0, 0, 60, 60 )
self.rectangleSettings.isVisible = false
self.rectangleSettings.isHitTestable = true
and then update its position according to the related bone after updateWorldTransform
local bone = self.skeleton:findBone(boneName)
self.rectangleSettings.x = bone.worldX
self.rectangleSettings.y = bone.worldY
self.rectangleSettings:toFront()
is there a flaw on this approach?
thanks
sooo one way comes into my mind is to create invisible rectangle on top of the related skeleton (easy on rectangles)
self.rectangleSettings = display.newRect( self.group, 0, 0, 60, 60 )
self.rectangleSettings.isVisible = false
self.rectangleSettings.isHitTestable = true
and then update its position according to the related bone after updateWorldTransform
local bone = self.skeleton:findBone(boneName)
self.rectangleSettings.x = bone.worldX
self.rectangleSettings.y = bone.worldY
self.rectangleSettings:toFront()
is there a flaw on this approach?
thanks
5.5 years ago
- cemleme
- Posts: 16
Mario
No, this is a very good approach. You could also add bounding boxes to your skeleton in the Spine Editor then use the SkeletonBounds class to get the bounding boxes after updateWorldTransform. However, in that case you'd have to do hit detection yourself, so your approach is likely easier to implement.
5.5 years ago
-
Mario - Posts: 3035
Mark topic unread
• Page 1 of 1
Return to Runtimes
- All times are UTC