Rect class

[mitchgc]

I've already changed Rect.Left and Rect.Top to Rect.X and Rect.Y respectively, but want to change Rect.Right and Rect.Bottom to Rect.W and Rect.H respectively. I'm doing this because I'm attempting to replace SDL with SFML in my library and can't stand using Left/Top/Bottom/Right - especially since Bottom and Right could be less than Left and Top and hence have to have special code to deal with that all over the place.

My question is if there is any code in SFML that deals with the event of Bottom/Right being less than Left/Top, or if there are any special places I should take care with when replacing these members.

Cheers.

[Nexus]

I've already changed Rect.Left and Rect.Top to Rect.X and Rect.Y respectively, but want to change Rect.Right and Rect.Bottom to Rect.W and Rect.H respectively. I'm doing this because I'm attempting to replace SDL with SFML in my library and can't stand using Left/Top/Bottom/Right

You shouldn't do such things just to keep your habits. SFML is different from SDL (far more than just other member names), so you have to adapt quite a lot – not only formal, rather semantic points.

If you change the SFML library code, you have to change it every time you update to a new version. Besides, your code becoms incompatible to other users. Additionally, you are making the lives of the people responding in the forum difficult when you don't adhere to the SFML identifiers. You should really not try to frantically program SDL in SFML, the many disadvantages aren't worth it.

[mitchgc]

I've already changed Rect.Left and Rect.Top to Rect.X and Rect.Y respectively, but want to change Rect.Right and Rect.Bottom to Rect.W and Rect.H respectively. I'm doing this because I'm attempting to replace SDL with SFML in my library and can't stand using Left/Top/Bottom/Right

You shouldn't do such things just to keep your habits. SFML is different from SDL (far more than just other member names), so you have to adapt quite a lot – not only formal, rather semantic points.

If you change the SFML library code, you have to change it every time you update to a new version. Besides, your code becoms incompatible to other users. Additionally, you are making the lives of the people responding in the forum difficult when you don't adhere to the SFML identifiers. You should really not try to frantically program SDL in SFML, the many disadvantages aren't worth it.

I can understand where you're coming from, and I expected similar replies. What do you suggest for the problem I mentioned regarding Bottom/Right being less than Left/Top if I were to take your advice and not change members?

Why were the members chosen to be as they are? What advantages were seen over using the conventional and much easier X/Y/W/H?

[Calmatory]

I agree, X,Y & W,H sounds much more practical to my ear. Considering that I haven't really dealt with rects since I switched to SFML from SDL, my opinion could be a bit biased.

[Laurent]

Bottom and Right can be less than Top and Left in SFML. There's no problem with that.

You have the same problem with Width/Height with float coordinates: they can be negative. So that wouldn't really solve anything (if there was anything to solve).

By the way, sf::Rect is now defined as Left/Top/Width/Height in SFML 2.

To answer the question "why?", there's no answer. Each definition will be more or less relevant according to the context, sometimes you want Width/Height, sometimes you want Bottom/Top. There isn't one which is "better" than the other.

[mitchgc]

Bottom and Right can be less than Top and Left in SFML. There's no problem with that.

You have the same problem with Width/Height with float coordinates: they can be negative. So that wouldn't really solve anything (if there was anything to solve).

When you're working with a rectangle and the start and end points (TL, BR) matter, there is something to solve. You have to switch them around  for certain algorithms where location is important. I can't think of an example off the top of my head, but I have come across it many times in my 2D programming.

By the way, sf::Rect is now defined as Left/Top/Width/Height in SFML 2.

That's great news... I wish I knew that before I went crazy on the earlier version haha. When is it due out?

To answer the question "why?", there's no answer. Each definition will be more or less relevant according to the context, sometimes you want Width/Height, sometimes you want Bottom/Top. There isn't one which is "better" than the other.

I disagree here. From my experience, width/height is a lot easier to use and is natural for more situations.

[Laurent]

When you're working with a rectangle and the start and end points (TL, BR) matter, there is something to solve. You have to switch them around for certain algorithms where location is important

How different is it from rectangles with negative width/height?

That's great news... I wish I knew that before I went crazy on the earlier version haha. When is it due out?

No idea, hopefully soon

I disagree here. From my experience, width/height is a lot easier to use and is natural for more situations.

From your experience. Which is not the same as other users.

[mitchgc]

When you're working with a rectangle and the start and end points (TL, BR) matter, there is something to solve. You have to switch them around for certain algorithms where location is important

How different is it from rectangles with negative width/height?

I've never needed to have negative widths/heights, but I can see your point.

I disagree here. From my experience, width/height is a lot easier to use and is natural for more situations.

From your experience. Which is not the same as other users.

Evidently, though I thought it might be useful as feedback? It must be a common usage amongst users if you're changing it?  :wink:

[Laurent]

Evidently, though I thought it might be useful as feedback?

It is, thank you

It must be a common usage amongst users if you're changing it?

This is not the reason, actually. I changed it because with Right/Bottom it is not clear whether the last point is included or not in the rectangle, it brought a lot of confusion.

[mitchgc]

It must be a common usage amongst users if you're changing it?

This is not the reason, actually. I changed it because with Right/Bottom it is not clear whether the last point is included or not in the rectangle, it brought a lot of confusion.

Not sure what you mean by this, but it is possible that this is what I meant by "less than"...

[Laurent]

No

In SFML 1.6, when you write

Code: [Select]

sf::IntRect rect(0, 0, 10, 10);
It's not clear if the pixel at coordinates (10, 10) is included or not in the rectangle. You may think that it is, but in fact it is not. And it was kind of weird because (0, 0) is included.
This is natural for people used to the STL containers where begin() is the first element and end() is one past the last element, but this remains confusing for most people.

In SFML 2 it is clearer because you know that if width == 10, the last pixel contained in the rectangle will be at coordinate 9 (if left is 0).

[mitchgc]

No

In SFML 1.6, when you write

Code: [Select]

sf::IntRect rect(0, 0, 10, 10);
It's not clear if the pixel at coordinates (10, 10) is included or not in the rectangle. You may think that it is, but in fact it is not. And it was kind of weird because (0, 0) is included.
This is natural for people used to the STL containers where begin() is the first element and end() is one past the last element, but this remains confusing for most people.

In SFML 2 it is clearer because you know that if width == 10, the last pixel contained in the rectangle will be at coordinate 9 (if left is 0).

That's odd. I'd have thought that since you're specifying a position and not width, it'd be inclusive. I am looking forward to seeing 2.0... I guess I will just wait until it is released before I go any further? By "soon" do you mean a couple of months or a few weeks?

[Laurent]

I mean a couple of months. But you can already use it, it is very stable. The only thing is that some parts of the graphics API may change before the final release.

[mitchgc]

I mean a couple of months. But you can already use it, it is very stable. The only thing is that some parts of the graphics API may change before the final release.

Sweet.