spine-ios

We are happy to announce the general availability of spine-ios! Learn more about spine-ios on our blog.

Related Discussions
...
Misaki bu tartışmayı sabitledi.

Very nice! Any plans for doing the same for Android / Compose UI?

    Spoilers!

    Hey, great stuff!

    I'm author of some experimental implementation of Spine2D for Android (for react-native to be specific) - react-native-spine-player.

    First thing which I noticed is that you are chose Java for Android implementation - I'm genuinely curious , why you decided to go with Java instead C++ which can be relatively easily implemented as in my solution?
    Do you think it would perform better than JNI?

    Also - do you have any plans regarding later integration with react-native? I would love to see that!

    Consumers of spine-android will most likely use Kotlin (with a small minority still using Java). The reference Spine Runtimes implementation is spine-libgdx, which is Java based. libGDX is Nate and my game dev library and has been battle tested for almost 15 years on mobile, specifically on Android. As such, we know the ins and outs of Android (or more precisely ART) performance. For most of the stuff happening in spine-android (and spine-libgdx, which is spine-android is built upon) going C++ would not yield any benefits. On the contrary, crossing the JNI bridge is very costly. I.e. having to go through JNI for every class' setters/getter would be much slower in C++.

    The one place where performance would be slightly better is vertex transformations of attachments. But even there, the returns are diminishing. Once we've transformed the vertices of an attachment based on the current pose, we'd have to talk to Android's graphics API, which would require us to push native side float* back into Java land (which incures allocations every frame). The Java solution is pretty much allocation free in the renderer (after a few frames).

    Memory management of native resources on the Kotlin/Java side is also not exactly trivial and there are many foot guns, with which users can shoot themselves.

    TL;DR: for the work loads we have, C++ does not quite give us many benefits compared to ARTs performance, while everything else (exposing the full API, memory management, talking to the graphics API) becomes worse.

    react-native-spine-player is neat btw! You have to draw into an Android Bitmap via Skia, which will eliminate the JNI round trip I talked about above:
    Hau-Hau/react-native-spine-playerblob/main/android/src/main/cpp/spine-android.cpp#L55

    But the downside to this approach is that you now have to composite that Bitmap into your UI, while our approach can more directly render to the underlying rendering surface, so less round tripping through the compositor.

    25 gün sonra
    • Düzenlendi

    Hello!

    We are currently working with Spine animations. The animator provided us with Spine version 4.2 and enabled premultipliedAlpha. In our Android project using the spine-libgdx runtime, the animation displays correctly and handles transparency. However, in our native iOS runtime project, the same animation does not display transparency correctly when premultipliedAlpha is enabled, and the background color shows as black.

    Here are some screenshots of the issue. Could you please help us with this problem? Thank you!

    Effect in the editor:

    Effect on Android:

    Effect on iOS:

    spine file:

    explosion.zip
    504kB

      Shastri

      Thanks for reporting this. I've noticed you already reported the same problem in this issue on our GitHub. The issue you reported is already under our consideration. Mario, who is following the issue is currently unable to respond to you due to some health issues. He will answer to you on the github issue as soon as he is back and operative.

        Davide
        Thank you for the update. I appreciate your attention to this issue. I hope Mario recovers quickly and I’m looking forward to his response once he’s back. Wishing him a speedy recovery!