Animated sprite in SFML

[Xander314]

I'm planning a little animated sprite class for SFML. I think it makes sense to inherit from sf::Drawable or sf::Sprite (the first seems nicer in theory, but I think the second might work better, or at least more easily, in practice).

Anyway, I have two little questions to help me decide on implementation.

1. Is there much of a performance difference between loading lots of small textures as opposed to one large one?
2. Is either of sf::Sprite::SetTexture or sf::Sprite::SetSubRect likely to be significantly faster (I don't know if this question can be easily answered, if not I guess I could use a profiler if I really wanted to...)

Thanks,
Xander

[Elgan]

One texture is better

I think a tool which packs them, and prints our an xml with the frames. I read this into sections..

animations, and their frames. and single images.

that way I can pack all the anims for a "character" in to one image... Then with that image, I can load and split it into animations which have their set frames, .ie....run, jump, walk...etc....Then I can select which animation I want to run.

I didnt inherit, but I havent used it for more than loading and parsing, testing at the moment..


Hope this helps, though I am terrible at explaining.

Code: [Select]



<?xml version="1.0" encoding="utf-8" ?>
<sprite src="character.png">
<animnation name="down"  loop="true">
<frame name="down_1" x ="0" y="0" w="16" h="32"/>
<frame name="down_2" x ="17" y="0" w="16" h="32"/>
<frame name="down_3" x ="34" y="0" w="16" h="32"/>
<frame name="down_4" x ="51" y="0" w="16" h="32"/>
</animnation>
<animnation name="left" loop="true">
<frame name="left_1" x ="68" y="0" w="16" h="32"/>
<frame name="left_2" x ="85" y="0" w="16" h="32"/>
<frame name="left_3" x ="0" y="33" w="16" h="32"/>
<frame name="left_4" x ="17" y="33" w="16" h="32"/>
</animnation>
<animnation name="right" loop="true">
<frame name="right_1" x ="0" y="66" w="16" h="32"/>
<frame name="right_2" x ="34" y="33" w="16" h="32"/>
<frame name="right_3" x ="17" y="66" w="16" h="32"/>
<frame name="right_4" x ="51" y="33" w="16" h="32"/>
</animnation>
<animnation name="up" loop="true">
<frame name="up_1" x ="34" y="66" w="16" h="32"/>
<frame name="up_2" x ="68" y="33" w="16" h="32"/>
<frame name="up_3" x ="51" y="66" w="16" h="32"/>
<frame name="up_4" x ="85" y="33" w="16" h="32"/>
</animnation>
<image name="head" x ="68" y="66" w="16" h="16"/>
</sprite>



[Nexus]

I think it makes sense to inherit from sf::Drawable or sf::Sprite (the first seems nicer in theory, but I think the second might work better, or at least more easily, in practice).

I don't think inheriting from sf::Sprite makes much sense, since some methods become useless and confusing in a derived class. For example, what would SetTextureRect() do? Since an animation contains multiple frames, each of them might refer to a different texture rect.

One possibility is to use a custom class derived from sf::Drawable, and equip it with the methods necessary for animations. Or a non-intrusive approach that just modifies one or multiple existing sprites, using a separate animator class that stores the animation progress.

I chose the latter design in my Animation API in Thor. You could have a look at it -- even if you find it completely useless, I'd be very happy about some feedback

1. Is there much of a performance difference between loading lots of small textures as opposed to one large one?

Using a large texture with multiple rects tends to be faster, because you don't have the texture switches. But too large textures might not be supported by your graphics card.

[HKei]

You think it makes sense to say "An animation is a sprite"?

[Xander314]

Hope this helps, though I am terrible at explaining.

No, that's okay. I see what you mean. It will be good to design a good way of packaging animations, but I think I'll get the animation itself working first...

non-intrusive approach that just modifies one or multiple existing sprites

That's an interesting approach, and certainly one of the neater ones I should think. I'll take a look at Thor when I have a minute - looks like a pretty cool library in general! However, for my own animation class, I want to make it -- in the name of object oriented-ness -- a single self contained class if possible.

However, it's tricky. As you say, inheriting sf::Sprite will give you a load of unwanted member functions. The best approach would be to inherit from sf::Sprite and override those member functions, but they're not virtual in sf::Sprite, so it's not an option.

Option 2 would be inheriting from sf::Drawable. Then, if the animation has a sprite, all the position, colour, etc applied to the animation have to be duplicated to the sprite for drawing, which seems somewhat wasteful.

Finally, you could inherit from sf::Drawable and not have a sprite, but then you'd just end up re-implementing most of the sprite functionality in the animation...

Hmm... it's a difficult choice, I can see why you went for the `non-intrusive' option

What if I inherited sf::Sprite privately and just duplicated all the desired repeated functions with public inline 'proxy' functions which just called the corresponding private ones? If they were inline, there probably wouldn't even be performance loss that way. Mind you, RenderTarget is a friend of Drawable, so I guess this might break something...

You think it makes sense to say "An animation is a sprite"?

I think it makes sense to say ``an animated sprite is a sprite'' And that's exactly what I'm making, an animated sprite. That said, I don't think inheritance will work in practice.

[Elgan]

i inherited from drawables and transformables.

[Nexus]

The best approach would be to inherit from sf::Sprite and override those member functions

I don't think so. It's not the method's implementation which is flawed in an Animation class, but the interface. Calling AnimatedSprite::SetSubRect() or AnimatedSprite::SetTexture() doesn't really make sense, the intention behind animations is to abstract those properties away.

What if I inherited sf::Sprite privately and just duplicated all the desired repeated functions with public inline 'proxy' functions which just called the corresponding private ones?

Then you could as well have composition (sf::Sprite is a member). Or what advantage would private inheritance have?

Hmm... it's a difficult choice, I can see why you went for the `non-intrusive' option

It is generally more flexible. For example, an animation can be applied to multiple sprites (together or independently).

But the question is whether this flexibility is often used. Maybe it would be wiser to provide only something like AnimatedSprite, it seems to be more intutive for people. Or add it on top of the existing API... There are so many design possibilities, and I really like to hear other ideas.