SFML 2.0 RC

[Laurent]

Another bunch of buggies from CSFML: In the include files, sfCircleShape has _GetOrigin and _GetScale instead of their camelCase versions, and all of sfRectangleShape's functions suffer from the same problem.

Wow, there was in fact a lot of functions that were still using the old naming convention. I wonder why I didn't check using a regexp before.

[Teemperor]

I don't know if this is a bug, but i found out sf::Keyboard::isKeyPressed() really slows down your programm if it is used every loop? I used it 5 times per gameloop and got ~10fps in the game. Now i changed to a Keyboard-Event-based input and i got 80-100 fps (on the same crappy netbook)? Found the issue with the valgrind profiler.

I know the event-based is the preffered way, but the other was more intuitive in my opinion.

[Laurent]

I don't know if this is a bug, but i found out sf::Keyboard::isKeyPressed() really slows down your programm if it is used every loop?

It's the first time that I hear about that. It would be interesting to know if other people experience this problem too.

[Paki Programmer]

Actually i found that to be true too...that exact line of code seemed to slow down my computer

[Laurent]

On which OS?

[Sonkun]

It's just a personal opinion but I think the design of the sf::Shape part of the API is ugly and non-natural. Of course, I know nothing about the under layer (which is OpenGL) so I won't criticize. If SFML 2.0 is meant to be a widely used version, from my point of view, this should need a face-lifting before being released

When I say ugly, I'm talking about writing CircleShape, ConvexShape (which should be ConvexPoligon by the way) and RectangleShape. Theese name are long because of the substring "Shape" which make things ugly. Why don't you put everything in a namespace named sf::Shape ?

When I say non-natural, I'm talking about why RectangleShape doesn't inherit from ConvexShape because a rectangle is no more than a convex polygon. Why can't I move my RectangleShape's points anymore and - by the way - why have point's properties (color, outline color) disappeared ? I found them very useful. Now I would understand if this comes from a technical reason belonging to a layer below the SFML but it took interest in using sf::Shape. Why don't you add other shapes such sf::TriangleShape.

I just want the best for Simple and Fast Multimedia Library

[Nexus]

When I say ugly, I'm talking about writing CircleShape, ConvexShape (which should be ConvexPoligon by the way) and RectangleShape. Theese name are long because of the substring "Shape" which make things ugly.

You have a quite... special understanding of ugly. sf::Shape::Rectangle is more beautiful because it is... hm, longer? Or do you always write using namespace as soon as you see a namespace?

Honestly, the names match their meaning perfectly. "Shape" is the base class, and "RectangleShape" is a specialized shape (namely a rectangle), so its name is standing to reason.

When I say non-natural, I'm talking about why RectangleShape doesn't inherit from ConvexShape because a rectangle is no more than a convex polygon.

Probably because some functions like setPointsCount() are not appropriate for a rectangle.

Why can't I move my RectangleShape's points anymore

You can, using setSize() and setPosition().

why have point's properties (color, outline color) disappeared ? I found them very useful.

There is now less confusion with global/point-local color. The special case of differently colorized points can still be achieved with sf::VertexArray.

[Sonkun]

When I say ugly, I'm talking about writing CircleShape, ConvexShape (which should be ConvexPoligon by the way) and RectangleShape. Theese name are long because of the substring "Shape" which make things ugly.

You have a quite... special understanding of ugly. sf::Shape::Rectangle is more beautiful because it is... hm, longer? Or do you always write using namespace as soon as you see a namespace?

Honestly, the names match their meaning perfectly. "Shape" is the base class, and "RectangleShape" is a specialized shape (namely a rectangle), so its name is standing to reason.

Finally you are right. Maybe because I'm used to write sf::Shape::Rectangle() to create my rectangle.

When I say non-natural, I'm talking about why RectangleShape doesn't inherit from ConvexShape because a rectangle is no more than a convex polygon.

Probably because some functions like setPointsCount() are not appropriate for a rectangle.

Why can't I move my RectangleShape's points anymore

You can, using setSize() and setPosition().

The reason may be about hardware acceleration but I can make a Rectangle using ConvexShape with wich I can move the point as I want. I thought I could use RectangleShape not to start from scratch when I want to make a parallelogram.

why have point's properties (color, outline color) disappeared ? I found them very useful.

There is now less confusion with global/point-local color. The special case of differently colorized points can still be achieved with sf::VertexArray.

I did not notice this class. How do I set a color ?

[Laurent]

The reason may be about hardware acceleration but I can make a Rectangle using ConvexShape with wich I can move the point as I want. I thought I could use RectangleShape not to start from scratch when I want to make a parallelogram.

You got the point: if you want to manipulate your rectangle as a convex polygon (change every point individually and eventually get a non-rectangle), use sf::ConvexShape. If you want to manipulate your rectangle as a rectangle (change size and position, and let SFML ensure that it will always be a rectangle), then use sf::RectangleShape.

I did not notice this class. How do I set a color ?

This class is the low-level layer of SFML. You construct your own vertices (a vertex is a 2D point with attributes: position, color and texture coordinates), and then you draw them as either points, lines, triangles or quads. So there's no global function that would work on your whole vertex array, instead you have to manage the points individually -- which is what you need, apparently.

[Teemperor]

On which OS?

Sorry for the late reply. OS is Ubuntu 12.04 64bit on Intel Atom .
Can i help solving this bug? I'll try to reproduce the bug on my other PC with 12.04 tomorrow.

I'm not sure but as far as i can remember, the most CPU time in KeyPressed was used in an other SFML-internal function which was called inside KeyPressed. I hope i can find the name of the function again.

I'll will post all results tomorrow evening

[Cornstalks]

The reason may be about hardware acceleration but I can make a Rectangle using ConvexShape with wich I can move the point as I want. I thought I could use RectangleShape not to start from scratch when I want to make a parallelogram.

You got the point: if you want to manipulate your rectangle as a convex polygon (change every point individually and eventually get a non-rectangle), use sf::ConvexShape. If you want to manipulate your rectangle as a rectangle (change size and position, and let SFML ensure that it will always be a rectangle), then use sf::RectangleShape.

I just looked at the API docs, and I may have (probably have) missed something, but it may be nice to provide a function/operator to convert a RectangleShape into a ConvexShape (and similarly with a CircleShape). Quite a low-priority feature, I might say, but what do you think about this possibility?

I too think RectangleShape should inherit from ConvexShape, just because a rectangle is a convex shape. But I don't think it should inherit from ConvexShape in its current form, and I haven't given enough thought to this to propose any kind of clean alternative. I don't think it's a show-stopper though, so I'm not too concerned with it.

[Walker]

I can't tell if there is a reason for this or not. When you create an sf::CircleShape the origin is set as if it were at the top-left corner of a bounding box encasing the circle. I find it more intuitive to have the circle's origin at the centre of the circle.

[Laurent]

I just looked at the API docs, and I may have (probably have) missed something, but it may be nice to provide a function/operator to convert a RectangleShape into a ConvexShape (and similarly with a CircleShape). Quite a low-priority feature, I might say, but what do you think about this possibility?

Why woud one need such a feature?
And don't forget that shape classes are just helpers, you're free to create your own shapes, either derived from sf::Shape or even from scratch with vertex arrays. Don't be limited by SFML classes, they are just there to provide simple features for simple use cases.

I too think RectangleShape should inherit from ConvexShape, just because a rectangle is a convex shape.

So you're the kind of programmer that would make a Square class inherit from Rectangle?
What you suggest is not possible. ConvexShape is less constrained than RectangleShape, so the latter would inherit functions that would be able to break its contract.

I can't tell if there is a reason for this or not. When you create an sf::CircleShape the origin is set as if it were at the top-left corner of a bounding box encasing the circle. I find it more intuitive to have the circle's origin at the centre of the circle.

This is a convention, all graphical entities in SFML have their origin in the top-left corner by default. It's easy to change that by calling setOrigin.

[Nexus]

I just looked at the API docs, and I may have (probably have) missed something, but it may be nice to provide a function/operator to convert a RectangleShape into a ConvexShape (and similarly with a CircleShape). Quite a low-priority feature, I might say, but what do you think about this possibility?

Why woud one need such a feature?
And don't forget that shape classes are just helpers, you're free to create your own shapes, either derived from sf::Shape or even from scratch with vertex arrays. Don't be limited by SFML classes, they are just there to provide simple features for simple use cases.

There are cases where one wants to construct a specialized shape, but after that, just use it generically as convex shape -- similar to the old factory functions that returned a single type. Thor contains such a function

sf::ConvexShape toConvexShape(const sf::Shape&);

It is not strictly necessary, but a little bit more convenient that sf::Shape pointers which have no value semantics. Although I could also use aurora::CopiedPtr<sf::Shape> to give them value semantics

But if it's necessary for SFML, is a different question. At the moment I'm not even sure how much of the Shape functionality will remain in Thor -- some parts seem to be very specific, maybe I'll remove them or provide them as examples.

I too think RectangleShape should inherit from ConvexShape, just because a rectangle is a convex shape.

That's not the only criterion for inheritance, take a look at the Liskov Substitution Principle.

[Laurent]

There are cases where one wants to construct a specialized shape, but after that, just use it generically as convex shape

In this case it's not hard to use sf::CongexShape directly. Defining a circle's or rectangle's points manually is really straight-forward.