Update to spine-c 4.2

[badlogic]

trafficstars

As per the discussion here: https://forum.defold.com/t/how-to-update-extension-spine-runtime-to-4-2-beta/76325

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
• 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.

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.

[britzl]

I'm looking into it. We prebuild the spine lib per platform, and we have a much more convenient pipeline to do so now than what can currently be seen in this repo. I'll create a separate PR to merge an updated build script, that you can then use in your PR.

[badlogic]

Great, thank you!

On Thu, May 2, 2024, 15:42 Björn Ritzl @.***> wrote:

I'm looking into it. We prebuild the spine lib per platform, and we have a much more convenient pipeline to do so now than what can currently be seen in this repo. I'll create a separate PR to merge an updated build script, that you can then use in your PR.

— Reply to this email directly, view it on GitHub https://github.com/defold/extension-spine/pull/167#issuecomment-2090533769, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5QBANDU2PQVZG64S7Y7LZAI7D5AVCNFSM6AAAAABG36GF2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJQGUZTGNZWHE . You are receiving this because you authored the thread.Message ID: @.***>

[britzl]

@badlogic there's now a utils/build_libs.sh:

https://github.com/defold/extension-spine/tree/main/utils

This script needs a version of our command line tools (bob.jar, download from here: https://github.com/defold/defold/releases/tag/1.8.0). It will automatically rebuild the spine-c code into libraries per platform, and put them in defold-spine/lib. You should also run the utils/build_plugins.sh script to rebuild the editor plugin.

> export BOB=bob.jar && ./utils/build_libs.sh
> export BOB=bob.jar && ./utils/build_plugins.sh

[britzl]

I've updated this PR with pre-built libs and plugins using bob 1.8.2 alpha

[badlogic]

Sorry for the super late reply. Thank you for the work on the build system! I've amended the PR with a minor commit that:

1. Updates the spine-c sources to include a few post 4.2 bug fixes
2. Fix a compilation error in comp_spine_model.cpp:268. Clang on macOS seems to not like (uint32_t)params.m_UserData;. Fixed by an additional cast (uint32_t)(uintptr_t)params.m_UserData;. Iffy, as this code goes from a 64-bit pointer to a uint32_t
3. Updated libraries, build using your build scripts

This all works as intended in Defold 1.8.2-alpha, both in editor and when running the example project stand-alone.

However, building the native library for Android as part of build_libs.sh fails. CLI output:

Build Remote Engine...
build-artifacts: library
Building engine...Wrote debug upload zip file to: /Users/badlogic/workspaces/extension-spine/build/upload.zipJun 05, 2024 1:55:47 PM com.defold.extender.client.ExtenderClient log
INFO: Sending async build request to https://build.defold.com/build_async/arm64-android/60433e9a00c87fbae67cb57efa285bd7f0a8dbab
Jun 05, 2024 1:55:47 PM com.defold.extender.client.ExtenderClient log
INFO: Async build request was accepted as job job14367876048211105651
Jun 05, 2024 1:55:52 PM com.defold.extender.client.ExtenderClient log
INFO: Waiting for job job14367876048211105651 to finish
Jun 05, 2024 1:55:52 PM com.defold.extender.client.ExtenderClient log
INFO: Checking job result for job job14367876048211105651
Jun 05, 2024 1:55:53 PM com.defold.extender.client.ExtenderClient log
INFO: Job job14367876048211105651 did not complete successfully. Writing log to /Users/badlogic/workspaces/extension-spine/build/arm64-android/log.txt

Contents of the log file:

com.samskivert.mustache.MustacheException$Context: No method or field with name 'env' on line 1
	at com.samskivert.mustache.Template.checkForMissing(Template.java:344)
	at com.samskivert.mustache.Template.getValue(Template.java:247)
	at com.samskivert.mustache.Template.getCompoundValue(Template.java:260)
	at com.samskivert.mustache.Template.getValue(Template.java:244)
	at com.samskivert.mustache.Template.getValueOrDefault(Template.java:292)
	at com.samskivert.mustache.Mustache$VariableSegment.execute(Mustache.java:872)
	at com.samskivert.mustache.Template.executeSegs(Template.java:170)
	at com.samskivert.mustache.Template.execute(Template.java:137)
	at com.samskivert.mustache.Template.execute(Template.java:128)
	at com.defold.extender.TemplateExecutor.execute(TemplateExecutor.java:19)
	at com.defold.extender.Extender.<init>(Extender.java:266)
	at com.defold.extender.Extender.<init>(Extender.java:295)
	at com.defold.extender.AsyncBuilder.asyncBuildEngine(AsyncBuilder.java:100)
	at com.defold.extender.AsyncBuilder$$FastClassBySpringCGLIB$$3a887347.invoke(<generated>)
	at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:783)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:753)
	at org.springframework.aop.interceptor.AsyncExecutionInterceptor.lambda$invoke$0(AsyncExecutionInterceptor.java:115)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)

I've tried this a few times, thinking that maybe the build server had an intermittent issue, but it never worked.

Other than that, I think this should be good to go!

[tarragonfly]

Any updates @britzl? It's a been awhile.

[britzl]

Any updates @britzl? It's a been awhile.

I agree. I'm sorry for the delay. I will look into it now.

[britzl]

I've rebuilt the libs and plugins using beta of bob.jar for 1.9.0 using build-stage.defold.com

[badlogic]

Cheers!