sprite shimmy

Sort of a guess, but the following seems consistent with the information mentioned so far.

Does system.getInfo(“gpuSupportsHighPrecisionFragmentShaders”) return false on the device? If so, then your texture coordinates (after scaling by 1 / 3360 and 1 / 2832, per Brent’s numbers) are only guaranteed (by the GLES spec, e.g. see the “Qualifiers” section here) to land on multiples of 1 / 1024; with high precision the minimum is the more generous 1 / 65536.

Interior pixels should look reasonable, thanks to filtering, but on the edges you might be seeing the effect of the sides in different frames landing at inconsistent offsets. I haven’t seen the shimmy in question, but I can about imagine, if this is the reason.

Anyhow, as I said, this is all conjecture.

Brent,

I want to thank you for taking the time to look at this.  The settings you described were among the things we’ve tried.  We haven’t played with the content area size, but I take it that was more for test purposes.  Honestly, the shimmy is pretty hard to notice and if I hadn’t had the shimmy effect much worse when I first tested it on the iPad I probably wouldn’t even notice it now.  On the affected animations, we have the context of surrounding static images, which helps pick out the movement a little easier.  Even there, it’s hard to see unless you’re looking for it.  We’ll probably employ a few adjustments here or there to help disguise it.

StarCrunch,

I’m no expert - obviously - but your guess sounds right to me.  It definitely seems like it’s landing at slightly inconsitent offsets.  The interior of the animation is always fine.

Thanks again for everyone’s help.  The forums here are excellent, filled with very helpful and considerate folks like yourselves.  If anyone has any other thoughts, we’d love to hear them.  And if we stumble on anything else that might be helpful to others, we’ll be sure to let you know.

Just wanted to give an update to say we got the shimmy problem solved.

Everyone’s input was very helpful, and I really believe the solution came about through a combination of that input.  Andreas’s advice on the common divisor got me looking at the settings again, and I discovered a power of two setting.  That, in conjunction with Brent’s suggestion of adding a 4-pixel extrude, was key.  The final settings that worked for me were:

extrude = 4

common divisor = 4(x) by 4(y)

pot (power of two) = on

Hope if anyone else has this problem, this helps.