Jump to content
This forum will be closing down. Please move to the respective dedicated project forums.

Pixi: TexturePacker and Sprite Sheets - critical settings


inductible
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...
  • 2 months later...

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)

Link to comment
Share on other sites

  • 1 year later...

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...