Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - psSch

Pages: [1]
1
Or possibly?

union m_Origin {
    Vector2f absolute;
    enum {
        TopLeft,
        TopCenter,
        TopRight,
        MidLeft,
        ...
    } relative;
};

2
It's good to know that I'm not the only one who has considered this.

I noticed in your post that Laurent mentioned that this change couldn't be made to SFML. I'm assuming this meant he couldn't change the functionality of setOrigin() itself, which is very understandable.

I can see how this would be a very desirable feature, but I'm also having a difficult time coming up with an implementation that could provide this behavior and not break old code.

My first reaction would be to add setAnchor() alongside setOrigin(), and make m_Anchor a stored property. But then, methods such as setPosition() wouldn't know which member to base their manipulation off of.

My second would be to make m_Origin a computed property, but this would break old code because now everything is based on the origin, and my first snippet wouldn't behave the same if i was to change the string afterwards.

And finally, making m_Anchor a computed property puts us back at square one with nothing really different.

Hmm...

3
I was using the SFML just now and attempting to center a sf::Text object at the top of the screen, which was accomplished with the following:

text.setString("SFML");
text.setOrigin(text.getLocalBounds().width / 2, text.getLocalBounds().height / 2);
text.setPosition(WindowWidth / 2, WindowHeight / 10);
 

This was simple enough, but it's not very good if my text happens to change size, as the origin is no longer relevant for its intended purposes.

This left me wondering is why SFML's sf::Transformable objects do not have something along the lines of a setAnchor() method, which would be able to set a relative point instead of an absolute for object manipulations. This way, users would be able to accomplish cleaner code that works for something like this:

// Anchor the text to it's center, then center the text.
// (0, 0) would be considered top-left, and (1, 1) bottom-right.
text.setString("SFML");
text.setAnchor(0.5, 0.5);
text.setPosition(WindowWidth / 2, WindowHeight / 10);

// The text's string changed, but the text is still centered at the top of the screen.
// In the first example, this would result in the text stretching off to the right.
text.setString("Hello, World!");
 

This method of manipulation is seen in other APIs such as Apple's SpriteKit. Would any of the authors know why this design decision was made, or if we could possible see features like this in the future?

Pages: [1]