Excellent news, thanks Paul. I hadn't realised the power of combining Spriter with AppGameKit until a couple of months ago, and it has breathed new life into an old project. I have racing animals with character and cartoonesque realism
Quote: "Alternatively this could be supported externally with something like FixSpriteToSkeleton supplying a bone name/ID"
This is a good solution for many reasons.
Firstly we can add sprites dynamically to the character.
Secondly, we can "replace" sprites by scaling the image it is replacing to almost 0 or setting its z-order to the back.
Thirdly (if this works) we can attach a physics-enabled kinematic sprite to detect collision.
There is another workaround for this once scaling and Z-order are implemented. This allows us - if the model is suitable - to scale down and move to the back any sprites that should not be visible. It won't work in all circumstance but these capabilites alone are a huge leap forward.
My points probably raise a couple of challenges to implement, test or clarify that they won't be possible:
Z-order of the attached sprite within the Spriter skeleton. Will this be able to be set? For example, a weapon in the rear hand will need to be between arm and body. Selecting the bone to attach to is probably the solution already.
Empty bones. Will an empty bone be able to be loaded, so that a sprite can be attached later.
Can attached sprites be physics-enabled. It makes sense that only kinematic sprites would work, as others will interfere with setting the skeleton position (which is a different method to sprite position). The workaround here is to manually follow the character with another sprite, but this would limit following local movement and rotation.
I'm happy to be a beta-tester if you need anyone.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt