Stuttering Sprites in Graphics 2.0

Audio and Graphics
#21

Hi Brent,

Yup. In Graphics 1.0 (and even in the V1 Compatibility Mode, largely), using a non-center reference point didn’t cause an issue when the Sprite’s frame size changed. This may have been due to the fact that they were the same size before being assembled into the image sheet (via TexturePacker). I’m not sure, I was always a bit fuzzy about why it worked; I just know that it did, and wasn’t an issue in the 1.0 version of Doggins which went live in March, or the two updates we’ve since released, all built with Graphics 1.0.

Thanks!

  • David
#22

To clarify this issue a bit, I was just working with a simple sprite that exhibited the same problem. The sprite is a sequence of 19 frames, all 260x260. I used TexturePacker to create an image sheet from them, and subsequent Lua file. Each frame’s entry looks like this:

[lua] {

            – D_Shake01@2x

            x=2,

            y=752,

            width=208,

            height=210,

            sourceX = 20,

            sourceY = 46,

            sourceWidth = 260,

            sourceHeight = 260

        },

        {

            – D_Shake03@2x

            x=412,

            y=218,

            width=224,

            height=200,

            sourceX = 20,

            sourceY = 56,

            sourceWidth = 260,

            sourceHeight = 260

        },[/lua]

Notice that while the width and height of each frame are different, the sourceWidth and sourceHeight are identical. This is because Texture Packer removed the transparent pixels in each frame, changing their size. However, according to Corona’s Image Sheet guide, that shouldn’t be a problem: http://docs.coronalabs.com/guide/media/imageSheets/index.html#trimming-notes

But, sure enough, if I set a non-center ancho point on this sprite and play it, it jumps around slightly as it animates. So it seems that the problem from my original post is the same as the problem articulated above: Corona seems to be ignoring the sourceWidth and sourceHeight information, which becomes noticeable with a non-center anchor point.

  • David
#23

Hi David,

I can’t vouch that trimmed sprites with different frame sizes exported from TP will work properly with a non-central anchor point. I suggest you still try to place the object inside a parent display group and work with it that way.

Take care,

Brent

#24

Hi Brent,

Thanks for the reply. I think the key is this statement from the Corona Image Sheet guide I linked to above:

Effectively, the image will be positioned in respect to the center point of the untrimmed frame size. 

This was happening correctly in Graphics 1.0 (as evidenced by my shipping game built with Graphics 1.0), but is no longer happening in Graphics 2.0. The TexturePacker output above conforms to the guide exactly, and was used successfully with Graphics 1.0, so it’s not the issue.

Regarding placing the object inside a parent display group, I’m still unclear on how this would help. If I take a display group with no set anchor point and nest it inside another group, that doesn’t seem to do anything. If I set an anchor point on the non-nested display group, it won’t do anything unless I use .setAnchor, which, since I’m using a non-center anchor point, causes the sprite to jump around, due to the issue outlined above.

If I’m missing something in your suggestion of using parent display groups, please let me know! Right now I’m re-doing all of my code to use center anchor points for all sprites in the game, and praying that I don’t mess anything up in the process, so a simpler solution would be welcomed. :slight_smile:

Thanks!
 

  • David
#25

Hi David,

Consider the following code, where I set up a parent group, anchor its children, then insert a “bounds” object which may represent the maximum bounds of everything within (this could and should be set to invisible at some point… or it may not be necessary to add it at all). Then, I place various objects in the group, set its own anchorX to 0, and move/rotate it. I also move around the children inside, and you’ll notice they move in accordance to how the parent is moving.

[lua]

local animGroup = display.newGroup()

animGroup.anchorChildren = true

local bounds = display.newRect( animGroup, 0,0,300,300 )

bounds:setFillColor( 0,0,0,0.4 )

local a1 = display.newRect( animGroup, -50,-20,100,100 )

a1:setFillColor( 1,0,0 )

local a2 = display.newRect( animGroup, 50,0,100,100 )

a2:setFillColor( 0,1,0 )

local a3 = display.newRect( animGroup, 0,100,100,100 )

a3:setFillColor( 0,0,1 )

local a4 = display.newRect( animGroup, 100,100,100,100 )

a4:setFillColor( 1 )

animGroup.x = 400

animGroup.y = 200

–animGroup.rotation = 10

animGroup.anchorX = 0

transition.to( animGroup, { time=5000, rotation=50, x=200 } )

transition.to( a2, { time=3000, x=100, rotation=50 } )

transition.to( a4, { time=5000, x=-100 } )

[/lua]

Not sure if this helps… perhaps I’m not clear on your overall setup.

Brent

#26

Hi Brent,

Thanks for clearing this up. I think I see what you’re saying now, though if I use .anchorChildren on any group that eventually has a sprite object in it, the sprite object animation will cease to be smooth. But again, I appreciate you clearing this up.

  • David
#27

Hi David,

Did you file a simple bug report showing how the sprite stutters inside an anchored group? The engineers should investigate that, and having a bug case/project to inspect keeps this issue in the queue for that.

Thanks,

Brent