* Fix android-specific rotation issue. bone->arotation == NaN, in some specific cases during update bones, cause squared value can been very smoll but still negative anyway and create NaN value
* Fix crash at spSkeletonData_dispose() while handling problems in skeleton in SkeletonBinary/SkeletonJson.
Use increase counts instead directly put counts value for avoid problems at early dispose vectors
* additional commit for prev revision
This pull request improve the loading of binary skeleton so that there is no crash in case of attachment problems.
Essentially, it will have the same behavior as for JSON skeleton, just returning NULL, and you can print pSkeleton->error to the output for the debug purpose.
The functions spSkeletonBinary_create() and spSkeletonJson_create() both use spAtlasAttachmentLoader, which creates attachments in its _spAtlasAttachmentLoader_createAttachment().
This function can return NULL in case of any problems with the atlas regions also setting internal error1,error2 to "Region not found: ", region_path
In case of SkeletonJson.c, there is a check for attachment != NULL after calling spAttachmentLoader_createAttachment().
However, unfortunately, there is no such check for SkeletonBinary.c, and if the region is not found, there is simply a crash deep inside the spine lib.
I fixed it like this
Currently, all calls to spAttachmentLoader_createAttachment() in SkeletonBinary.c are located inside the spSkeletonBinary_readAttachment() function, which is convenient. It is possible to check for the validity of the attachment after each _createAttachment() call. We can use
if (!attachment)
return NULL;
In fact, the problem with the attachment can only be in three cases inside spSkeletonBinary_readAttachment()
case SP_ATTACHMENT_REGION:
case SP_ATTACHMENT_MESH:
case SP_ATTACHMENT_LINKED_MESH:
But for the sake of consistency, it may be worth checking the other four cases:
SP_ATTACHMENT_BOUNDING_BOX:
SP_ATTACHMENT_PATH:
SP_ATTACHMENT_POINT:
SP_ATTACHMENT_CLIPPING:
(I do attachment check here, but maybe we can just "trust" that the attachment is always valid in this cases).
Now that spSkeletonBinary_readAttachment() can return NULL instead of crashing, so go on and fix the next function - spSkeletonBinary_readSkin()
Here, we also check the attachment for validity in this code 'for (i = 0; i < slotCount; ++i)'.
Unfortunately, we cannot use 'continue' inside the loop here, as it is done in SkeletonJson.c, as we cannot move 'input->cursor' to the beginning of the data for the next slot. Here, we can only exit using return NULL, which generally suits us
And finally, in the function spSkeletonBinary_readSkeletonData(), there are only two calls to spSkeletonBinary_readSkin() - one for the default skin and another inside the loop for other skins.
Here, you can apply a check 'if(self->attachmentLoader->error1)', and in case of problems, clear the data by spSkeletonData_dispose() and exit with return NULL; similarly to how it is done below for errors "Skin not found: " and "Parent mesh not found: ".
Thus, there will be no crash inside spine lib in case of attachment problems. Instead, NULL will be returned when calling spSkeletonBinary_readSkeletonData(), which the game engine can recognize and output the error message from pSkeleton->error in the output.
This will help understand why my wonderful spine animation is not loading.
