Lightweight AnimatedImage Library

I've added an isComplete() function to AnimatedImage. However, this will always return false for looping animations.

2 Likes

Thanks so much! While a minor thing, I'm looking forward to replacing this in my code :slight_smile:

if self.coinExplode:getFrame() >= 7 then
1 Like

Added this function, thanks. :slight_smile:

1 Like

Also just noticed how you're using getImage() in the sprite example. Though this works fine, you could also just pass in the animated image directly as it is designed to act as a proxy to the current frame's image, which is the whole point of the class: graphics.image but animated. :slight_smile:

1 Like

While you're here in the thread Dustin, I took your assertion above of "image but animated" literally and tried using it with :setImage() on a sprite, but no dice. Is getting it working with sprites via this method way outside the scope of this, or something viable in future?

I have zero idea how hard this is. Just wishing Playdate SDK had better built in stuff for handling animated sprites :slight_smile:

Oh that makes sense now that I think of it. I suppose any part of the API where the lua object is handed off to C this may not work. It works when Lua code expects an image and calls image methods on the AnimatedImage object, but if it gets handed over via C and C is casting to a graphics.image object, this will probably.

Good point. Thanks!

:slight_smile:

Brought this into AnimatedImage. Also made it so you can simply pass in an image table if you have one already loaded—which you may if you are thinking about using the sequence param where you can now select individual frames from a larger image table.

Thanks! Good add.

1 Like

Definitely sense-check this, but it seems like isComplete() is returning false when the animation is complete, when I'd expect it to return true?

function AnimatedImage:isComplete()
	return self.loop:isValid()
end

should this be:

function AnimatedImage:isComplete()
	return not self.loop:isValid()
end
1 Like

You know, sometimes you think you're good enough to just write some code and commit without testing. Then the world slaps you in the face and says "NO."

Anyway, should be fixed. Thanks. :stuck_out_tongue:

3 Likes

All good, thank you. I thought I was going insane there for a minute. :smiley:

isComplete seems like a valid state to me. :wink:

1 Like

false. I mean true. :wink:

Reviving this thread with another question. I'm currently trying to use this library to draw an animated trail, where an animatedImage is drawn each frame at the previous position, animates, and is removed when completed.

When I add an instance of the AnimatedImage, I need to call :reset() on it, otherwise it plays from the last frame that the previous instance of it was up to.

If I have a single AnimatedImage, but it's displayed in multiple places on screen, when I call :reset() on it to start the animation from the first frame, all instances reset, and nothing ends up animating (as it's reset every frame).

To get around this, I'm calling a completely new copy of AnimatedImage.new with different instance names, and resetting the animation per-instance when I do so. The problem here is the performance is awful, as it's creating completely new image tables each frame (I think).

Does this make sense, and can you think of any ways to improve the performance of this type of use of the library, or do I need to start over with animated sprites or something?

Thanks :slight_smile:

You can create your own image table instance and pass it in as the path parameter instead of the path to the file and it’ll forego loading rock disk and just use that table. The options param has a few things that should help, like first and last though you can set the frame to start from manually too.

Hope this helps.

Thanks for the response, I'll try setFirstFrame() first and see if there's any improvement, and go to a custom image table from there if there isn't. Cheers!