Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / AddSpriteAnimationFrame scaling issue

Author
Message
Wilf
Valued Member
18
Years of Service
User Offline
Joined: 1st Jun 2006
Location: Gone to Unity.
Posted: 4th Sep 2013 01:12 Edited at: 4th Sep 2013 01:15
I've been playing around with the combination of Spine, TexturePacker and AppGameKit to create animated sprites.

Having figured out how to use the LoadSubImage and AddSpriteAnimationFrame commands, I've run into an issue when packing sprites more efficiently onto spritesheets using TexturePackers Trim function. More images on the sheet means smoother animation and more efficient use of memory.

When using TexturePackers Trim option, AppGameKit wants to resize the image of the sprite frame, making the sprite expand and contract when played. Heres my code:



SpriteA on the left plays as expected. SpriteB on the right gets bigger and smaller according to the size of the Sub Image used to create it. The goal is to have the sprite just animate, not resize.

I've fiddled are with using SetSpriteAnimation as the docs say
Quote: ""Storing an animation image on an atlas texture is supported.
""
but doesn't say how to achieve this.

My understanding is that loading subimages from a spritesheet is the most efficient way of cramming images into memory, have I missed something?



The spritesheets are attached with the program as a .zip

Attachments

Login to view attachments
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 4th Sep 2013 11:18
For sprite animation to work properly all frames must be the same size, the trim option reduces each image down to the minimum size (which may not be the same). My advice is to make sure the image frames are all the same.

I'm not able to test your code but that would be my advice.

"Everything should be made as simple as possible, but not simpler."
Wilf
Valued Member
18
Years of Service
User Offline
Joined: 1st Jun 2006
Location: Gone to Unity.
Posted: 6th Sep 2013 16:02
Yeah, that's a shame. Reduces the utility of sub images quite a lot, where it should be calculating pixel density.
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 6th Sep 2013 16:08
It might be possible to write your own frame by frame animation system that changes UV offsets or sprite size depending on the current sub-image size but for the amount of memory you'd save having smaller sub images I doubt it's worth it. Unless you have quite a few spritesheets I'd say just don't trim them.

"Everything should be made as simple as possible, but not simpler."

Login to post a reply

Server time is: 2024-11-24 19:39:05
Your offset time is: 2024-11-24 19:39:05