SFML 2.0 RC

[Laurent]

... But I agree that the new shapes API is still not perfect. I can't change it now because SFML 2 is going to be released, but I'm already thinking about something that could replace it in the future.

However, we could work on solutions and provide them soon, for example in Thor if you're interested in improving this area. Later, some of these solutions could be integrated to SFML if they prove to be good enough (like boost and std ).

I don't know if it would be a good idea, that was just the monday morning suggestion

[Cornstalks]

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?

It could be easier for creating custom convex shapes. That is, you could take a rectangle as a starting shape, and then slightly transform the points (so it's not a rectangle, but still a convex shape), rather than starting from scratch.

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.

Don't forget I said I wouldn't do this in its current form Doing so right now would certainly violate LSP. I suppose I'm thinking of a more component-based design for the shapes, where shape classes are created through composition of various attributes/capabilities. And I figure with a design like this, implementing it with inheritance would require a little less typing (plus allow polymorphic behavior, if done carefully, though I don't know if that's a worthwhile goal).

But I'm ok with the shapes API for now. It's not like these little details are going to stop me or anyone else from making a game. I'm just thinking out loud.

[Laurent]

Don't forget I said I wouldn't do this in its current form

Any other form that I can think of doesn't involve inheritance. To me, the current design is the best that you can get if you want to keep inheritance: sf::Shape has all the common attributes plus functions to read points. Functions that set points (ie. that wouldn't fit in the RectangleShape class) are kept in ConvexShape only.

I suppose I'm thinking of a more component-based design for the shapes, where shape classes are created through composition of various attributes/capabilities. And I figure with a design like this, implementing it with inheritance would require a little less typing  (plus allow polymorphic behavior, if done carefully, though I don't know if that's a worthwhile goal).

If you have a precise idea of what this solution would look like, I'll be glad to hear more about it

[Nexus]

I don't know if it would be a good idea, that was just the monday morning suggestion

Yes, it's a good idea in my opinion

I just don't really have an exact imagination of how I could improve it. The only thing I'm quite sure to leave in its current form is thor::ConcaveShape, I don't know however if it's a candidate for SFML because of its rather complex triangulation algorithm. And it doesn't inherit from sf::Shape, since the latter only supports convex shapes. thor::Arrow could also be useful to visualize vectors, but it's not integrated with sf::Shape either...

One approach consists of minimalizing the Thor Shape API for 2.0, and of adding features as soon as I've found a good way

[nulloid]

In CSFML, SoundStream.h isn't #included in Audio.h (public headers). Also, in the same SoundStream.h, there are still CamelCase function names, but maybe it isn't necessary to report them, since you indicated you will use regexp. (Am I wrong?)

[Laurent]

In CSFML, SoundStream.h isn't #included in Audio.h (public headers). Also, in the same SoundStream.h, there are still CamelCase function names, but maybe it isn't necessary to report them, since you indicated you will use regexp. (Am I wrong?)

Have you checked the latest modifications on the repository?

[nulloid]

Oh, hell, I forgot that. Thanks

[Foaly]

I've been messing around a little more with the release candidate in the last days and I couldn't find anything that not yet on the issue tracker. Great job!

What's still left to be done before the final version is released?

[Laurent]

What's still left to be done before the final version is released?

I must finish to write the tutorials.

[Sonkun]

The documentation about events says "Depending on the type of event, the event instance will be filled with different parameters" but where to find more about how is filled an event when it's a precise type of event ? E.g: if the event type is sf::Event::Closed, how is the event filled ? The same question for the other seventeen one.

[Laurent]

It's not hard to find the matching member:
MouseButtonPressed/Released -> event.mouseButton
KeyPressed/Released -> event.key
...

Closed and a few others have no parameter (what would you expect?).

This is of course explained in detail in the tutorials.

[Sonkun]

If this was explained, I wouldn't be here for asking I didn't expect anything special for events that are triggered when a window closes but as I'm writing a binding I wanted to be sure.

[Laurent]

If this was explained, I wouldn't be here for asking

It's in the "Handling events" tutorial.

[Sonkun]

If this was explained, I wouldn't be here for asking

It's in the "Handling events" tutorial.

It was implicitly said Maybe a line like "The other three events (Closed, LostFocus and GainedFocus) have, of course, no specific parameters" would have removed my doubt.

By the way, maybe there's a small error in the documentation, shouldn't sf::Text::getStyle() and sf::Text::setStyle() returns/takes a sf::Text::Style instead of Uint32 ? I'm saying that based of sf::Sotcket::bind() which returns a sf::Socket::Status, they are both an enumeration. It's been a long I haven't practiced my C++ so I may be wrong...

[Laurent]

Maybe a line like "The other three events (Closed, LostFocus and GainedFocus) have, of course, no specific parameters" would have removed my doubt.

The new documentation will be much better

By the way, maybe there's a small error in the documentation, shouldn't sf::Text::getStyle() and sf::Text::setStyle() returns/takes a sf::Text::Style instead of Uint32 ?

No, because you can combine several styles. In C++, combining multiple items of an enum produces an integer, not a variable of the enum type.