Anchor points broken with trimmed frames in image sheet

Hi all,

After spending too much time on this issue, it seems clear to me that anchor points don’t work properly with imagesheets when the frame is trimmed (such as output from texture packer).

Corona does not respect the sourceX/Y/Width/Height data. Here is a simple reproduction case (complete test project included as attachment):

local SheetInfo = {} SheetInfo.sheet = { frames = { { -- redbox x=2, y=2, width=84, height=80, sourceX = 32, sourceY = 31, sourceWidth = 120, sourceHeight = 120 }, }, sheetContentWidth = 128, sheetContentHeight = 128 } SheetInfo.frameIndex = { ["redbox"] = 1, } function SheetInfo:getSheet() return self.sheet; end function SheetInfo:getFrameIndex(name) return self.frameIndex[name]; end return SheetInfo

local sheetInfo = require("testdata") local myImageSheet = graphics.newImageSheet( "testdata.png", sheetInfo:getSheet() ) local sprite = display.newSprite( myImageSheet , {frames={sheetInfo:getFrameIndex("redbox")}} ) -- We would like to scale the red box relative to its top left corner sprite.anchorX = 0 -- Set anchor sprite.anchorY = 0 sprite:scale(2,2) -- Scale it sprite.x = 0 sprite.y = 0 -- Add a circle so we can see where the display origin is local c = display.newCircle(0,0,10) c:setFillColor(0,1,0,1) -- BUG: The corner of the red box will not line up with circle center...

This bug was previously dismissed in this topic, but I think it is a serious issue, as it is core functionality.

http://forums.coronalabs.com/topic/50025-stuttering-sprites-in-graphics-20/?hl=%2Bimage+%2Bsheet+%2Banchor#entry259436

I hope this issue can be addressed in a timely manner.

Best regards,

Christer

Since you have a test case, please take a moment and use the “Report a Bug” feature at the top of the page.  Fill out the form, include this zip file so the Engineers can look into this.

Thanks

Rob

Thanks Rob. I have filed a bug report. Actually the test case above is not so good, so i made a new one for the bug report. I may later upload it here too if some one is interested.

Anyway, the anchors dont work properly. One can also tell bound box does not match the graphics when inserting a trimmed frame into a scroll view widget (the updated scroll area does not full include the trimmed sprite).

Hi Rob,

As I’m new to Corona I would just like to confirm how long it normally takes for the engineers to address the backlog of bugs. Is there an ETA for the next public build? I assume it could be months away?

This bug is a go-no-go, so I guess I will have to try some older public builds and see if it goes away.

Thank you,

Christer

No luck. I tried version 2013.2076 and the behavior is the same (I assume also at intermediate versions).

For reference I’ve attached the new test case, where it is shown that changing the anchor of the original unpacked image displayed with newImageRect does not behave the same as changing the anchor of a newSprite created from an image sheet where the image has been packed/trimmed.

If someone can show that I am doing something wrong and this is not a bug, then that would of course be nice too… please see attachment for complete project.

local SheetInfo = {} SheetInfo.sheet = { frames = { { -- thingy x=2, y=2, width=84, height=80, sourceX = 32, sourceY = 31, sourceWidth = 120, sourceHeight = 120 }, }, sheetContentWidth = 128, sheetContentHeight = 128 } SheetInfo.frameIndex = { ["thingy"] = 1, } function SheetInfo:getSheet() return self.sheet; end function SheetInfo:getFrameIndex(name) return self.frameIndex[name]; end return SheetInfo

-- Create a sprite from image sheet and change the anchor local sheetInfo = require("testdata") local myImageSheet = graphics.newImageSheet( "thingy\_on\_sheet.png", sheetInfo:getSheet() ) local sprite = display.newSprite( myImageSheet , {frames={sheetInfo:getFrameIndex("thingy")}} ) sprite.x = 100 sprite.y = 100 sprite:setFillColor(0,0,1,1) sprite.anchorX = 0 sprite.anchorY = 0 -- Create an image from the original unpacked image file and change the anchor local img = display.newImageRect("thingy.png", 120, 120) img.x = 100 img.y = 100 img:setFillColor(1,0,0,0.5) img.anchorX = 0 img.anchorY = 0 local anchor = 0 function changeAnchors(event) if anchor == 0 then anchor = 0.5 else anchor = 0 end img.anchorX = anchor img.anchorY = anchor sprite.anchorX = anchor sprite.anchorY = anchor end timer.performWithDelay(2000, changeAnchors, -1) -- BUG: The image and image sheet sprite do not line up in the same way when anchors are changed to 0,0

Another way to immediately see that sprites using trimmed image sheets are broken is by printing the width and height of the sprite in the above example:

print(sprite.width)

>> 84

print(sprite.height)

>> 80

This is incorrect as this is the width and height in the image sheet, which is completely useless information. The whole point of image sheets is surely that it should not matter how the sprites are packed. The correct thing would be for it to return the original sourceWidth and sourceHeight, as if we are still using the original image (it is then Corona’s job to work out the proper offsetting behind the scenes during final rendering). Clearly this also why trimmed sprites are incorrectly clipped/culled when inserted into a scroll view widget (the bounding box is incorrectly calculated, etc).

Sorry to keep spamming this thread. I just want to add that I was thoroughly enjoying learning LUA and Corona up until this point. Now I’m worried that this issue won’t be fixed in the near future, as it may break existing titles that have probably worked around the bug by manual offsetting or by disabling trimming (leading to increased texture size).

Any thoughts anyone?

Our normal release cycle for public builds is usually 3-4 months.  The current build is about 6 weeks old.  We intend to put out a new public build once we make sure iOS 8 is good to go.  We have several things we have to fix before hand and we also have to test on the new iPhones.   We don’t have an ETA.

Engineering has been slammed by all of these Apple changes of late and we have to focus on bugs that are going to impact iOS 8.   

Bugs are prioritized on several factors which includes the severity of the bug (crash bugs trump bugs that have work arounds), how wide of a swath of the community it impacts, etc.  I can’t predict when this bug will be processed.

Rob

Thank you for the thorough reply Rob. I appreciate it.

For now I will continue by disabling trimming in my project, with the assumption that the bug will be fixed in the next release (a calculated a risk).

Since you have a test case, please take a moment and use the “Report a Bug” feature at the top of the page.  Fill out the form, include this zip file so the Engineers can look into this.

Thanks

Rob

Thanks Rob. I have filed a bug report. Actually the test case above is not so good, so i made a new one for the bug report. I may later upload it here too if some one is interested.

Anyway, the anchors dont work properly. One can also tell bound box does not match the graphics when inserting a trimmed frame into a scroll view widget (the updated scroll area does not full include the trimmed sprite).

Hi Rob,

As I’m new to Corona I would just like to confirm how long it normally takes for the engineers to address the backlog of bugs. Is there an ETA for the next public build? I assume it could be months away?

This bug is a go-no-go, so I guess I will have to try some older public builds and see if it goes away.

Thank you,

Christer

No luck. I tried version 2013.2076 and the behavior is the same (I assume also at intermediate versions).

For reference I’ve attached the new test case, where it is shown that changing the anchor of the original unpacked image displayed with newImageRect does not behave the same as changing the anchor of a newSprite created from an image sheet where the image has been packed/trimmed.

If someone can show that I am doing something wrong and this is not a bug, then that would of course be nice too… please see attachment for complete project.

local SheetInfo = {} SheetInfo.sheet = { frames = { { -- thingy x=2, y=2, width=84, height=80, sourceX = 32, sourceY = 31, sourceWidth = 120, sourceHeight = 120 }, }, sheetContentWidth = 128, sheetContentHeight = 128 } SheetInfo.frameIndex = { ["thingy"] = 1, } function SheetInfo:getSheet() return self.sheet; end function SheetInfo:getFrameIndex(name) return self.frameIndex[name]; end return SheetInfo

-- Create a sprite from image sheet and change the anchor local sheetInfo = require("testdata") local myImageSheet = graphics.newImageSheet( "thingy\_on\_sheet.png", sheetInfo:getSheet() ) local sprite = display.newSprite( myImageSheet , {frames={sheetInfo:getFrameIndex("thingy")}} ) sprite.x = 100 sprite.y = 100 sprite:setFillColor(0,0,1,1) sprite.anchorX = 0 sprite.anchorY = 0 -- Create an image from the original unpacked image file and change the anchor local img = display.newImageRect("thingy.png", 120, 120) img.x = 100 img.y = 100 img:setFillColor(1,0,0,0.5) img.anchorX = 0 img.anchorY = 0 local anchor = 0 function changeAnchors(event) if anchor == 0 then anchor = 0.5 else anchor = 0 end img.anchorX = anchor img.anchorY = anchor sprite.anchorX = anchor sprite.anchorY = anchor end timer.performWithDelay(2000, changeAnchors, -1) -- BUG: The image and image sheet sprite do not line up in the same way when anchors are changed to 0,0

Another way to immediately see that sprites using trimmed image sheets are broken is by printing the width and height of the sprite in the above example:

print(sprite.width)

>> 84

print(sprite.height)

>> 80

This is incorrect as this is the width and height in the image sheet, which is completely useless information. The whole point of image sheets is surely that it should not matter how the sprites are packed. The correct thing would be for it to return the original sourceWidth and sourceHeight, as if we are still using the original image (it is then Corona’s job to work out the proper offsetting behind the scenes during final rendering). Clearly this also why trimmed sprites are incorrectly clipped/culled when inserted into a scroll view widget (the bounding box is incorrectly calculated, etc).

Sorry to keep spamming this thread. I just want to add that I was thoroughly enjoying learning LUA and Corona up until this point. Now I’m worried that this issue won’t be fixed in the near future, as it may break existing titles that have probably worked around the bug by manual offsetting or by disabling trimming (leading to increased texture size).

Any thoughts anyone?

Our normal release cycle for public builds is usually 3-4 months.  The current build is about 6 weeks old.  We intend to put out a new public build once we make sure iOS 8 is good to go.  We have several things we have to fix before hand and we also have to test on the new iPhones.   We don’t have an ETA.

Engineering has been slammed by all of these Apple changes of late and we have to focus on bugs that are going to impact iOS 8.   

Bugs are prioritized on several factors which includes the severity of the bug (crash bugs trump bugs that have work arounds), how wide of a swath of the community it impacts, etc.  I can’t predict when this bug will be processed.

Rob

Thank you for the thorough reply Rob. I appreciate it.

For now I will continue by disabling trimming in my project, with the assumption that the bug will be fixed in the next release (a calculated a risk).

I, too, am getting this issue.

I have an object that has a few different states and a couple of the states is significantly smaller than another. When I use anchorY with  a trimmed sprite, the anchor and position is based off the trimmed size. Thanks.

I, too, am getting this issue.

I have an object that has a few different states and a couple of the states is significantly smaller than another. When I use anchorY with  a trimmed sprite, the anchor and position is based off the trimmed size. Thanks.