That is amazingly weird. The code in the test looks fine. I also went through the shaders of the spine-libgdx runtime for mobile and tested it on a few of my old test devices (HTC Nexus One) and it looked fine. Could you test the vine sample of ours on your devices? That'd rule out an issue with the Spine project of yours.

What Android version are those devices running? My guess is that it might be a JIT bug in Dalvik (those devices probably don't run ART), in which case there's not a lot we can do :/

edit: issue opened by op here [libgdx] Paths not working on old devices · #861

The vine project comes with Spine, in the installation folder. Also here:
spine-runtimes/examples at master

I'm guessing it's a Dalvik bug of some sort, which is unfortunate. The best thing to do would be to narrow down what exactly the problem is. Maybe badlogic has some ideas?

The Android versions of the devices you mentioned are running ART, not Dalvik. Some vendors modify ART (for whatever terrible reason) and the end result is what you see. I'll try to reproduce it with an emulator running those versions, but it's likely the emulator won't reproduce the issue. I don't see any code in PathConstraint that could be responsible for this issue, except for a NaN check (which should work).

Could you try one thing for me: add strictfp to the PathConstraint class, e.g.

public strictfp class PathConstraint {

That may trigger a different JIT route and potentially fix the issue.

I've opened an issue here [libgdx] PathConstraint fails on older ART versions on Android · #865

Then it's bad. strictfp is supposed to work on ART (which 4.1 should use), and ensure that all calculations are performed stricly adhering to the IEEE float standard.

Could you please try the following: replace your copy of PathConstraint.java with this version https://gist.github.com/badlogic/4f517f3a65d25839d27aff01f3dc7965 It's compatible with the latest spine-libgdx runtime from the master branch on GitHub.

If this doesn't work, then I'm out of ideas for now. I tried to reproduce the issue using various emulator setups (Haxm x86, ARM Qemu), but that didn't reproduce the problem.

edit: I've updated both the master branch and the 3.6-beta branch with higher precision code in PathConstraint and other classes. Please give that a try.

Maybe Android borked up int math? :party:

That's not good. I'll try to come up with an easy way for you to help debug the issue (project, test data, etc.) if you are willing. Not being able to reproduce this makes it really hard on our end to fix it. I checked if I could buy one of these two phones, but they aren't sold any longer here.

Hi Mario, huge thanks for helping out!

@zepplondon is working on DeepTown which is one of our games, so I really appreciate you helping us, and this seems like it affects more than two phones, we just don't know which. (we've seen other people posting youtube videos with this)

We are more than willing for any kind of debug that can be done. If you want to we can even setup a remote session with team viewer or whatever you suggest I am online in Skype to provide any info immediately.

Thanks!

offtop:
DeepTown is heavily based on spine, almost everything is animation, and we are having currently enormous amounts of traffic, being #5 in Strategies/Germany ^_^

If you can repro it, debugging comes down to setting up the same example on a bad device and a good one (or desktop) and then stepping through it (or otherwise analyzing the data, could write to a log), comparing values until you pinpoint the discrepancy. Since the results are quite off, the discrepancy should stand out. Unfortunately it's not possible for us to do this, since we can't repro the problem. PathConstraint is a bit of a hairy beast!