Sorry your browser is not supported!

Hello, all. I'm enjoying learning AppGameKit but needed a clarification.

If I understand correctly, the SetSpriteAnimation command is the recommended way to use animation frames that are included in a texture atlas because it changes frames faster. But the frames have to have the same width and height.

To use frames of different sizes, I guess I'd need to add the subimages individually with the AddAspriteAnimationFrame command?

My question is: does the second approach lose the speed advantages of SetSpriteAnimationFrame command, even if they're all on the same texture atlas?

In the past I've used TexturePacker to build my texture atlas and trim the frames at the same time. This makes the texture atlas much smaller, but of course every frame is of a different size.

There is a slight overhead as it must resize the sprite each time a frame of a different size is reached, forcing it to recalculate a few things. But this shouldn't be noticeable.

If the frames are all on the same atlas then the renderer can still batch them into the same draw call with other sprites using the same texture so that won't be affected.

Thanks. That makes sense.

Ashambles how you solved the position problem automatically ? In our game at the beginning we tried to trim space using texture packer but at the end we had a lot of problems to found the correct sprite position considering the size is different every time. How you solved the problem ?

Hi, 7RS. I haven't had chance to do anything with it this week. I hope to get my first AppGameKit game roughed out this weekend. But this is how I intend to approach it:

1. Texture Packer supports the AppGameKit text format for subimages. So when you publish the sprite sheet, you will also get a .txt file that has to go in the media folder with the actual .png file.

2. Next you'd use LoadImage with the name of the sprite sheet to load it into memory. This automatically reads the .txt file so that AppGameKit knows how big each subimage is, where it starts, and what its original file name was.

3. Next you'd use LoadSubImage to load each of the sprite frames by name from the sprite sheet image. I think I'll use the option to assign an index in the LoadSubImage call so I don't have to create a bunch of new variable to hold that info.

4. Lastly, you'd use AddSpriteAnimationFrame to add each of the subimages by its index number to the sprite's animation. From there I think the animation just works as normally.

That's a lot more steps than just using SetSpriteAnimation, but on the other hand you only have to do the setup one time. And as you can see, Paul Johnston said there'd be some overhead because the sprite would be changing size each frame of the animation to accommodate the changing image sizes, but that it shouldn't be noticeable.

Oh, I'm also assuming I'll need to do something with the Sprite's offset point because it would look spastic pinned to the top-left corner. I'll post more once I have a chance to work with it, or someone far more experienced might comment