Bézier curves

[Klaim]

I also think that it's surprising that there are threading features to SFML if I follow the logic of not adding anything other than basic building blocks of multi media library (and threading is anything but "simple").

This has already been discussed multiple times, and threads are only provided because they are needed in the SFML implementation. That's also the reason why requests for more elaborated multithreading features are constantly rejected.

When SFML ports its code to C++11 one day, sf::Thread will probably be removed.

Ok then, but was networking necessary too for SFML implementation?

Anyway my point was that adding value animation would not be a big addition nor would make SFML fat and is in my opinion the only really needed feature missing. However, it should not be automatic like in other frameworks which provide a main loop and everything is updated automatically. For SFML, just having the algorithms as wrapped values (or something similar) with an easy way to update them when needed would be enough.

[Nexus]

Do you have a concrete idea how such an API might look?

[Klaim]

I was thinking about it but got caught on something else. Give me some time to propose some example. Meanwhile, just think it would be just functions or callable objects that would update a value (either via ref or internal, which should be easier). I'll get back to this soon.

[Nexus]

Tweeners were once suggested for Thor, maybe the corresponding discussion might inspire you.

[Klaim]

Tweeners were once suggested for Thor, maybe the corresponding discussion might inspire you.

I believe a non-time-based solution would be far more generic (but a little less quick to use) for SFML itself than what is proposed there. Then in Thor you could easily plug things together to propose time-based tweeners.

[Nexus]

Thor's animations are not time based, only the front-end thor::Animator is. If you read a bit further, you see I proposed a std::function<float(float)> which is very generic. Maybe one could build something on top of that.

In Thor, the concept of an animation is as follows:

void animation(Animated& object, float progress);

This is quite generic, as it allows to animate an object using an arbitrary function that takes a float in [0,1]. You can use functions, functors, std::bind, or lambda expressions. Depending on what you need, you can implement an intermediate layer that transforms a progress range to another. For example, playing an animation in reverse can be done in a single line:

auto anim = ...; // animation function satisfying the concept
auto reverse = [anim] (sf::Sprite& s, float pr) { return anim(s, 1.f - pr); };

You might also want to read my design considerations. Maybe this can inspire you for an API...

[cpolymeris]

I was also thinking it could also be adapted to improve the text code, so the lines on it would look less blurred and more smooth and sharp!

Agree this would be A Good Thing^TM, and an excuse to say this code belongs into the SFML core. Would also potentially make the Font size (points) independent from the target's pixel size.

- p * p * p should be more efficient than std::pow(p, 3)

I'd find that surprising. I tend to assume people who write compilers are smarter than me.

[Mario]

- p * p * p should be more efficient than std::pow(p, 3)

I'd find that surprising. I tend to assume people who write compilers are smarter than me.

In the end, both should result in the same code, if optimized, so it shouldn't matter. However, if you don't specifically optimize your code (usually the case for debug builds), the explicit multiplication should be faster I'd guess.

[Laurent]

I'd find that surprising. I tend to assume people who write compilers are smarter than me.

I don't know if it can be optimized. The second argument is a double, so the function has to apply a generic algorithm which is much more complex than p * p * p. So unless pow maps directly to a built-in processor instruction, I don't know how your compiler would be able to make it as optimized as the explicit version.

But that's interesting, generate the ASM listing and compare

[Mario]

Despite it being defined as double, the compiler should be able to determine it being a constant integer value, so I've got hope there. Anyway, let someone... try it. *sneaks away*

[Laurent]

Despite it being defined as double, the compiler should be able to determine it being a constant integer value

And what? He "knows" that this is a function that computes a power, and apply its own optimized algorithm instead? This is just a function call, the compiler knows nothing about it.

[Mario]

I imagined the compiler could just consider the whole call for optimization, similar to how memset() can be optimized out, if the memory isn't accessed anymore later. But anyway, getting quite offtopic and out of scope here.

[binary1248]

I'd find that surprising. I tend to assume people who write compilers are smarter than me.

I don't know if it can be optimized. The second argument is a double, so the function has to apply a generic algorithm which is much more complex than p * p * p. So unless pow maps directly to a built-in processor instruction, I don't know how your compiler would be able to make it as optimized as the explicit version.

But that's interesting, generate the ASM listing and compare

double foo( double p )
{
        return std::pow( p, 10 );
}

double bar( double p )
{
    return p * p * p * p * p * p * p * p * p * p;
}

Code: [Select]

foo(double):
movapd %xmm0, %xmm1
mulsd %xmm0, %xmm1
mulsd %xmm1, %xmm0
mulsd %xmm1, %xmm0
mulsd %xmm0, %xmm0
ret
bar(double):
movapd %xmm0, %xmm1
mulsd %xmm0, %xmm1
mulsd %xmm0, %xmm1
mulsd %xmm0, %xmm1
mulsd %xmm0, %xmm1
mulsd %xmm0, %xmm1
mulsd %xmm0, %xmm1
mulsd %xmm0, %xmm1
mulsd %xmm0, %xmm1
mulsd %xmm0, %xmm1
movapd %xmm1, %xmm0
retThis was generated by GCC with -O2 -march=native. It seems the compiler is more intelligent than you might expect . The explicit multiplication generates as many machine operations as multiplications you perform. The std::pow() variant tells the compiler the base stays the same hence it can reuse the results of previous multiplications to reduce the number of machine operations required. Explicit multiplication is O(k) whereas std::pow() is O(log k) for p ^ k.
It groups
p * p * p * p * p * p * p * p * p * p to
( ( ( p * p ) * p ) * ( p * p ) ) * ( ( ( p * p ) * p ) * ( p * p ) ) which is
( ( ( p ^ 2 ) * p ) * p ^ 2 ) ^ 2

Maybe the word "intelligent" isn't as correct as "less conservative" as explained here. With -ffast-math both functions produce identical asm output (the shorter variant).

[Mario]

Very interesting (and very tricky). So it essentially groups the multiplications for pow() into repetitive patterns. But yeah, for short ones it wouldn't matter as well.

Still interesting to know. So it definitely parses the parameter rather than just passing it to something hardcoded.

[Laurent]

That's what I thought. binary1248 is faster than the compiler to produce ASM listings and prove me wrong

This is very interesting but I still wonder how the compiler does. So it's probably not an effect of generic optimization rules, but rather a hard-coded one (std::pow + integer arg = this specific code).