How to update extension-spine runtime to 4.2-beta?

wind · March 18, 2024, 12:21am

Hi

When building projects, i got this error:

Skeleton version 4.2.42-beta does not match runtime 4.1

Does anybody know how to update the extension-spine to spine runtime 4.2-beta ?

I’ve tried running ./utils/runtime/build_runtime_lib.sh x86_64-linux on the extension-spine, but the problem still persist

Thank you for the help, have a nice day

AGulev · March 17, 2024, 5:43pm

We are not going to update sine extension to 4.2 any time soon.
You can export from newer Spine for 4.1 in case you don’t use new features.

wind · April 23, 2024, 8:37am

Spine 4.2 stable has been released, the physic on spine 4.2 really is a game changer.

Hopefully it can be used on defold soon

AGulev · April 23, 2024, 8:59am

No, I don’t think it will be added any time soon, unless someone decides to implement it (it’s an open-source extension, so anyone can contribute) or a company that wants to use it decides to sponsor such an update.

I don’t want to create false expectations: internally, our team does not have any plans to do so.

britzl · April 23, 2024, 9:33am

I would really recommend that paying users of Spine reach out to Esoteric Software (the creators of Spine) and request this, perhaps as a support request on their forum: Runtimes - Spine Forum. The Defold Foundation can then work with Esoteric to create such an update.

The other option is if someone is willing to give it a try themselves. We’re happy to provide help if that is the case.

wind · April 24, 2024, 1:16am

in case a company decide to sponsor the update, what kind of sponsor / how much sponsor is needed?

britzl · April 24, 2024, 6:51am

Let’s take a look at the changelog for 4.2. We use the spine-c runtime in Defold:

github.com

EsotericSoftware/spine-runtimes/blob/4.2/CHANGELOG.md#c

# 4.2

## C

- **Additions**
  - Added physics support
    - Added `spPhysicsConstraintTimeline` and `spPhysicsConstraintResetTimeline`
    - Added `spPhysics` to be passed to `spSkeleton_updateWorldTransform()`
    - Added `spSkeletonData_findPhysicsConstraint()` to query a physics constraint by name
    - Added `spSkeleton_findPhysicsConstraint()` to query a physics constraint by name
    - Added `spSkeleton_physicsTranslate()` to translate all physics constraints by some distances in the skeleton coordinate system
    - Added `spSkeleton_physicsRotate()` to rotate all physics constraints by some distances in the skeleton coordinate system
    - Added `spSkeleton::time` to keep track of time for physics simulations
    - See also breaking changes for `spSkeleton_updateWorldTransform()` and the requirement to call `spSkeleton_update()` to advance
      pyhsics each frame.
  - Added `spInheritTimeline`
  - Added [`spTrackEntry::alphaAttachmentThreshold`](http://esotericsoftware.com/spine-api-reference#TrackEntry-alphaAttachmentThreshold)
  - Removed `const` qualifiers where appropriate
  - Added `spTrackEntry_setMixDuration()` to set the mix duration in conjunction with a delay
  - Added `spTrackEntry_wasApplied()` to check if the entry has been applied

This file has been truncated. show original

There’s a few breaking changes (Esoteric loves to break stuff!), but nothing really big. This means that the bulk of the work will be to introduce the new physics support. It’s hard to say how much time would be required to do the update, probably a week, perhaps a bit more. We would charge $80/h for this kind of public development work, which means that for one week (40 hours) the cost would be $3200. Before we commit to anything we’d obviously do a bit more investigation into the new functionality so that we can provide a more accurate cost of development.

We’ve done similar work in the past. For instance the IronSource SDK integration was sponsored by a few studios that needed the integration for their games. Some of the recent Texture Packer work was also partially sponsored by the community.

And of course the Rive integration was paid for and developed in collaboration with Rive.

badlogicgames · April 27, 2024, 7:45am

Hello, Mario from Spine here. We actually don’t break the API, we usually modify the .json and binary format exported from the editor to support new features, like physics. API wise, we may add new APIs, but hardly break existing ones. In this release, there is only 1 breaking change relevant to extension-spine, namely the additional parameter to sp_skeleteon_updateWorldTransforms. The extension doesn’t expose any of the spine-c APIs, so “user land” won’t be affected at all.

I’ll take a look next week and send a pull request once I’ve figured out how things fit together.

I also have a question: is there a technical reason that the binary format is not supported? If not, I’d take a look at adding that capability as well.

britzl · April 27, 2024, 8:51am

Hi Mario. I wrote my comment based on our years of having our own runtime and constantly playing catch up with changes to the json format.

Now that we are using the official c runtime we do not experience as many problems with breaking changes in the data format or APIs.

Mathias_Westerdahl · April 27, 2024, 9:06am

Granted, the better term is ABI.
We frequently experience changes to the file format, where a user updates their Spine version, saves the data, and suddenly it doesn’t work with our current spine runtime.
That’s what we were referring to.

As for supporting binary format, the text format is both good for checking in source control what has actually changed, as well as modifying the content in those cases where the ABI udpated, and it no longer works with our version.

Size-wise, it was not a big loss either.

badlogicgames · April 27, 2024, 9:23am

@britzl and @Mathias_Westerdahl makes sense! I remember your brave attempts to follow our Spine updates with your custom runtime. Glad the pain is not as big anymore with spine-c.

I’ve just created a pull request that updates extension-spine to spine-c 4.2. See

github.com/defold/extension-spine

Update to spine-c 4.2

defold:main ← badlogic:main

opened 09:21AM - 27 Apr 24 UTC

badlogic

+2909 -3456

As per the discussion here: https://forum.defold.com/t/custom-defold-build-for-…android/72804/2 I've updated the `extension-spine` repo to use spine-c version 4.2, which adds support for physics, among other things. Notes: - Users need to re-export their `.spinejson` files from Spine Editor version 4.2 to be compatible. This can be done manually via the editor UI, or by creating a simple Bash/whatever script using the [Spine command line interface](https://en.esotericsoftware.com/spine-command-line-interface) - I have updated the files in `assets/` to Spine version 4.2 and did some clean-up. - Updated the files in `assets/sequence_animation` - Created a Spine project for the `assets/squirrel` asset, renamed `Squirel.spinejson` to `squirrel.json`, and fixed up the file reference in the corresponding scene - Updated the files in `spineboy` - I've updated the `spine-c` sources in `defold-spine/commonsrc/spine` and `defold-spine/include`. I later saw `utils/runtimes/build_runtime_lib.sh` does the same. - I've updated the extension sources where necessary to fix the API breakage. Namely, we need to call `spSkeleton_update(deltaTime)` to advance any physics constraints, and pass an additional parameter to `spSkeleton_updateWorldTransforms()` - I've added a `build.sh` file in the root of the project so I can build the extension "locally" (but still through the Defold build servers) more easily. I've based this on the GitHub workflow. After building the plugin and its dependencies via `build.sh`, all scenes load as expected in the Defold editor. <img width="1728" alt="Screenshot 2024-04-27 at 11 17 25" src="https://github.com/defold/extension-spine/assets/514052/ef9f979d-e9f6-4f22-bdb4-6316bf385b3a"> However, I can not get the main scene to run via `Debug > Start/Attach`, as that triggers a build, which seems to rebuild the plugin, which then complains about duplicate symbols in the linker stage. It appears that spine-c is compiled into both a libspinec.a and the libSpineExt.a files, which the build then tries to link into the final binary. I'm afraid I don't understand Defold's native extension build system enough to know how to fix this. As such, the pull request also does **not** contain any pre-built binaries. I hope that a Defold team member can help me out in that regard, either by fixing up the build or explaining to me how this can be fixed in the future. I'd love to help maintain this going forward, so it would be great to better understand how all this fits together. I'm afraid I was unable to piece things together from the official documentation on the Defold site.

Few caveats as per my PR description. Let’s discuss over on GitHub.