sf::Clock overhead

[N1ghtly]

Hello,

I'm designing an AnimatedSprite class for my sprite engine and I've run into a little issue.
I'm thinking of overriding the draw() function to draw the sprite AND automatically update the frame.

Now I'm thinking, is it madness to have an sf::Clock for every AnimatedSprite?
Because it would be very easy if you don't have to worry about updating the time for every AnimatedSprite.

[Laurent]

No it's not, sf::Clock is internally just a Int64 and a system call.

[Nexus]

I'm thinking of overriding the draw() function to draw the sprite AND automatically update the frame.

That's not a good idea, drawing shouldn't alter the object, for example one might draw it multiple times (maybe to different places). This is also expressed in code; sf::Drawable::draw() is const.

Now I'm thinking, is it madness to have an sf::Clock for every AnimatedSprite?

Not because of performances, but it strongly limits the use cases. With clocks, you cannot interrupt the animation, that is a game pause is not possible.

[N1ghtly]

Ahh didn't think about that!

Code: [Select]

void update(sf::Time frameTime)it is then!

[Lo-X]

Ahh didn't think about that!

Code: [Select]

void update(sf::Time frameTime)it is then!

I don't know how big (in memory) is the sf::Time class, I think this is small but prefer a reference or a const reference since I'm sure this is smaller =)

[Laurent]

Nop: it's only a Int64, so even if it's bigger than a pointer on 32-bits systems, it's still faster to pass by value (no dereferencing, etc.).

N1ghtly just followed SFML, which passes all its sf::Time instances by value.

[Lo-X]

Nop: it's only a Int64, so even if it's bigger than a pointer on 32-bits systems, it's still faster to pass by value (no dereferencing, etc.).

N1ghtly just followed SFML, which passes all its sf::Time instances by value.

Really ? To pass a 64bit value is faster than 32 reference ?
I need better C++ courses oO

[Laurent]

Well, this conclusion is not obvious, in fact it depends on many parameters.

This article is very interesting and detailed:
http://www.macieira.org/blog/2012/02/the-value-of-passing-by-value/

[Nexus]

Do not forget that -- although you don't see it in code -- references need to be dereferenced, which also has a cost.

In fact, sf::Vector2f should also be passed by value
(It also makes the syntax nicer and prevents API changes, for example if a returned const sf::Vector2f& that refers to a member is replaced by a copy to a local object).

Side note: Already with the old standard, yet more with C++11, some situations encourage to pass even big objects by value.
C++Next: Want speed? Pass by value