Pixi: TexturePacker and Sprite Sheets - critical settings

[inductible]

I just learned a few bits the hard way, and wanted to share (since this forum seems to be turning into a good repository for Pixi info, pre-tutorialisation)...

 

Using texture packer you need to use JSON (Hash) format. JSON (Array) won't work - the image can't be referenced by name using Sprite.fromFrame() otherwise.

 

Also, in texturePacker, 'Allow Rotation' is a no-no at this stage - this can throw the an error during atlas texture mapping.

[Aymeric]

Hey,

 

I also would like to add that if we want to run a MovieClip (without having 2 manage its position dynamically), we have to be sure that all its frames have the same size. This means in TexturePacker we're not able to select the trim or crop option. So finally I got 21 SpriteSheets instead of 9 !!! because I'm not able to use the trim / crop property. That must be fixed!

 

My 2 cents.

[xerver]

1This means in TexturePacker we're not able to select the trim or crop option.

 

This isn't true, TexturePacker allows you to set a common size for sprites within a sheet, you can crop/trim them down to a common size. Pixi has no way of knowing what offset each frame of your animation should be at, which is why we expose things like anchor. I've haven't had a case where messing with the anchor/position wasn't a solution to lining up animations that I wanted trimmed to different sizes.

[Aymeric]

Hey, thanks for the answer.

 

However I didn't get the point. AFAIK you're not able to select the crop/trim common size!? in TexturePacker (I've the latest version).

If your exported animations spritesheets doesn't have the same width / height (not its real width / height for an animation, its width / height for all the animations), even if we set anchor to its center the animation will never be at the same position since the exported animations spritesheets doesn't have the same width / height, right?

 

Well, I'm not sure to explain it very well... As an exemple, using Starling you can set up your spritesheet using the trim option and eveyrthing will be managed under the hood. You won't have to move it on each frame.

[xerver]

You can modify the anchor/position of a sprite each frame if you want each frame to be of a different size, I do this a lot with lttp so that each frame is as trimmed as possible but playing the animation looks smooth.

 

A different solution is to set the "Common divisor" property to whatever size you want each frame to be, and texture packer will make each frame that same size.

 

You have to have some information to send an engine for it to know where to position sprites for animations. You do that in PIXI by modifying the anchor/position whenever you need to. I'm sure Starling is doing something similar under the hood, but you still have to pass it that data somehow.

 

If what you are trying to say is that each of your frames are the same size before being packed by texture packer, and you want pixi to use that original size; then I refer you to the fact that trim/crop data is not fully supported in pixi. Like I mentioned before I found the easiest way to implement this is to set offsets for frames and apply them as the animations loops.

 

Hope this helps.

[Aymeric]

Ok, thanks for the answer!

 

Hope it will be fully supported under the hood soon

[pietro909]

Thank you Inductible, I was digging into my project trying to figuring out why I couldn't get frames' ID.

[richpixel]

Hi - I ran into this sprite sheet frame issue today. Does anyone have sample code that positions the animation each frame? I'm trying to do it but things look pretty jittery. Thanks.

[richpixel]

I wound up making some hacks to the pixi source to achieve what I wanted. If anyone is interested in those let me know. However, xerver I'm still interested in how you handled this problem in code... Thanks

[xerver]

I wound up making some hacks to the pixi source to achieve what I wanted. If anyone is interested in those let me know. However, xerver I'm still interested in how you handled this problem in code... Thanks

 

I adjust the anchor property each frame based on values I set.

[richpixel]

Ok, my first try was to update the position each frame, but there was a flicker when the MovieClip changed to the next frame - either showing the new frame at the old position or the old frame at the new position ... for 1 frame of animation. I'm guessing it was related to updateTransform() being called early or late such that the renderer had the wrong position for 1 frame.

 

I changed DisplayObject.updateTransform() so the local transform matrix would always get the correct position based on texture offset. (A hack)

[ForgeableSum]

I adjust the anchor property each frame based on values I set.

I'm in shock. Do we really need to do this for sprites with variable sourceSizes? 

 

Setting the common divisor can give each frame the same "spriteSourceSize", but "sourceSize" is still variable. I think it's "sourceSize" that needs to be the same across all frames to not have the jitter effect. 

[xerver]

I'm in shock. Do we really need to do this for sprites with variable sourceSizes? 

 

Setting the common divisor can give each frame the same "spriteSourceSize", but "sourceSize" is still variable. I think it's "sourceSize" that needs to be the same across all frames to not have the jitter effect. 

 

No, this thread you resurrected is 2 years old, and at least 2 major versions old and an uncountable number of minor versions old. rotation, trim, crop, etc all work find in modern versions of pixi.