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

Author Topic: sf::Rect<> design question  (Read 5822 times)

0 Members and 1 Guest are viewing this topic.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
sf::Rect<> design question
« on: April 28, 2009, 10:56:01 pm »
Hi,

Is there a special reason to store the coordinates of the right and lower edge inside the sf::Rect class template? In my opinion width and height might be more intuitive. For example, you could use unsigned types for both and wouldn't have to assure that the right/down coords are bigger than the left/top ones. Additionally, the (from my point of view) often used width and height can be accessed faster. I know, performance of a subtraction is not really relevant, but consider more complex classes being used as template-argument T. Offset would be easier to calculate, too, and the effort of changing raw literals of image subrects would shrink.

I know, changing the sf::Rect structure is not possible at all, since it would break most SFML code up to now. That's not very tragic, one can easily build wrapper classes or utility functions. Nevertheless, I am wondering what was the crucial point for this design choice. ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
sf::Rect<> design question
« Reply #1 on: April 28, 2009, 11:06:36 pm »
Quote
In my opinion width and height would be more intuitive

I don't think so. They would be more intuitive in the situations you have in mind, but I can give you as many examples in favor of the current way of handling coordinates. The fact is that you'll always find people unhappy about a design choice when more than one solution is available.

Quote
For example, you could use unsigned types for both and wouldn't have to assure that the right/down coords are bigger than the left/top ones

So the current method is more flexible, as it allows reverted rectangles ;)
This is actually useful if you want to define a flipped sf::View, for example.

But to me the most relevant point is that with your solution, sf::Rect would store two kinds of coordinates: a position and a size. So to be perfectly right, it would have to use two template parameters. This is not obvious with primitive types such as int or float, but what if you use a more complex type T as you mentioned? T may not be able to represent both concepts.
With the current implementation, T is a "position" coordinates for all members, and that's it.

My conclusion is that you can easily write your own functions / classes to get a sf::Rect from whatever using a width and a height, so go ahead ;)
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
sf::Rect<> design question
« Reply #2 on: April 28, 2009, 11:26:48 pm »
Quote from: "Laurent"
I don't think so. They would be more intuitive in the situations you have in mind, but I can give you as many examples in favor of the current way of handling coordinates. The fact is that you'll always find people unhappy about a design choice when more than one solution is available.
Yes, that was only my view. I am not aspiring any alteration, but rather trying to reproduce the choice of the current sf::Rect design. I am aware of the fact every decision makes some people happy and some not. If you have got some time, it would be nice to see some of the examples you mentioned.

Quote
So the current method is more flexible, as it allows reverted rectangles ;)
This is actually useful if you want to define a flipped sf::View, for example.
Okay, that is a point I haven't thought of. But I don't guess a rect like this is used often, is it? In contrast to SubRects of Sprites, for example.

Quote
But to me the most relevant point is that with your solution, sf::Rect would store two kinds of coordinates: a position and a size. So to be perfectly right, it would have to use two template parameters. This is not obvious with primitive types such as int or float, but what if you use a more complex type T as you mentioned? T may not be able to represent both concepts.
With the current implementation, T is a "position" coordinates for all members, and that's it.
But by strictly following this argumentation, the member functions GetWidth() and GetHeight() should return a type other than T, namely a difference type. This is not the case at the moment. But to be honest, I can't imagine a graphical use of a sf::Rect where position and difference are not compatible to each other. I know the concept from other things like pointers or iterators, still I can't apply this on graphical rectangles. Maybe I have just got too few fantasy... ;)

Quote
My conclusion is that you can easily write your own functions / classes to get a sf::Rect from whatever using a width and a height, so go ahead ;)
As I wrote, that's not the problem. I am already partially doing it like this. It's more a theoretic discussion, I hope you don't mind wasting time for something that won't affect the SFML library. :)
(You can consider it a variation to feature and help requests ;))
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
sf::Rect<> design question
« Reply #3 on: May 03, 2009, 01:55:34 am »
Hmm... It would be nice if someone could comment this topic. I'd also like to know what other users think about sf::Rect.

All opinions are welcome... :)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
sf::Rect<> design question
« Reply #4 on: May 04, 2009, 11:04:30 am »
I like the current design. A rectangle is built of 4 points, therefore Left/Top/Right/Bottom seems to be perfect in my opinion.

What *could* be added are methods like SetHeight() and SetWidth() (as counterparts to GetHeight() and GetWidth()) that only change Right and Bottom. But I guess it's not really important, since you can easily archive that by adding values by yourself.

Astrof

  • Full Member
  • ***
  • Posts: 135
    • View Profile
sf::Rect<> design question
« Reply #5 on: May 04, 2009, 01:44:04 pm »
I know at first I was confused by the four point scheme as opposed to the origin + width/height.  But to fix it all I did was add the width and height to the origin points anyway...

I guess it depends what previous library or language you come from.  

I also agree that a SetHeight and SetWidth could be added; for now I just create new rects with the desired width and height...inefficient...i know...

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
sf::Rect<> design question
« Reply #6 on: May 04, 2009, 04:57:34 pm »
Thanks a lot for the answers! I nearly gave up hope... :)

Quote from: "Tank"
I like the current design. A rectangle is built of 4 points, therefore Left/Top/Right/Bottom seems to be perfect in my opinion.
Okay, I can comprehend well this might be more intuitive for a lot cases. Probably, I only noticed the situations where a width/height would fit better. Quite possibly, the other way I'd have the same problem. ;)

About SetWidth/SetHeight: I think it's no big deal to write a function template like the following. Or is it the calling syntax you don't like (non-member-function)?
Code: [Select]
template <typename T>
void SetWidth(sf::Rect<T>& Rect, const T& Width)
{
    Rect.Right = Rect.Left + Width;
}


Laurent, you still didn't anwer the conceptional problem of position/size-types. To be strict, GetWidth() and GetHeight() should be forbidden, shouldn't they? Or did I misunderstand you?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
sf::Rect<> design question
« Reply #7 on: May 04, 2009, 05:14:31 pm »
Quote
Laurent, you still didn't anwer the conceptional problem of position/size-types. To be strict, GetWidth() and GetHeight() should be forbidden, shouldn't they? Or did I misunderstand you?

You caught me ;)
You're right, the problem is the same in both implementations so I guess we can forget about this point.

My personal point of view about this discussion is that the best rectangle class you'll ever have is the one you write. I could make a bloated one (like the QRect class in Qt) so that everyone is happy... except me.
Users who really care about this rectangle class may just design their own one and make it convertible from/to sf::Rect, it's easy enough to do.

However I'm not against minor changes such as the SetWidth/SetHeight functions. I'll think about it ;)
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
sf::Rect<> design question
« Reply #8 on: May 04, 2009, 07:35:11 pm »
Thank you for your statement, Laurent.

In fact, I am really glad your classes are not that overloaded. If you want to add functionality to a class (more exact struct), you can also think about creating global functions instead of member functions, similar to the sf::Vector2 operators.

By the way, a sf::Rect::SetWidth() function should be considered carefully. I don't know how useful it really is or if it would just bloat the class interface again. And an own solution via global function is written in a minute. Just keep this in mind... ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
sf::Rect<> design question
« Reply #9 on: May 04, 2009, 07:39:41 pm »
I'm glad to see that we share the same philosophy for designing classes :)
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
sf::Rect<> design question
« Reply #10 on: May 05, 2009, 06:10:57 pm »
Quote from: "Nexus"
And an own solution via global function is written in a minute. Just keep this in mind... ;)


I share that opinion *mostly*. What you also should keep in mind is that SFML is a generic multimedia library, where all those little helpers should take place, instead of enforcing 80% of the users to write their own additions. Don't get me wrong, things that users post about are mostly really too specific. But others aren't, so the sentence "It's easy to write it yourself" is sometimes absolutely misleading IMHO.

To keep on topic: I like the current sf::Rect, but wouldn't whine if it would get SetWidth() and SetHeight(). Those aren't btw. more dangerous than GetWidth() and GetHeight(), because they're counterparts.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
sf::Rect<> design question
« Reply #11 on: May 05, 2009, 10:43:36 pm »
Quote from: "Tank"
But others aren't, so the sentence "It's easy to write it yourself" is sometimes absolutely misleading IMHO.
I didn't mean it shouldn't be part of SFML because one can write it fast oneself. Rather, I actually don't see many use cases, but I can be wrong as well. For example, I use GetWidth() very often, while I initialize the sf::Rect mostly by its constructor and set the edges with absolute positions. But maybe some other SFML users should comment this, too... ;)

The other point is that more member functions like SetWidth() tend to expand the sf::Rect class to the class with all possibilities. This can especially become confusing when there is a member function to set the internal state, but no corresponding constructor to initialize it in this way. So the width-height-concept is supported a little bit more, but not strictly enough. For those cases a wrapper class would be more convenient, in my opinion.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
sf::Rect<> design question
« Reply #12 on: May 05, 2009, 11:10:21 pm »
Quote from: "Nexus"
For those cases a wrapper class would be more convenient, in my opinion.

Very good idea in my opinion.

 

anything