Image Sheet Exporter: working with modification to corona-imagesheet.lua file

TexturePacker
#21

Hi all,

I’ve spent a while getting all this to work - here goes :wink:

I got the information about sprite trimming from the latest Corona SDK in the sample code HorseAnimation. You will see in uma.lua that trimming is used by setting the values for sourceX, sourceY, sourceWidth and sourceHeight for the imagesheet.

The code that I posted previously adds these values to the exporter for conorna SDK in TexterPacker.

The steps to get this working are:

  • Create a new exporter by opening the TexturePacker package then create a copy of the Corona Exporter folder under Resources/exporters/corona-imagesheet
  • Rename the new folder something like corona-trim-imagesheet.
  • Rename the corona-imagesheet.lua to corona-trim-imagesheet.lua
  • Open corona-trim-imagesheet.lua and replace the frames section with the code I posted previously.
  • Open the exporter.xml file in the new folder.
  • Change the name element to reference the new name “corona-trim-imagesheet”.
  • Change the template element to reference the new .lua file “corona-trim-imagesheet.lua”
  • Change the supportsTrimming element to “true”.
  • Launch TexturePacker and you should now have a corona-trim-imagesheet option.

I have used the API and it is stable enough. The main problem you will have is with dynamic image scaling. As Andreas mentioned TexturePacker will always try and pack the images as best as possible. If this results in odd pixels (or more accurately pixels that are not divisible by the scale you want to produce) then the images will jump around slightly due to different offsets.

For now I am not using trimming as I need to use dynamic image scaling. I think some kind of trimming divisor will be needed in TexturePacker to fully support this feature, but seeing as the API is not yet in a Corona stable release I doubt that Andreas will want to commit to adding the functionality :wink:

The other problem that you will find is when you are creating multiple resolutions. You should work with the highest resolution first but must make sure that the images are divisible by the other scales you want to use. If they are not then you will find that TexturePacker (rightly so) may move the images around when you change the scale.

The way I make this work is to ensure that all my images at the highest resolution I am going to use are divisible by the other scales I want to use e.g. if I am using scales 1.0 and 2.0 then I just need to make sure that the width/height of my 2.0 images are all even (divisible by 2). When using TexturePacker I use an imagesheet that is 2048x2048 and set padding to 4. I export these images and then change the scale to 0.5 and change padding to 2 then export my 1.0 scale images. You must use the .lua file in Corona that was generated for the 1.0 scale images.

It gets more complicated if you are producing assets for more resolutions. For example if you are going to use 1.0, 1.5 and 2.0 you must make sure the high res images are divisible by 4. This is so that when you set the scale to 0.75 for your 1.5 resolution images there will still be a whole number of pixels for TexturePacker to work with. For scales 1.0, 1.8 and 4.0 you will need your high res images to be divisible by 20!

Hope this helps,
[import]uid: 77943 topic_id: 23739 reply_id: 110636[/import]

#22

Is there a way to perfectly map a regular resolution texture atlas with a @2x one? I have some images that are the exact same sizes, and it places them differently in each atlas I make. Also, sometimes it’ll “arrange/reposition” everything on each atlas, but stuff will be in different spots. I need a way to make sure everything is in the exact same place on both sprite sheets (just double the resolution on the @2x one). I’ve made sure all my images are exactly double, but TP still sorts them differently :frowning: [import]uid: 51654 topic_id: 23739 reply_id: 110742[/import]

#23

I ran a test on the latest texture packer beta 8: 100 sprites.
These sets of commands created proper imagesheets for SD and HD:

Set 1:
[text]
TexturePacker --data animation-hd.lua --format corona-imagesheet --allow-free-size --shape-padding 4 --border-padding 4 --sheet animation-hd.png --no-trim --algorithm Basic --auto-sd *.png
[/text]

Set 2:
[text]TexturePacker --data animation-hd.lua --format corona-imagesheet --allow-free-size --shape-padding 4 --border-padding 4 --sheet animation-hd.png --no-trim --algorithm Basic *.png
TexturePacker --data animation.lua --format corona-imagesheet --allow-free-size --shape-padding 2 --border-padding 2 --sheet animation.png --no-trim --algorithm Basic --scale 0.5 *.png[/text]
I haven’t tried other sorting algorithms, since I’m using the non pro version.

Krystian
EDIT:
I have tried running TP separately for HD and SD images but it didn’t work. As well, I made sure there were no odd sized sprites. [import]uid: 109453 topic_id: 23739 reply_id: 110745[/import]

#24

I’m not sure why it wouldn’t work using it separately, that’s how I use it. I remember that I was tripped up by the enable auto alias being true as default when using the UI directly and this sometimes causes images that are not exactly the same to become the same when they are scaled down and they end up being moved around.

003naveen - I would suggest trying to add just the @2x images to TexturePacker, set the padding to 4 and export the sheet, then change the padding to 2, set the scale to 0.5 and export again using a different filename and see if they come out the same. Remember to set enable auto alias to false.

I don’t use the auto SD option because… not sure why :slight_smile: never noticed it. I usually have to create at resolutions for iPhone/iPad/Android all together so need more than just 2 and 1 scales.
[import]uid: 77943 topic_id: 23739 reply_id: 110747[/import]

#25

I am currently updating TexturePacker to handle odd scalings by forcing multiples of the scaling factors.

But I am still convinced that it is a bad idea to force the same coordinates on different images. It might seem easy for scale factor 1.0, 0.5 and 0.25 but it will get bad with odd factory like scaling from iPad to iPhone to using .9375 or something else.

Here you will always end up with artifacts on the borders because the odd sizes will drag in transparency from the surroundings. This will be especially ugly if you try to stitch together a UI from several separate sprites. Or use tiles.

TexturePacker’s current algorithm would round the sprites to an whole number - you would end up with +/-0.5 pixels for a sprite but if you could ask the sprite’s width you should be able to stitch them together perfectly.
[import]uid: 9611 topic_id: 23739 reply_id: 110750[/import]

#26

sorry for reviving this post but i really need help!
texture packer got updated and now the trimming option for image sheets is disabled again.
even though i get into the corona-image sheet/exporter.xml file and change supportstrimming to true, the option does not activate.
please, please help! [import]uid: 105206 topic_id: 23739 reply_id: 118081[/import]

#27

nml read this topic again…

You will see your reply on it. [import]uid: 142895 topic_id: 23739 reply_id: 119620[/import]

#28

nml read this topic again…

You will see your reply on it. [import]uid: 142895 topic_id: 23739 reply_id: 119620[/import]

#29

Please get rid of the javaesk getters in the lua source template (getSheet, getFrameIndex). They serve absolutely no purpose, but to confuse n00bs and hurt my eyes. My colleage is highly confused about this. He now writes getters at random places completely without understanding the concept in OO.

#30

Please get rid of the javaesk getters in the lua source template (getSheet, getFrameIndex). They serve absolutely no purpose, but to confuse n00bs and hurt my eyes. My colleage is highly confused about this. He now writes getters at random places completely without understanding the concept in OO.