[Android/Spine] Error with removeSelf, can it cause this sim/device inconsistency?

Solar2D Android
#1

I made a post in the Spine forum, but since the issue seems to be on Corona’s side, I wanted to give it some mainstream attention as well.  Nate from Esoteric says the spine code in use seems fine.  My spine forum post can be found here and the same post on Esoteric forums here.  My Corona version is 2013.2100.

In brief:

I am using 3rd party tool Spine to animate game characters.  Running in the sim, most everything runs correctly.  There are a few attack animations that will not play at all.  However, there are NO logged errors or warnings, memory issues, or indication that there is any problem (other than the non-working animations).

When running on devices, there are multiple issues with animations.  Idle animations work randomly, some animate some don’t. There is no consistency as to which work based on unit types, positions, etc even between turns. Some character assets do not appear at all, or disappear after a non-idle animation. Memory use slowly continues to increase as the game plays the animations.

The device logs show this runtime error excessively spammed to the console:

I/Corona (20725): Runtime error
I/Corona (20725):
I/Corona (20725): stack traceback:
I/Corona (20725):     [C]: in function ‘removeSelf’
I/Corona (20725):     …-Brawl(default)\Monster-Brawl\spine-corona\spine.lua:110: in function ‘updateWorldTransform’
I/Corona (20725):     …onster-Brawl(default)\Monster-Brawl\modules\unit.lua:264: in function ‘updateAnim’
I/Corona (20725):     …Monster-Brawl(default)\Monster-Brawl\gamemanager.lua:671: in function
<…Monster-Brawl(default)\Monster-Brawl\gamemanager.lua:665>
I/Corona (20725):     ?: in function <?:218>

(If you would like to see the originating code, please see my previous post.)

Has this type of removeSelf behavior been seen before? What types of problems can cause removeSelf to error?  Why am I seeing good animations and not receiving errors in the simulator?  It almost feels like it is trying to remove a non-existing object. 

Looking at the API, I notice:

display.remove( object )

This is the same as calling object:removeSelf(), but will first check if the object exists before attempting to remove.

So removeSelf does not check for nil. Could this be the issue? Any insight into removeSelf is appreciated.

#2

In another post, Rob Miracle says:

When ever I hear “It works in the simulator but not the device”, it tells me that there is a 90% chance you have a file name problem.  Devices are case sensitive, Windows and OS-X are not.

Boy was he right.

Apparently, Git (on Windows at least) is also not case sensitive.  Even if filename cases have been corrected, if they are pushed to the repository, it will not recognize the change and use the pre-existing case condition.  This caused some of our image assets that Spine was looking for appear to be ‘missing’ and not allowing the app to create and manipulate those images.

#3

It’s really not the “simulator” that’s case insensitive on OS-X or Windows.  it’s the operating system itself.   Which ironically, the underlying Unix OS on OS-X is case sensitive, but the filesystem is not and the OS-X engine sitting on top of the Unix kernel is not case sensitive.  Window’s is also not case sensitive.

Rob

#4

Very true, Rob. Thanks for your clarification.

#5

In another post, Rob Miracle says:

When ever I hear “It works in the simulator but not the device”, it tells me that there is a 90% chance you have a file name problem.  Devices are case sensitive, Windows and OS-X are not.

Boy was he right.

Apparently, Git (on Windows at least) is also not case sensitive.  Even if filename cases have been corrected, if they are pushed to the repository, it will not recognize the change and use the pre-existing case condition.  This caused some of our image assets that Spine was looking for appear to be ‘missing’ and not allowing the app to create and manipulate those images.

#6

It’s really not the “simulator” that’s case insensitive on OS-X or Windows.  it’s the operating system itself.   Which ironically, the underlying Unix OS on OS-X is case sensitive, but the filesystem is not and the OS-X engine sitting on top of the Unix kernel is not case sensitive.  Window’s is also not case sensitive.

Rob

#7

Very true, Rob. Thanks for your clarification.