• RuntimesBugs

  • Updating an empty animation causing a mod by 0 in spine-cpp

    anglais

Hello Spine team,

I am implementing spine-cpp version 4.2 in a custom engine, and I believe I'm encountering a runtime error.

We are using AnimationState::setEmptyAnimations(0.0f) to immediately stop playing all animations and return to the setup pose in certain cases.

Shortly after setting the animation to empty, we experience a crash after we update the object with AnimationState::apply when we get to AnimationState::queueEvents:

void AnimationState::queueEvents(TrackEntry *entry, float animationTime) {
	float animationStart = entry->_animationStart, animationEnd = entry->_animationEnd;
	float duration = animationEnd - animationStart; // <<- Can be 0 for an empty animation?
	float trackLastWrapped = MathUtil::fmod(entry->_trackLast, duration); // mod by 0 occurs here, crashes here

I think it makes sense that the duration of the animation is 0, as the documentation mentions that setEmptyAnimation creates an animation with a duration of zero specifically :
https://en.esotericsoftware.com/spine-api-reference#AnimationState-setEmptyAnimation

In this case, should AnimationState::queueEvents not be calling in AnimationState::apply when the duration is 0? Or should queueEvents early out?

Thanks for your help!

Related Discussions
...

In other languages (eg Java) entry.trackLast % duration will give NaN without any errors. That is expected and in that case event.time < trackLastWrapped is always false. The rest of the method is still executed.

In C/C++ fmod with 0 results in NaN and a domain error flag is set. It seems you have configured your floating point environment to raise an exception for domain errors. You could disable this eg feenableexcept(0);. This may be a good idea, as there could be other scenarios in the Spine Runtimes that allow NaN in computations when the end result is the same as it would be with a special case.

My colleague Mario is out this week. When he gets back he can weigh in on how he thinks it is best to handle this.

Thanks for the fast reply Nate!

We'll disable the exception if needed, though we do like to keep a very strict level of error checking configured in our code base whenever possible.

Let me know if I can provide any other information to help out.

7 jours plus tard

Awesome, thank you so much once again.
I'll follow the issue.

This is now fixed in the 4.2 branch. Could you tell me what compiler you were using with what flags?

7 jours plus tard

Hi Mario!
Sorry for the delay in my reply.
I downloaded and tested the updated runtime, and this fixes the issue for us! Thanks for the fast fix.

Unfortunately I'm not able to provide compiler information due to company policy. Please let me know if I can help in any other way.