sprite shimmy

Getting Started Newbie Questions
#1

I REALLY hope someone out there can help because I’m about ready to lose my mind.  I’ve had no end of problems with sprite animations, many of which were my fault, but I don’t see how this one can be.

I finally managed to get sprite animations to work perfectly on the simulator.  Unfortunately, when I try it on an iPad looping sprites have a slight shimmy, as if they’re wiggling in place.  At first, the shimmy was very pronounced.  I made some adjustments, and the shimmy is better, but still there slightly.

I’m using TexturePacker, and no matter what I try I can’t correct this problem.  Originally, I was using TexturePacker’s code, which specifies the exact coordinates of every frame on the sprite sheet.  That caused the worse shimmy of all.  I recreated the sprite sheet in TP and added a 5 pixel buffer (extrude).  I then coded it the standard way, setting the frame dimensions and number, and that helped a lot.  But not enough.  I’ve tried 1, 2, 3, 5, 8, 10, 25 pixel buffers.  No help.

Does anyone have any thoughts?

#2

Hi @mysterycaper,

I assume the part described in the following guide is something you took into account, whether manually or through TexturePacker’s output?

https://docs.coronalabs.com/guide/media/imageSheets/index.html#trimming-notes

I might need to see how your project is set up, if you could send me a simple test case with the real sprites and the setup you’re seeing the shimmy. Email is brent (at) coronalabs (dot) com.

Thanks!

#3

Thanks so much for your reply and offer to help, Brent.  I sent you an email just now with more details.  I look forward to your reply.

#4

Hi @mysterycaper,

Can I post back my findings (and your sprite sheet) here, so that the conversation may be useful to others reading it? Or are the images proprietary material you need to protect?

Brent

#5

Please switch to the “Advanced settings” in TexturePacker and click on “> Sprites”. 

There’s an option called “Common divisor” - try values 2, 4, 8 

This should stop the problem.

The problem is - as I see it - that Corona rounds the pixel values.

#6

Hi Brent,

If you think it would be useful to others, then sure, you can post your findings and use the sprite sheet as part of your example.  

#7

Hi Andreas,

Thanks for your reply.  I’ll give that a try.

#8

Andreas,

I feel like it has something to do with rounding pixels too.  Unfortunately, changing the values as you suggested didn’t repair the problem.  Under common divisor, I tried 2 (for x & y), 4 & 8.  With x & y set to 4, I also changed the extrude from 1 to 4.  Still no change.  Do you think there might be another setting that has to be applied along with the common divisor?

#9

Hi @mysterycaper,

Try out the attached project which I tossed together. It just uses the “basic” setup.

A few things I did (some of which you might have done but I can’t recall everything I changed as I went along):

  1. I set “sheetContentWidth” and “sheetContentHeight” in your image sheet setup (3360 x 2832).

  2. I set each frame to be 1120 x 708.

  3. I set the Corona content area size to 1242 x 2208… not a requirement, but because your image sheet (and its frames) are so large, I wanted to see the entire sprite on the screen without scaling it down.

When I run this on an iPad Air (obviously a “retina” screen), I don’t see any shimmy/jitter, and I really tried to inspect it closely in terms of the polygon-shaped border you drew around the fire… since that part doesn’t actually animate, it’s easier to watch for shimmy on that part.

Now, because the content area was made so large, it’s possible that the shimmy you saw before still occurs, but it’s so small (fractionally reduced because of larger content area) that I’m just not seeing it. I suppose the way to test this would be to use a smaller image sheet/frames which you know are unified and aligned perfectly on the image file side of things.

What I did notice was, on the iPad Air, a tiny bit of bleed on the top edge of the sprite which it’s picking up from neighboring frames. However, that could easily be solved by just adding 2-4 more empty pixels of padding around each frame in the image sheet itself, and then making sure the new frame size and sheetContentWidth/Height on the Corona side is updated to match that.

Brent

#10

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.

#11

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.

#12

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.

#13

Hi @mysterycaper,

I assume the part described in the following guide is something you took into account, whether manually or through TexturePacker’s output?

https://docs.coronalabs.com/guide/media/imageSheets/index.html#trimming-notes

I might need to see how your project is set up, if you could send me a simple test case with the real sprites and the setup you’re seeing the shimmy. Email is brent (at) coronalabs (dot) com.

Thanks!

#14

Thanks so much for your reply and offer to help, Brent.  I sent you an email just now with more details.  I look forward to your reply.

#15

Hi @mysterycaper,

Can I post back my findings (and your sprite sheet) here, so that the conversation may be useful to others reading it? Or are the images proprietary material you need to protect?

Brent

#16

Please switch to the “Advanced settings” in TexturePacker and click on “> Sprites”. 

There’s an option called “Common divisor” - try values 2, 4, 8 

This should stop the problem.

The problem is - as I see it - that Corona rounds the pixel values.

#17

Hi Brent,

If you think it would be useful to others, then sure, you can post your findings and use the sprite sheet as part of your example.  

#18

Hi Andreas,

Thanks for your reply.  I’ll give that a try.

#19

Andreas,

I feel like it has something to do with rounding pixels too.  Unfortunately, changing the values as you suggested didn’t repair the problem.  Under common divisor, I tried 2 (for x & y), 4 & 8.  With x & y set to 4, I also changed the extrude from 1 to 4.  Still no change.  Do you think there might be another setting that has to be applied along with the common divisor?

#20

Hi @mysterycaper,

Try out the attached project which I tossed together. It just uses the “basic” setup.

A few things I did (some of which you might have done but I can’t recall everything I changed as I went along):

  1. I set “sheetContentWidth” and “sheetContentHeight” in your image sheet setup (3360 x 2832).

  2. I set each frame to be 1120 x 708.

  3. I set the Corona content area size to 1242 x 2208… not a requirement, but because your image sheet (and its frames) are so large, I wanted to see the entire sprite on the screen without scaling it down.

When I run this on an iPad Air (obviously a “retina” screen), I don’t see any shimmy/jitter, and I really tried to inspect it closely in terms of the polygon-shaped border you drew around the fire… since that part doesn’t actually animate, it’s easier to watch for shimmy on that part.

Now, because the content area was made so large, it’s possible that the shimmy you saw before still occurs, but it’s so small (fractionally reduced because of larger content area) that I’m just not seeing it. I suppose the way to test this would be to use a smaller image sheet/frames which you know are unified and aligned perfectly on the image file side of things.

What I did notice was, on the iPad Air, a tiny bit of bleed on the top edge of the sprite which it’s picking up from neighboring frames. However, that could easily be solved by just adding 2-4 more empty pixels of padding around each frame in the image sheet itself, and then making sure the new frame size and sheetContentWidth/Height on the Corona side is updated to match that.

Brent