Problem with Trim option in TexturePacker

moopf

Hi @atilim - I seem to be having a rendering issue when using the Trim option in TexturePacker. Basically I'm constructing a sprite from two images, a backing image and a front image. The backing image is the same in all cases, the front image differs. For the base resolution all images (both backing image and different front images) are 32 x 32, for the x2 resolution all images are 64 x 64. However, the front image has lots of transparent pixels and these differ on different front images.

The problem is that when I use trim in TexturePacker, which stores the images in the texture without any bounding transparent pixels, when I create the sprites in Gideros and display for the x2 resolution there are alignment issues which have the effect of pushing the full sprite a little out of position. If I turn Trim off in TexturePacker this problem goes away. Internally Gideros is reporting incorrect sizes for the images when I use getWidth() and getHeight() for the two images, here are some examples:

backing size 31 31
image size 32 32

backing size 31 31
image size 31 31

backing size 31 31
image size 31 32

backing size 31 31
image size 31 32

backing size 31 31
image size 32 31

You'll notice that backing size is always a pixel out in both x and y, and image size (for the different front images) can be out differently on different images.

This makes me think that there might be a bug with getTextureRegion and scaling that doesn't quite work correctly when Trim is being used. I've used Trim before with other development systems without a problem. With trim off both backing size and image size report 32 x 32 all the time.

At the base resolution everything aligns properly even with trim on, it's when I'm using higher resolution assets that the problem occurs.

Any ideas? Obviously I can turn trim off for now but it's a very useful facility to be more efficient with memory.

KeepTrying

I had a similar problem so I used the trim function in Photoshop,
then imported back the frames into Texture Packer and case solved.
Perhaps a problem with this function in Texture Packer.

Photoshop CS6 Trial
http://www.adobe.com/cfusion/tdrc/index.cfm?product=photoshop&loc=en_us

moopf

No, it's not TexturePacker that's causing the problem as far as I can discover, it definitely seems like a Gideros issue. I've used trim in TexturePacker with other systems (such as cocos2d and Moai) without such an issue being present.

I'm aware of trimming in Photoshop but doing so convolutes positioning code in the app itself. It's much easier to trim in the packed texture output and have it read as its proper size in Gideros for this purpose.

atilim

Let me look at it.

For example, open the sample code "Hardware/Automatic Texture Pack Resolution" and add these 4 lines at the end of main.lua:

print(hammerb:getWidth(), hammerb:getHeight()) print(monkeywrenchb:getWidth(), monkeywrenchb:getHeight()) print(pliersb:getWidth(), pliersb:getHeight()) print(screwdriverb:getWidth(), screwdriverb:getHeight())

With iPhone resolution the output is:

84 131 94 101 115 95 107 108

and with iPad resolution the output is:

83 130 93 100 114 94 107 107

The +1/-1 difference is the bug you've mentioned, right?

moopf

Hi @atilim, thanks for replying. Yes that looks like the bug I'm finding. Plays havoc with positioning

atilim

I see. Let me debug it and I'll update this thread when I catch something.

atilim

@moopf, now it's fixed. Previously I was doing calculations with trimmed sizes but now I'm doing calculations with untrimmed sizes. Doing calculations on trimmed sizes resulted in some rounding errors (+1/-1).

Thank you for reporting.

moopf

Thanks @atilim

moopf

Hi @atilim - I've just come across a really bizarre issue with TexturePacker and Gideros. I have two packed textures, the SD and a @2x - the SD one had an extra image in it that isn't being used in higher resolution modes and actually isn't referenced by the app at all at the moment.

The effect of just having this in the packed sd texture caused all images to display with incorrect Y scaling when using the player with retina or iPad resolution. If I remove it, everything sorts itself out, if I put it back in the same thing happens.

This might be indicative of something strange going on in the background? If you want the packed textures and .txt files just let me know and I'll send them over to you.

moopf

Hi @atilim, I'm trying out 2012.9.2 and I'm not sure the fix for trimmed packed textures is working correctly, unfortunately. Although the dimensions of the textures that make up the sprite are being reported correctly, they're certainly not being displayed properly.

I've attached two images, one with trim on and one with trim off on the packed textures (I've blown the images up so you can see what I mean - they're originally 64 x 64). In both instances the overall sprite and the front image (the white line) are being reported as 32 x 32 but you'll see that when trim is on the backing image is actually slightly smaller even though it's still being reported as 32 x 32 itself.

Any ideas?

With trim on:



With trim off:

atilim

@moopf if possible, can you attach a simple example? (I won't be around for a couple of hours and will look at it when I turn back).

moopf

Hi @atilim, sure thing. I've attached an example. I've created four texture packs - sd and @2x with trim off and the same with trim on. I've included them in a sample project which displays them side by side so you should see what I mean.

atilim

Thank you. And yes, I can see the error. Let me play with this example and update this thread.

moopf

@atilim, when you have a solution, if you'd like it testing please feel free to email me - I don't mind putting it through its paces and doing some QA on it if it helps you out.

moopf

Hi @atilim, I want to update you on this. I've upgraded to TexturePacker 3 today and am now using the fantastic expanded Auto-SD facility to automatically produce all the sprite sheets from the highest resolution @4x versions (wow this makes a massive difference to workflow!)

I've been playing with the settings today and I can get Gideros to display the images correctly using trim as long as I use the 'Force Identical Layout' option available on the Auto-SD settings screen in TexturePacker.

Whilst this is a work around I think it's hiding the limitations that I've previously explained in another thread that are introduced into Gideros by it using the SD image to obtain scaling information for higher resolution artwork. Please consider not doing this any more - it's playing havoc with higher resolution artwork. This will also presumably be why I simply cannot get higher resolution fonts produced in GlyphDesigner to display correctly (without clipped glyphs etc.) as well and, whilst I've worked around some of the issues there, because Gideros is internally using the SD dimensions etc. in some way when displaying higher resolution artwork, I can't get around them all.