Stuttering Sprites in Graphics 2.0

Audio and Graphics
#1

Hi all,

I’m finally biting the bullet and updating Doggins to use the new Graphics 2.0 engine, and have encountered an issue with sprite animation feeling stuttery.

The main character in Doggins is a display group that contains six sprite objects (created using the current display.newSprite API). The display group is given a center-right (1, 0.5) anchor point. When I move the character on-screen, I move the entire display group, and play sprite sequences on three of the sprites inside the display group. This worked fine on Graphics 1.0, and is the method used in the current release on the App Store.

When trying the V1 Compatibility Mode, I noticed that Doggins’s sprite animation felt stuttery, as it was skipping frames or jumping around. If I removed the :setReferencePoint(display.CenterRightReferencePoint) call, the animation felt smooth again. I decided to fully migrate the game to Graphics 2.0, and all was well until I set the anchor point and added “.anchorChildren = true” to the display group. The animation is then just as stuttery as in the V1 Compatibility Mode; if I disable “.anchorChildren = true”, it’s smooth.

Again, this worked just fine in Graphics 1.0. Anyone else encounter this? Any ideas?

Thanks!
 

  • David
#2

Hi David,

By “stuttering” do you mean the actual sprite animations are slowing down or skipping? Or is this something with the “position” of the sprite objects in the group? Are you getting any error messages in the Terminal?

Have you considered using the alternative to .anchorChildren, wherein you place the group inside another “parent” group and then manipulate that parent group?

Take care,

Brent

#3

Hi Brent,

The sprite animation seems to be skipping or stuttering; if I turn off the animation but still allow the display group to move, the movement is smooth. I’m not getting any error messages, and it’s only a problem if anchorChildren is set to true.

I’m a bit confused about the nesting method. Do I then set an anchor point on the parent display group? Do I use anchorChildren on that? I’m not really sure how nesting it inside another group helps. Any pointers on that would be great. :slight_smile:

Thanks for the help!

  • David
#4

Hi David,

Can you file a bug report on this? If you’ve isolated it to where the stutter is only occurring if you use “anchorChildren”, but not  in other cases, then we need to investigate your project and see if there’s a deeper bug.

Thanks,

Brent

#5

In the meantime, if you haven’t read the entire guide on groups yet, please do so. Especially the section “Groups and Anchor Points”.

http://docs.coronalabs.com/guide/graphics/group.html#groupanchors

Brent

#6

Hi Brent,

Thanks for the link; I read through the “Groups and Anchor Points” section and skimmed the rest. I think I understand groups a bit better, though I still don’t see how nesting a group inside a parent is similar to anchorChildren. :slight_smile:

I’ll file a bug report soon. In the meantime, I’m changing my code so that I never set anchor points on groups or sprites. I also noticed that if I set an anchor of top-left on a sprite and then animate it, if the frames ever change size, the sprite moves around on-screen. I never had this problem with Graphics 1.0. Could this whole problem be related to changes in sprite behavior?

Thanks!
 

  • David
#7

Hi David,

I don’t recall how sprites worked with setReferencePoint() in G1.0. In your past experience, did using a non-center point still allow everything to line up perfectly even when the sprite frames changed size?

Thanks,

Brent

#8

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
#9

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
#10

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

#11

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
#12

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

#13

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
#14

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

#15

Hi David,

By “stuttering” do you mean the actual sprite animations are slowing down or skipping? Or is this something with the “position” of the sprite objects in the group? Are you getting any error messages in the Terminal?

Have you considered using the alternative to .anchorChildren, wherein you place the group inside another “parent” group and then manipulate that parent group?

Take care,

Brent

#16

Hi Brent,

The sprite animation seems to be skipping or stuttering; if I turn off the animation but still allow the display group to move, the movement is smooth. I’m not getting any error messages, and it’s only a problem if anchorChildren is set to true.

I’m a bit confused about the nesting method. Do I then set an anchor point on the parent display group? Do I use anchorChildren on that? I’m not really sure how nesting it inside another group helps. Any pointers on that would be great. :slight_smile:

Thanks for the help!

  • David
#17

Hi David,

Can you file a bug report on this? If you’ve isolated it to where the stutter is only occurring if you use “anchorChildren”, but not  in other cases, then we need to investigate your project and see if there’s a deeper bug.

Thanks,

Brent

#18

In the meantime, if you haven’t read the entire guide on groups yet, please do so. Especially the section “Groups and Anchor Points”.

http://docs.coronalabs.com/guide/graphics/group.html#groupanchors

Brent

#19

Hi Brent,

Thanks for the link; I read through the “Groups and Anchor Points” section and skimmed the rest. I think I understand groups a bit better, though I still don’t see how nesting a group inside a parent is similar to anchorChildren. :slight_smile:

I’ll file a bug report soon. In the meantime, I’m changing my code so that I never set anchor points on groups or sprites. I also noticed that if I set an anchor of top-left on a sprite and then animate it, if the frames ever change size, the sprite moves around on-screen. I never had this problem with Graphics 1.0. Could this whole problem be related to changes in sprite behavior?

Thanks!
 

  • David
#20

Hi David,

I don’t recall how sprites worked with setReferencePoint() in G1.0. In your past experience, did using a non-center point still allow everything to line up perfectly even when the sprite frames changed size?

Thanks,

Brent