search

jeremyfa / spine-hx

Spine runtime for Haxe automatically converted from the official Java/libgdx runtime
Other
56 stars 15 forks source link

Softness broken due to rounding #29

Closed digibo closed 2 years ago

digibo commented 2 years ago

After investigating an issue with IK Softness, I traced it to the following line:

https://github.com/jeremyfa/spine-hx/blob/cb76a29f55aa2a6fdc7fa2006ce5a8e5f99a53b3/spine/IkConstraint.hx#L287

This rounds to zero in most cases, breaking IKs, if softness is applied.

The rounding isn't present in the official libgdx runtime (link), so my guess is it's added during the conversion. Changing the code to this: var p:Float = MathUtils.min(1.0, sd / (softness * 2)) - 1; fixes the issue. Note that the first param needs to be 1.0 for the Haxe compiler to accept Float as the second param. My guess this is the issue that lead to the rounding being added at some point.

I didn't create a PR, as this seems to be an issue with converting from libgdx and I am not able to get this to properly work on my end. The same conversion/rounding issue may be present in other places. A quick search showed potential issues in AnimationState.hx, but I don't have a test case to confirm:

https://github.com/jeremyfa/spine-hx/blob/cb76a29f55aa2a6fdc7fa2006ce5a8e5f99a53b3/spine/AnimationState.hx#L352 https://github.com/jeremyfa/spine-hx/blob/cb76a29f55aa2a6fdc7fa2006ce5a8e5f99a53b3/spine/AnimationState.hx#L553

jeremyfa commented 2 years ago

Indeed that’s an issue with the converter. I’ll take a look at the converter and see why it does that as soon as I have the bandwidth for that.

Thanks for investigating!

jeremyfa commented 2 years ago

The converter is now fixed and should output the same as what you manually fixed!