newImageRect using imageSheet and trimmed frames doesn't use sourceWidth/sourceHeight?

Audio and Graphics
#1

I created an imageSheet in Texture Packer with an image that has a transparent border around it.  The image has 80 pixels square of content in a 100 pixel art board. Texture Packer trimmed off the transparent pixels.  When I create a newImageRect using that imageSheet, the resulting display object has a width and height that is the dimensions of the trimmed object, NOT the dimensions of the untrimmed object.

Is this correct/expected behavior?  If so, why?

We use Spine with Corona and some of the animators use an image asset that has this transparent padding to help in positioning layered objects.  Spine expects this image asset to be a certain width and height, so when it is passed this image that has the dimensions of the trimmed object, it doesn’t look right because the image is stretched to the untrimmed dimensions.

At first I wasn’t sure if this was a Corona issue or a Spine issue, but I would think Corona should honor the untrimmed dimensions of an image in an imageSheet, right?

Thanks for any help. I’ve included a small test program to show the issue.

#2

Hi @kleung,

The behavior is affected by how you export the sheet from Texture Packer. I’m not sure exactly how your game art looks, but if you don’t want TP to trim off the padding pixels, then you should instruct it not to. That should omit the parameters in the sheet definition file (from TP) that Corona would use to assume it should be trimmed, and thus Corona should honor the entire 100x100 image.

Some more trimming notes are contained here:

http://docs.coronalabs.com/guide/media/imageSheets/index.html

Brent

#3

I understand that if I don’t select “Trim” in TP, it will include all transparent areas and keep the 100x100 image. I thought the point of the “Trim” functionality was to pack the images into the least amount of disk space, and then when used in the program, it would “re-inflate” the image to include all the transparent areas.

If Corona honors the untrimmed size of an image in it’s placement on screen as stated in the docs ( “the image will be positioned in respect to the  center  point of the untrimmed frame size” ), then why doesn’t it honor the untrimmed width and height of the image?  

Is there any way to get the original untrimmed image from a trimmed imageSheet?  We would like to keep the Trim option on TP in order to save disk space on our sprite sheets, but we would also prefer that the resulting newImageRect maintain the untrimmed image dimensions.

#4

Can I get a response for my last question?  Thanks!

#5

Hi @kleung,

In my tests, once you trim the image, Corona considers it trimmed on output… so it may not be possible to get the untrimmed size in respect to the Corona display object. However, I think you may be able to pass the “original size” (both width and height) along with the data tables that TP generates, then read/use those in your newImageRect() calls instead of the trimmed width and height. This would require a bit more effort up front, but I think it would provide a workaround for your issue.

Best regards,

Brent

#6

Hi Brent,

I’m a little confused. Are you saying I can create the untrimmed image from the trimmed image plus the TP data?  I’ve tried passing in the untrimmed width and height (sourceWidth and sourceHeight) into newImageRect and that doesn’t work.  I’ve even tried using a snapshot to create the untrimmed image, but that had weird side effects.  Can you provide a code example of the workaround you mentioned?

#7

Hi @kleung,

Actually the snapshot idea is probably better. What side effects did this produce? Using that, you could create a snapshot of the untrimmed size, add the trimmed object to it, offset it by the “x” and “y” from the TP definition, and it should work as you need.

Brent

#8

Hi @kleung,

The behavior is affected by how you export the sheet from Texture Packer. I’m not sure exactly how your game art looks, but if you don’t want TP to trim off the padding pixels, then you should instruct it not to. That should omit the parameters in the sheet definition file (from TP) that Corona would use to assume it should be trimmed, and thus Corona should honor the entire 100x100 image.

Some more trimming notes are contained here:

http://docs.coronalabs.com/guide/media/imageSheets/index.html

Brent

#9

I understand that if I don’t select “Trim” in TP, it will include all transparent areas and keep the 100x100 image. I thought the point of the “Trim” functionality was to pack the images into the least amount of disk space, and then when used in the program, it would “re-inflate” the image to include all the transparent areas.

If Corona honors the untrimmed size of an image in it’s placement on screen as stated in the docs ( “the image will be positioned in respect to the  center  point of the untrimmed frame size” ), then why doesn’t it honor the untrimmed width and height of the image?  

Is there any way to get the original untrimmed image from a trimmed imageSheet?  We would like to keep the Trim option on TP in order to save disk space on our sprite sheets, but we would also prefer that the resulting newImageRect maintain the untrimmed image dimensions.

#10

Can I get a response for my last question?  Thanks!

#11

Hi @kleung,

In my tests, once you trim the image, Corona considers it trimmed on output… so it may not be possible to get the untrimmed size in respect to the Corona display object. However, I think you may be able to pass the “original size” (both width and height) along with the data tables that TP generates, then read/use those in your newImageRect() calls instead of the trimmed width and height. This would require a bit more effort up front, but I think it would provide a workaround for your issue.

Best regards,

Brent

#12

Hi Brent,

I’m a little confused. Are you saying I can create the untrimmed image from the trimmed image plus the TP data?  I’ve tried passing in the untrimmed width and height (sourceWidth and sourceHeight) into newImageRect and that doesn’t work.  I’ve even tried using a snapshot to create the untrimmed image, but that had weird side effects.  Can you provide a code example of the workaround you mentioned?

#13

Hi @kleung,

Actually the snapshot idea is probably better. What side effects did this produce? Using that, you could create a snapshot of the untrimmed size, add the trimmed object to it, offset it by the “x” and “y” from the TP definition, and it should work as you need.

Brent

#14

@kleung: Did you ever find a solution to this? I’m running into a somewhat similar situation.

Is the guide indeed wrong that “the image will be positioned in respect to the center point of the untrimmed frame size”? If so, are there plans to fix it? Or at the very least, update the guide?

#15

Hi David,

I’m 99.9% sure that the guide is correct on this issue. When I updated the guide on that particular point, I tested to determine that what’s stated is correct. If you can show a clear example of this being not so, then I’ll take a look, but otherwise I believe it’s correct. Previously the guide did not include that part, and it was causing confusion, which is why I tested and added that section.

Brent

#16

Hi Brent,

Thanks, that’s good to know. I think I was misreading some of what you said in this thread. Thanks!

  • David
#17

@kleung: Did you ever find a solution to this? I’m running into a somewhat similar situation.

Is the guide indeed wrong that “the image will be positioned in respect to the center point of the untrimmed frame size”? If so, are there plans to fix it? Or at the very least, update the guide?

#18

Hi David,

I’m 99.9% sure that the guide is correct on this issue. When I updated the guide on that particular point, I tested to determine that what’s stated is correct. If you can show a clear example of this being not so, then I’ll take a look, but otherwise I believe it’s correct. Previously the guide did not include that part, and it was causing confusion, which is why I tested and added that section.

Brent

#19

Hi Brent,

Thanks, that’s good to know. I think I was misreading some of what you said in this thread. Thanks!

  • David