I’m having trouble understanding the sourceSize (TexturePacker) / spriteSourceSize (Zwoptex) parameter in .plist files.
It seems that when I create a sprite by frame name, its contentSize gets set to this value. In the method
Sprite::setTextureRect(const Rect& rect, bool rotated, const Size& untrimmedSize)
, the newly created Sprite’s contentSize gets set to the untrimmedSize parameter - which is loaded from the .plist file as the sourceSize.
I have been using spritesheets without problems for some time, but today all my sprites boundingboxes got way too large after I recreated the spritesheet. For some reason, while the frame parameter has the correct dimensions, both Zwoptex and TexturePacker sets the sourceSize to a value - the same for every sprite in the spritesheet - whose origin I haven’t figured out yet (namely, 1536x2048). Looking back on my older files, it seems that TexturePacker used to set the sourceSizeto the same size as the frame size, with different sourceSize for different sprites, always the same as the frame size of the sprite.
If I use my older spritesheet files, my program works. However, with the strange sizing problem described above, I can no longer produce spritesheets that give me correctly sized files.
So my questions are: What is the parameter sourceSize supposed to represent? If it’s not the size of the graphics of an individual sprite, then why does the sprite’s contentSize get set to it?
EDIT:
Using my shellscript, instead of the GUI, produces “correct” results, that is, sourceSize is the same as the frame size. I use this command line:
TexturePacker --trim-mode Crop --disable-rotation --max-width 4096 --max-height 4096 "${pngdirs[$i]}" --sheet "$publishdir/${pngdirs[$i]}.png" --data "$publishdir/${pngdirs[$i]}.plist"
I’m not sure what setting changes the behaviour or which one is correct.
EDIT 2:
I found the source of the problem: the trim-mode setting in TexturePacker. If set to Crop, it works like I expected. I still find this confusing…