Messages

1

General discussions / sf::Rect modifications in SFML 2 (important!)

« on: April 21, 2010, 04:58:26 am »

Woohoo

2

Graphics / Maybe a problem with Rect intersections

« on: October 18, 2009, 04:01:14 am »

Well, I was on the fence last night, but now that I've thought about it more, I suppose I am of the opinion that all of the functionality of a class should be contained within that class, if possible. Of course ultimately it's up to Laurent how he'd like to structure his API, but I was under the impression that one of the main selling points of SFML was its object-oriented nature. Having a bunch of global functions, even if they're templated, seems like a step backwards from that. I personally don't have any issue with symmetric methods, but a global function could be symmetric as well. Intersect(a, b) vs. Intersect(b, a), for example. When faced with the question of whether these should be equivalent, it should be obvious that they are just by the definition of an intersection. Same with a.Intersects(b) vs. b.Intersects(a).

One thing I don't understand is your comment about how global functions can become part of the public interface. Do you mean a global Intersects() function would be able to be called by saying a.Intersects(b)? I also don't think I understand how having global functions would increase encapsulation vs. member functions. It seems to me like that would violate encapsulation, by requiring those global functions to be able to access the private data of a class to which they don't belong. I agree with your argument about genericity, but I could see a situation where a general function works for 90% of classes, but special cases must be made for the other 10%, and it becomes a big confusing mess of "exceptions" to the "rules".

I guess I should also take this time to say hello to everyone, since these are my first few posts here. Great job on the library, Laurent. I am very excited about the possibilities that I will have by using SFML. You and everyone else who's contributed to this project has done an amazing job so far. Keep up the good work!

3

Graphics / Re: Maybe a problem with Rect intersections

« on: October 17, 2009, 06:27:32 am »

The current implementation of Intersects() uses method 1, which can lead to serious problem. Imagine this case:

Code: [Select]


sf::Rect  a( 1, 1, 1, 1 );
sf::Rect  b( 1, 1, 1, 1 );
std::cout << a.Intersects( b ) << std::endl;


a and b are still valid rects (with width and height of 1; at least that should be the case. SFML currently calculates wrong sizes, but a bugfix is already in the pipeline as stated by Laurent in another thread) and should therefore (or better: must!) intersect because they're at the exact same position.

Just for clarity, if using exclusive coordinates, the intersect function should not return true if you pass it these rectangles. These rectangles would have a width and height of zero, and thus be invalid. Since they are invalid, they should not intersect because they have no area.

I also just noticed that the issue I found with Contains() was mentioned in another topic not too long ago, by Tank! So this is a known issue, but I believe the fix mentioned in that thread should be to change Contains(), not GetWidth() or GetHeight().

4

Graphics / Maybe a problem with Rect intersections

« on: October 17, 2009, 03:27:14 am »

What I'm about to say is based off of SFML 1.5, so if things have changed since that version please forgive me, but there seems to be some confusion about how rectangles should be represented by the sf::Rect object. Browsing through the code for the Rect class, I see conflicting uses. Here are the two options:

1) Inclusive Coordinates

The "right" and "bottom" members specify the bottom-right-most pixel that is included in the rectangle. So a Rect(0,0,1,1) would have a width of 2, and a height of 2, including four pixels, with the pixel at (1,1) being the bottom-right.

2) Exclusive Coordinates

The "right" and "bottom" members specify the bottom-right-most pixel that is outside the rectangle. So a Rect(0,0,1,1) would have a width of 1, a height of 1, and include only one pixel, (0,0).


Method 2 is commonly accepted as the standard way of representing a rectangle. Using this method simplifies things such as iterating over the points in a rectangle, or calculating its width or height. For this, all that needs to be done is to subtract the right from the left. If using inclusive coordinates, the width of the rect is (right-left+1), which is considered counter-intuitive. Using exclusive coordinates also makes SFML's intersect code work correctly. For your example, the rect (0,0,1,1) would encompass only one pixel at (0,0). The second rect (1,1,2,2) would also encompass only one pixel, at (1,1). These do not intersect, even though they at first appear to share a pixel. In reality, they do not share any pixels, because the bottom-right pixel of the first rect is not actually inside that rectangle. If the rectangles do not overlap, returning a Rect(0,0,0,0) would be correct with exlusive coordinates, since this rectangle would have a width and height of zero, and thus contain no pixels and be invalid.

In the sf::Rect class, GetWidth(), GetHeight(), and Intersects() all operate as if the rectangle is expressed in exclusive coordinates. However, Contains() appears to operate as if the rectangle is using inclusive coordinates. Instead of this:

Code: [Select]

return (X >= Left) && (X <= Right) && (Y >= Top) && (Y <= Bottom);
I believe it should be this:

Code: [Select]

return (X >= Left) && (X < Right) && (Y >= Top) && (Y < Bottom);

I strongly recommend that SFML continue to use exclusive coordinates, they make life easy. Either way, the class needs to be consistent in the method it uses to do calculations. I am also in favor of having a global Intersects() function, but I would also like to see the class continue to have its own Intersects() method as well.