Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML 2.0 RC  (Read 119679 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 2.0 RC
« Reply #75 on: May 07, 2012, 10:47:35 am »
... 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 ;D).

I don't know if it would be a good idea, that was just the monday morning suggestion :)
Laurent Gomila - SFML developer

Cornstalks

  • Full Member
  • ***
  • Posts: 180
    • View Profile
    • My Website
Re: SFML 2.0 RC
« Reply #76 on: May 07, 2012, 03:48:02 pm »
Quote
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.

Quote
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 :D (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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 2.0 RC
« Reply #77 on: May 07, 2012, 03:57:49 pm »
Quote
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.

Quote
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 :)
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML 2.0 RC
« Reply #78 on: May 07, 2012, 05:34:00 pm »
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 ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

nulloid

  • Full Member
  • ***
  • Posts: 134
    • View Profile
Re: SFML 2.0 RC
« Reply #79 on: May 11, 2012, 01:34:29 am »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 2.0 RC
« Reply #80 on: May 11, 2012, 07:59:56 am »
Quote
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?
Laurent Gomila - SFML developer

nulloid

  • Full Member
  • ***
  • Posts: 134
    • View Profile
Re: SFML 2.0 RC
« Reply #81 on: May 12, 2012, 06:08:45 pm »
Oh, hell, I forgot that. Thanks :)

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: SFML 2.0 RC
« Reply #82 on: May 14, 2012, 05:02:19 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 2.0 RC
« Reply #83 on: May 14, 2012, 05:29:16 pm »
Quote
What's still left to be done before the final version is released?
I must finish to write the tutorials.
Laurent Gomila - SFML developer

Sonkun

  • Full Member
  • ***
  • Posts: 241
    • View Profile
Re: SFML 2.0 RC
« Reply #84 on: May 15, 2012, 11:08:29 pm »
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.
Interested in using SFML with Python ? Try out its Python binding!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 2.0 RC
« Reply #85 on: May 16, 2012, 07:30:38 am »
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.
Laurent Gomila - SFML developer

Sonkun

  • Full Member
  • ***
  • Posts: 241
    • View Profile
Re: SFML 2.0 RC
« Reply #86 on: May 16, 2012, 05:29:07 pm »
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.
Interested in using SFML with Python ? Try out its Python binding!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 2.0 RC
« Reply #87 on: May 16, 2012, 10:11:28 pm »
Quote
If this was explained, I wouldn't be here for asking
It's in the "Handling events" tutorial.
Laurent Gomila - SFML developer

Sonkun

  • Full Member
  • ***
  • Posts: 241
    • View Profile
Re: SFML 2.0 RC
« Reply #88 on: May 18, 2012, 05:30:23 pm »
Quote
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...
Interested in using SFML with Python ? Try out its Python binding!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 2.0 RC
« Reply #89 on: May 18, 2012, 06:35:36 pm »
Quote
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 :)

Quote
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.
Laurent Gomila - SFML developer