Origins: Coordinates vs. fractions

[Nexus]

Hi, I would like to discuss something that just came to my mind. In SFML, the origins of graphical objects -- accessed with sf::Transformable::setOrigin() and sf::Transformable::getOrigin() -- are stored as coordinates in the local coordinate system, with same scale (but different origin) as the global coordinate system.

Have you ever considered a fractional approach instead? That is, origins that lie inside the object have values in [0, 1]. To get the coordinates, the origins are multiplied with the object size (retrieved via getLocalBounds()). I know this doesn't perfectly fit into the current sf::Transformable API, since size is not part of it, but it's more a general consideration.

The advantage of fractional values is the consequence that a texture's (or generally object's) size and origin become orthogonal properties, one doesn't depend on the other. Thus, it becomes very easy to express proportions. For example, a centered origin would be (0.5, 0.5), the right-upper corner would be (1, 0). On the downside, absolute distances are more difficult to express, like "10 pixels past the right border". But they depend already now on the local rect, one cannot make them orthogonal properties anyway.

[eXpl0it3r]

If such functionality would get implemented, would you change the interfaces completly or provide the in addition?

I guess for many beginners the coordinate-way is a bit more intuitive.

[Nexus]

If such functionality would get implemented, would you change the interfaces completly or provide the in addition?

You have to decide which one is used by the implementation.

If you leave it as it is, you can of course still implement a function which takes a ratio and adjusts the origin according to it, but you have to call it again and again -- everytime the object's size changes.

If you take the fractional approach, you can set the ratio once and it is preserved, independently of the object's current size. This implies that you can set the origin even before you know the size. The two attributes are orthogonal to each other.

I guess for many beginners the coordinate-way is a bit more intuitive.

I don't know how other people use it, but for me, I most frequently set the origin to an object's center. And I find

object.setOrigin(0.5f, 0.5f);

far more intuitive than

sf::FloatRect rect = object.getLocalRect();
object.setOrigin(rect.Width / 2.f, rect.Height / 2.f);

[Laurent]

That's an interesting approach but I can't change SFML like this. The best I can do is to provide functions that let users write both ways easily and shortly.

[Omegaclawe]

Making this the standard would be... bad. It would still require the calculations, so in any situation where such an approach would not be useful, you've added time complexity. On top of that, using floating points that are merely between 0 and 1 would result in an overall decrease in accuracy and memory efficiency, as numbers greater than 1 and less than 0 would be, in most cases, useless. Potentially, you could use an integer as a percentage to get the full 4.3 billion possibilities as accuracy, but... more calculations would be required.

Does this really amount to much? Probably not. Linear additions to complexity are typically considered ignorable when non-linear complexity is in use. Still shaves off a bit of performance, though... and makes for somewhat uglier code.

Best to Keep it Simple, in the library. There's nothing stopping you from implementing a class or recoding the library to do it your way, but I doubt it'd provide you with anything more than a way to be lazier with easy code... and perhaps slightly more intuitiveness, but that's not necessarily a good thing.

In fact... actually, I challenge you to implement this. It'd be a great way to learn why the thing is the way it is.

[Nexus]

That's an interesting approach but I can't change SFML like this.

Do you mean you don't want to change the current API anymore because it's in RC state, or do you see technical limitations?

The best I can do is to provide functions that let users write both ways easily and shortly.

How do you imagine that? As mentioned, a function like setOriginFraction() wouldn't be very useful, it would have to be called all the time. So the user could as well write his own global function.

On top of that, using floating points that are merely between 0 and 1 would result in an overall decrease in accuracy and memory efficiency, as numbers greater than 1 and less than 0 would be, in most cases, useless.

Don't forget that floating point numbers are denser when they are small. The fractional part becomes more accurate the smaller a float is.

Does this really amount to much? Probably not. Linear additions to complexity are typically considered ignorable when non-linear complexity is in use. Still shaves off a bit of performance, though... and makes for somewhat uglier code.

Don't you think the tiny performance overhead might be worth a more expressive API? And code gets "uglier" (which is slightly exaggerated) in the implementation, but may become more beautiful in the usage, which is more important in my opinion.

There's nothing stopping you from implementing a class or recoding the library to do it your way, but I doubt it'd provide you with anything more than a way to be lazier with easy code... and perhaps slightly more intuitiveness, but that's not necessarily a good thing.

Of course I can try to rewrite SFML, but this defeats the whole purpose of public discussions about design choices, which may give Laurent ideas to implement things differently in the future. And why shouldn't intuitiveness be a good thing?

[Laurent]

Do you mean you don't want to change the current API anymore because it's in RC state, or do you see technical limitations?

It's more a personal feeling

How do you imagine that?

For example, by providing helper functions to get the corners or center of an entity in a more direct and intuitive way than the current API.

[pdinklag]

Like an enum?

transformable.setOrigin(sf::anchorTopRight);
transformable.setOrigin(sf::anchorCenterLeft);
transformable.setOrigin(sf::anchorCenterCenter); //?
 

Providing 9 anchors would work IMO, Top, Center, Bottom x Left, Center, Right.

It'd be both intuitive and make many use cases (like centering) a lot shorter. And this could be a simple overload of setOrigin.

[Laurent]

Looks good. But it's still hard to integrate, because as Nexus said, sf::Transformable knows nothing about the size of the entity. And it would also have to know when this size changes, in order to adjust the coordinates of the origin in case it's not TopLeft.

[pdinklag]

Looks good. But it's still hard to integrate, because as Nexus said, sf::Transformable knows nothing about the size of the entity.

sf::Transformable does not know the size, but in reality, all sf::Transformable implementations do (sf::Shape, sf::Sprite and sf::Text all provide getLocalBounds and getGlobalBounds). It *could* be moved up the hierarchy, but since the size does not really have anything to do with the transform (the global bounds are only affected by it), that might be a bad choice.

And it would also have to know when this size changes, in order to adjust the coordinates of the origin in case it's not TopLeft.

Ah yes, this is a bigger problem. A protected method like "notifySizeChanged" that sets an update flag could solve this, but generally I hate approaches that require interface implementations to remember doing something... people will forget it, and spam the forum. Not sure if that's a problem in your consideration.

[Laurent]

The major problem is that I don't want SFML to be a framework with base classes and virtual functions to implement. I want a simple API with tool classes that can be used as building blocks for user classes.

I don't like sf::Transformable and sf::Drawable, but I had to find a compromise in SFML 2. Same for sf::Sprite, sf::Shape and sf::Text; providing textures, fonts and vertex arrays could be enough. But that's a different discussion that I don't want to have now, let's keep it for SFML 3

[Nexus]

sf::Transformable has regularly been a candidate for a base class in my projects, but sometimes I didn't like it because of the origin

For example, I think about encapsulating Thor's Particle class. It is now a structure with direct member access, and providing it with setters and getters would make it more uniform with SFML classes, so I can write generic functions that access properties more easily. Since a particle also has position, rotation and scale, making it transformable seems standing to reason. Not only would I have loads of getters and setter for free, but particles can interact better with functions that work with sf::Transformable and sf::Transform.

However, the origin property doesn't really fit into the Particle class in my opinion. It is rather a property of the particle system, together with the texture. The problem when each particle has its own origin is to initialize it correctly. I don't want the emitters to know about the origin (since this implies that every emitter implementation would have to forward the origin attribute manually to the particle, including user-defined ones). Furthermore, I think in the very most cases, all particles with the same texture have the same origin.

Or I forget about all this and provide an origin property to the particle system, leave Particle as it is, and write a bunch of global function overloads that can access SFML classes and particles uniformly

Any ideas or thoughts are welcome!

[Laurent]

Each particle has its own transform? Isn't it too heavy?

[Nexus]

At the moment, I store single attributes. sf::Transform is also inappropriate because it makes it difficult and expensive to extract the single components and to apply the transform for a delta time.

The class looks like this:

class Particle
{
    public:
        sf::Vector2f    position;
        sf::Vector2f    velocity;
        float           rotation;
        float           rotationSpeed;
        sf::Vector2f    scale;
        sf::Color       color;

    private:
        sf::Time        passedLifetime;
        sf::Time        totalLifetime;
};

Most of the attributes are required for more or less flexible particle effects. In facts, it might be more flexible, I consider adding mass or even user-defined data.

Do you think it's too heavy? Would you take a different approach?

[Laurent]

Do you think it's too heavy?

Nop, it looks good. But using sf::Transformable would probably be heavier.

But why are these properties publicly accessible? Aren't they updated internally by the particle emitter according to its global properties? (sorry, I have no idea how your API works )