If I use TexturePacker to create my spritesheet, and the sprites have a large transparent area that's cut away, when they're pulled out by Starling, is the image JUST the minimum size of the sprites, or does it expand to be the same size as the original sprite, with the transparent areas?
TexturePacker and Starling
(24 posts) (9 voices)-
Posted 1 year ago #
-
The image is just the minimum size of the sprites. You should use the crop property.
Posted 1 year ago # -
thanks. That's the answer I was hoping for
Posted 1 year ago # -
Just to be sure there are no misconceptions, I want to elaborate a little on that.
The texture object itself will only report the cropped size (texture.width, texture.height). But if you create an image with that texture, the size of the image will depend on the setting you're using in Texture Packer.
* when you use "trim", images will have their original (untrimmed) size
* when you use "crop", images will have their cropped size, without the transparent borderPosted 1 year ago # -
Thanks for the additional information - that's exactly what I'm wanting.
One more question, probably related more to texture packer ... if I create a spritesheet and use it in the program, then I want to add a few more sprites, because of the way texture packer works, they could all be assigned different suffixes, couldn't they? So I may have to go back and change what suffixes in the program belong to each sprite (in this case, a spritesheet would be for non-animated sprites, that are being used in the image class)
Posted 1 year ago # -
@shaz What exactly do you mean with "suffix"?
The position of a sprite inside the texture might change but the name for the sprite stays the same. So you don't have to worry about that.
Posted 1 year ago # -
@shaz What exactly do you mean with "suffix"?
The position of a sprite inside the texture might change but the name for the sprite stays the same. So you don't have to worry about that.
Posted 1 year ago # -
By suffix, I mean the number appeneded to the name you provide. In the example I saw, if you name the file "run", then your individual sprites are named "run001", "run002", etc.
If my files are called Sprite1.png, Sprite2.png, Sprite3.png and I import them into Texture Packer, then I add Sprite1a.png (coming between them in the alphabetical list), then redo my spritesheet, will Sprite2 and Sprite3 have the same names as they previously did, or will they shuffle down because there's a new image that's loaded before them?
Posted 1 year ago # -
This is in case you are using the .swf importer. In this case the files get named automatically.
TexturePacker uses the name of the image. If you name the file sprite1.png it will become sprite1.png or sprite1 (if you use trim names)
You can just test it - the essential version is free but restricted in some features.
Posted 1 year ago # -
Thanks Andreas. I thought it named all the sprites based on whatever file name you specified when you saved it. I've just found the windows version, and will be playing with it today.
Posted 1 year ago # -
Thanks Andreas. I thought it named all the sprites based on whatever file name you specified when you saved it. I've just found the windows version, and will be playing with it today.
Posted 1 year ago # -
ack! Sorry - slow browser response made me think I clicked the wrong circle.
Posted 1 year ago # -
Sorry to rebump...
When I crop a Texture in TexturePacker, and bring it in to starling, is the origin point of the image maintained?
Imagine you have a 100x100 transparent png, apart from a single pixel at location x:50 y:50.
When I pass this to a Image, is my Image still 100x100 with a pixel at 50:50? Or has the transparent zone been lost? I need a way to maintain a common origin point without filling the GPU with transparency.
Posted 3 weeks ago # -
TexturePacker as 3 Modes:
* trim - which should preserve the position & size of the original
* crop, keep pos - which keeps the position but reduces the size - useful e.g. for buttons
* crop, flush pos - which sets position to 0/0 and size to the cropped sizePosted 3 weeks ago # -
Thanks Andreas! Appreciated.
Posted 3 weeks ago # -
It uses the smaller (71kB) amount.
This is because the transparency is replaced by a translation operation. The smaller sprite is moved to match the original position.
This
1) reduces memory
2) increases performances (since no transparent pixels have to be drawn)Posted 1 week ago # -
@Andreas Loew:
Do you think you can add texture atlas merging anytime in a foreseeable future?
Usage scenario: I like how TexturePacker adds all the images from a folder to an atlas, but I'd like it to add BMFont fonts or atlases generated by other tools too (like DragonBones/Spine).
Posted 1 week ago # -
@Jarek,
texture packer would need :
1. an import tool (for other tps files maybe)
2. a custom import tool, with two inputs :
- the file to import (xml format)
- the "data description file" that describes how to format the first file (coming from another tool) to a texture packer format.but in the end you still have to re-generate (somehow) a file to describe where on that final atlas your characters are for BitmapFont (for that BMFont example) ... because they probably moved since they got repacked - and that's a problem I think
also possible data loss.
---
I may be wrong though. I just give myself this as an explanation to why it hasn't been done and is harder than just merging pictures.
Posted 1 week ago # -
Try get texture from main atlas e.g. font, and use it to create new atlas with xml font. I think tried this and works. Just do a test.
Posted 1 week ago # -
@cywil_pl
yeah, did that, but TP is changing texture positions quite often and it gets annoying to update xmls. As a bonus - things get weird when you account SD/HD/SuperHD sizes and pngs with mergerd xmls (dragonbones).
I'd be more than happy to pay some small fee for app that could handle this shit and has at least 1/10 support that Andreas does.
Posted 1 week ago # -
Updating the XMLs should be easy with a small script that reads the XML TexturePacker creates and patches the other one.
You could even add this to your build process.Spine should already work with TexturePacker.
Posted 1 week ago # -
Dragonbones allow use your own atlas by now.
@Jarek - pls read PM.Posted 1 week ago #
Reply
You must log in to post.