Hello, I'm not sure if I'm entirely correct with this, but, I do not use this property personally, and I've actually never had this issue before that I'm about to mention:
After the HandleArtReady is called on a APhysicsObject or CitrusSprite, if I wanted a flipped image, I would just write: sa.scaleX = -1 ( sa being a reference to the StarlingArt instance of that object )
So now inside StarlingArt.as, in the update loop, there is:
if (_citrusObject.inverted) {
if (scaleX > 0)
scaleX = -scaleX;
} else {
if (scaleX < 0)
scaleX = -scaleX;
}
In my scenario, "inverted" is "false", so in the normal StarlingArt loop, it's running the code in the bottom section, and flipping it back from my -1 to +1, so by default, without using inverted it is impossible to set a negative value, without this "inverted" property ( unless you flip the Starling Image directly via say, ( view as image ).scaleX = -1 ).
Shouldn't the "inverted" property just have a "setter" function, that flips it on demand rather than having constant code running in the StarlingArt.as update function?
Hello, I'm not sure if I'm entirely correct with this, but, I do not use this property personally, and I've actually never had this issue before that I'm about to mention:
After the HandleArtReady is called on a APhysicsObject or CitrusSprite, if I wanted a flipped image, I would just write: sa.scaleX = -1 ( sa being a reference to the StarlingArt instance of that object )
So now inside StarlingArt.as, in the update loop, there is:
In my scenario, "inverted" is "false", so in the normal StarlingArt loop, it's running the code in the bottom section, and flipping it back from my -1 to +1, so by default, without using inverted it is impossible to set a negative value, without this "inverted" property ( unless you flip the Starling Image directly via say, ( view as image ).scaleX = -1 ).
Shouldn't the "inverted" property just have a "setter" function, that flips it on demand rather than having constant code running in the StarlingArt.as update function?