• Runtimes

  • Swift/SpriteKit Runtimes

    anglais

So, I've reached a place where I'm stepping back and re-evaluating where I want to go with my personal dev of SpriteKit Runtimes.

If you've followed my posts so far, claybear39 and I have cobbled together some fixes and adaptations to Michael Redig's SGG_SKSpineImport libraries that allow them to be used in current versions of Xcode with Swift (using the bridging headers).

Right now I'm trying to implement IK constraints in SGG_SKSpineImport because they are not already in either of the two libraries that are for SpriteKit:
mredig/SGG_SKSpineImport
simonkim/spine-spritekit

I'm at a point of no return. I'm having to make significant amounts of new code in the SGG classes to implement missing features. Both of these libraries are coded in Obj-C not Swift. They do work fine with Swift, but I'm not enjoying going back to Obj-C to add functionality.

Before I scrap my current work and jump in with making my own Swift/SpriteKit Runtimes I'd like to know a few things from the community and from the developers at Esoteric Software.

  1. EsotericSoftware Developers: Do you have active plans for an official Swift/SpriteKit Runtime? If so can you share an estimated date of completion?

  2. Esoteric: Do you have any pseudo-code written up for the runtimes? If so, would you be willing to share that with me? I'd like to understand the code better if I'm going to make a new Runtime library.

  3. Community: What interest level is there? I've noticed a few people (2-5) that have responded to my previous posts or posted similar topics. If you are interested in Swift/SpriteKit Runtimes and haven't yet said anything, add a comment.

I'd like to have Swift Runtimes for a variety of reasons. I'd like to work with the developers and the community as everyone is interested and able. I plan to post the finished results to gitHub so that anyone can use them. Let me know how you'd like to help if you're able.

Related Discussions
...

What is the issue with IK constraints? These are implemented in the generic runtime (eg, spine-c). When extending the generic runtime, you just need to implement rendering. There is not anything that needs to be done for IK for rendering. It sounds like you are writing a runtime from scratch? This is going to be a lot more work.

The problem with SpriteKit is likely that rendering images requires positioning rectangles by setting their scale, rotation, and translation. Is that right? If so it means no meshes and no non-uniform scaling (unless the attachment is aligned with the bone). If you are ok with these limitations, it should be perfectly possible to implement rendering using SpriteKit. Other runtimes do this, such as spine-corona and the flash package in spine-as3 (example).

We would like to add support for additional runtimes. At the top of the list is Unreal Engine, but just after that is SpriteKit. Sorry, I'm sure you'd prefer SpriteKit first, just being honest. UE is quite big and popular, but also SpriteKit not being able to support meshes or non-uniform scaling reduces it's value as a runtime for Spine to support.

It's quite hard helping everyone using Spine on these forums and emails, fixing bugs, implementing new features, and still finding time to add new runtimes. We are doing it all, it's just a matter of time. I'm afraid I really can't say when. Until then, if you'd like to work on a SpriteKit runtime, we are happy to help with any problems you run into.

Hi Nate,

Thanks for the honest responses and the info you've shared. I think this gives me a better plan too. I was considering doing the Runtimes from scratch if needed, but as you've stated it is a lot of extra work. So thanks for sparing me that 🙂 Previously I was a bit frustrated because I felt like I needed to do that extra work, but it sounds like I don't.

It sounds like I need to try the generic c official runtimes and implement the SpriteKit for the sprite renderer.

Don't worry about doing UE4 first - I understand your priorities.

When you discuss the SpriteKit problem as "rendering images requires positioning rectangles by setting their scale, rotation, and translation," I'm guessing this is as opposed to other engines and frameworks that allow for 2D meshes to be rendered similar to how they are in Spine or (in 3D in Blender/Max/Maya). If that's the case, there may be a solution to this problem with SceneKit - but I'll have to double check on that.

Please share anything else I may need to know about what's needed in the rendering engine to make mesh deformation and non-uniform scaling work, and I'll see what I can find in SceneKit and report back here.

spine-sfml is the smallest example of how to use spine-c:
https://github.com/EsotericSoftware/spi ... e-sfml.cpp
This shows how the vertices are computed by spine-c, then displayed by describing vertex data (x, y, u, v, color for each vertex). If you need to position attachments as rectangular images by setting their SRT, then you'll can look at spine-corona or spine-as3. That works like this:

First the attachment offset. The attachment offset x and y are a translation relative to the bone world position. The translated point is the center of the attachment. The attachment offset rotation and scale uses the center of the attachment as the origin. Next the attachment is transformed by the bone's world SRT. The origin of the scale and rotation is the bone world position.