Vector2f vs FloatRect

[Laurent]

Because I think there should be a distinction between points and sizes. A size should never be negative, whereas the members of a point could (and because to me "vector" is not enough explicit). I know explanations have been given about negative size (allows inverted object drawing) but I think this is short and simple solution, but absolutely not an intuitiv one.

There no use of negative sizes to mirror objects in SFML. All integer sizes already use unsigned integers (whether they use sf::Vector2 or not), and float ones well... I can't do anything

I prefer OpenGL naming convention, thus if I was the only one to be asked, SFML would already follow this convention

What "OpenGL naming conventions" are you talking about, apart from the name{dim}{type} one?

[Ceylo]

There no use of negative sizes to mirror objects in SFML. All integer sizes already use unsigned integers (whether they use sf::Vector2 or not), and float ones well... I can't do anything

I'm not sure we're talking of the same thing, Rect is defined by Left, Top Right and Bottom, thus Left can be greater than Right, same thing for Top and Bottom. What's the behaviour in these cases ?

I prefer OpenGL naming convention, thus if I was the only one to be asked, SFML would already follow this convention

What "OpenGL naming conventions" are you talking about, apart from the name{dim}{type} one?

Lowercase for the first letter of methods (yeah I know a lot of people do not like this) and variables, short names rather than fully explicit names (ie Rect instead of Rectangle, and not only for this case!) without using hungrian naming though. I need to have a closer look at SFML interface to tell you more, but that's already part of the thing.

I agree using short naming is discussable, but until it involves confusion, it's quicker to type and use (to my mind).

[Laurent]

What's the behaviour in these cases ?

For what usage of rectangles?

Lowercase for the first letter of methods

Well, it's mainly because every function has the "gl" prefix.

yeah I know a lot of people do not like this

I like it (if I could change the whole naming convention for SFML I'd do it this way) :lol:

short names rather than fully explicit

I'll never use short names. There's just no reason to use short names (with auto-completion nobody ever writes full names), and many good reasons to use long ones

[Ceylo]

What's the behaviour in these cases ?

For what usage of rectangles?

For example with sf::Sprite::SetSubRect() ? Will the image appear inverted ?

Lowercase for the first letter of methods

Well, it's mainly because every function has the "gl" prefix.

I think it'd be the same kind of typo even without this prefix.

yeah I know a lot of people do not like this

I like it (if I could change the whole naming convention for SFML I'd do it this way) :lol:

Does it mean you can't ?

short names rather than fully explicit

I'll never use short names. There's just no reason to use short names (with auto-completion nobody ever writes full names), and many good reasons to use long ones

Okkay .

[Hiura]

Lowercase for the first letter of methods

Well, it's mainly because every function has the "gl" prefix.

I think it'd be the same kind of typo even without this prefix.

We can assume sf:: as a prefix.

[Laurent]

We can assume sf:: as a prefix.

Absolutely
I think prefixes / namespaces are a different naming convention than function and variable names.

For example with sf::Sprite::SetSubRect() ? Will the image appear inverted ?

No, such a rectangle is not valid. But it's impossible to ensure with a structure storing left/right/top/bottom. It would be possible only with width/height, and only for integer based rectangles.

Does it mean you can't ?

I think so. But I'm tempted

[Hiura]

Does it mean you can't ?

I think so. But I'm tempted

IMO you should do it. S(T)L do it that way. So why not SFML ?

[nitram_cero]

Nothing to do with this topic but, I think sf::String should be called sf::Text.

Classes named "string" are usually meant to handle character arrays in software, and have nothing to do with rendering and viewing.

"Text" or "Label" are usually used for viewable GUI elements.

It's funny because the way of setting a string to sf::String is SetText.
I think it should be the other way around (sf::Text::SetString())


What do you think?

-Martín

[Laurent]

IMO you should do it. S(T)L do it that way. So why not SFML ?

It would be more the Qt style rather than STL/boost one.

Nothing to do with this topic but, I think sf::String should be called sf::Text.

Probably

Well, it seems that the discussion is sliding towards "global naming conventions in SFML"

Unless someone has a good argument for keeping everything like it is (that I could understand), I'm opened to any suggestion. Enjoy it, I won't do this again in the future :lol:

[Ceylo]

For example with sf::Sprite::SetSubRect() ? Will the image appear inverted ?

No, such a rectangle is not valid. But it's impossible to ensure with a structure storing left/right/top/bottom. It would be possible only with width/height, and only for integer based rectangles.

So why isn't a Rect composed of these two members ?

Does it mean you can't ?

I think so. But I'm tempted

Reminds me something :roll:

Well, it seems that the discussion is sliding towards "global naming conventions in SFML"

Unless someone has a good argument for keeping everything like it is (that I could understand), I'm opened to any suggestion. Enjoy it, I won't do this again in the future :lol:

Woooot ! *goes have a look at the whole SFML interface*

[Laurent]

So why isn't a Rect composed of these two members ?

Because I wouldn't be able to use unsigned int size + int position, unless IntRect is a separate class from FloatRect rather than an instanciation of the same template.

Reminds me something

What?

[nitram_cero]

I like the current Vector/Rect notation because is verbose as the rest of the library functions (But not in an extreme way).

I always liked the Open*L notation, so 2f is the clearest way to tell me that it has 2 floats. As the basic types are lower case, the letter should be to. Also, the capital D is used for other meanings, like glTexImage2D (2 dimensions, not 2 floats .

FloatVector2 seems to long to me. But you can always typedef to whatever makes you happy. An umbrella header is the easiest approach.

I'm more ok with the verbose versions that "Rectf/Recti" that sounds (in the later) like a latin conjugation for ASS :lol:

For these almost-basic algebraic types I like verbosity but when It doesn't exceed a length of about 10 characters. After that it starts bloating the source code and looks like crap.

Well, happy ranting to the rest xD

Regards
-Martín

[nitram_cero]

So why isn't a Rect composed of these two members ?

Because I wouldn't be able to use unsigned int size + int position, unless IntRect is a separate class from FloatRect rather than an instanciation of the same template.

You could having a signed/unsigned typenames in the template and then using uint/int & float/float.

But anyway, it's totally impractical. The subtraction between two int/float numbers is extremely fast (them being cached in the CPU).

If it really makes a difference for a user, then he/she should keep the data duplicated within his own structure.

[Ceylo]

So why isn't a Rect composed of these two members ?

Because I wouldn't be able to use unsigned int size + int position, unless IntRect is a separate class from FloatRect rather than an instanciation of the same template.

It's rather annoying, because I would have like to access to the size and position members like I do for x and y. Hmm.. we have GetWidth() and GetHeight() that should be replaced with GetSize() as you mentionned on the previous page. It would be fine to also have something like GetOrigin() returning the top left point.

Reminds me something

What?

What you know about the packages .

I like the current Vector/Rect notation because is verbose as the rest of the library functions (But not in an extreme way).

So don't you think it should be Vector/Rectangle (or Frame ?) ? It does look more logical to me.

[heishe]

vector2f + rectf; you can write these names in a continous flow as you type in the characters on your keyboard. if you do something like vector2F, it puts a shift in the name which makes it kinda more uncomfortable to write.