about the new spritesheet API

Solar2D General Questions/Discussion
#1

I use TexturePacker to generate my spritesheets.
I need the trimming option to be supported.
Has this been added to the new spritesheet API?
Moreover, what are the benefits of using the new spritesheet API? I read the blog and everything but found it a bit confusing. Do i have to generate the data files myself? What changed besides image groups.
I need some orientation in this since i’m not very experienced in this topic. Should i stick to the old spritesheet API and keep using texture packer or switch to the new one and do everything by had?

Thanks! [import]uid: 105206 topic_id: 23620 reply_id: 323620[/import]

#2

I can answer a few of your questions…

  1. Trimming/cropping is NOT yet implemented in the new API, but it should be coming sooner than later (alot of devs are begging for this, so I’m guessing it’s a fairly high priority for Ansca).

  2. I don’t use a texture packing tool like TexturePacker or SpriteLoq, but I believe the developers of those apps are updating them (or will do so) so they can output your data into Corona’s new imageSheet structure. Remember that this new API isn’t even “officially stable” yet, so it might be a couple weeks before the 3rd-party tools catch up with the API.

  3. I can’t say this with 100% certainty, but I think the new API is just better for overall performance, and tied in more closely with all of the new graphics performance updates added a couple weeks ago. The old sprite API is still backwards compatible as far as I know, but it might be slower. Furthermore, the old sprite API might eventually be phased out completely, so it’s not a bad idea to start switching over now, unless your app is almost ready for the marketplace and changing APIs at this point isn’t practical.

Brent Sorrentino
Ignis Design
[import]uid: 9747 topic_id: 23620 reply_id: 94827[/import]

#3

i agree with ignis. overall performance should be much better. i am also using texturepacker. you are still able to use those with the new api BUT trimming isn’t supported right now. i hope that they add trimm support soon! [import]uid: 90610 topic_id: 23620 reply_id: 94830[/import]

#4

Great guys thanks for your replies!
So i should do as i thought of, wait until the 3rd party tools get updated and corona adds trimming.
Hope that happens soon! [import]uid: 105206 topic_id: 23620 reply_id: 95135[/import]

#5

trimming is working now, with the latest build! [import]uid: 90610 topic_id: 23620 reply_id: 95139[/import]

#6

Hey Dingo - I just saw that on the release notes - is there anything I should change in my code to implement this or is it something TexturePacker will handle when it’s updated? [import]uid: 103802 topic_id: 23620 reply_id: 95142[/import]

#7

well, i think there is no need for texturepacker to update, because we still can use the old data:

local oldStyleSpriteSheetData = require("uma").getSpriteSheetData()  
  
local options =  
{  
 spriteSheetFrames = oldStyleSpriteSheetData.frames  
}  
  
local imageSheet = graphics.newImageSheet( "uma.png", options )

then load the imageSheet into a sprite and you’re fine. i just tried it and it seems to work! [import]uid: 90610 topic_id: 23620 reply_id: 95145[/import]

#8

Doesn’t using the old data mean there’s no way of using dynamic SD/HD sprites or am I way off ? :S [import]uid: 103802 topic_id: 23620 reply_id: 95286[/import]

#9

hello06,

I couldn’t use the dynamic SD/HD with Texture Packer either.

Has anyone had better luck? [import]uid: 135590 topic_id: 23620 reply_id: 98357[/import]

#10

I’ve run though several issues and got things working, so I’m not sure which apply to your project, but one definite tip for TexturePacker I’ve discovered is to knock off all border and padding.

In the new Sprite API only the SD frames options are included, the assumption is the HD image file will be an exact x2 and the frames co-ordinates can simply double to effect a smooth animation using the hi-res file. However border and padding are applied as a default in texturepacker, and when these are doubled at HD all co-ordinates are skewed, resulting in an @2x imageSheet laid out differently to the SD version, which the new Sprite API doesn’t accommodate. Making sure all borders and padding are off has made every export an exact double, which then behaves perfectly with the new Sprite API.

Hope that helps

J [import]uid: 103802 topic_id: 23620 reply_id: 98531[/import]

#11

Great info hello06! Thanks! [import]uid: 105206 topic_id: 23620 reply_id: 98790[/import]