New graphics API ready

[Laurent]

Anyway, the current parameter lists of sf::Sprite and sf::Text are a good compromise in my opinion.

Yes. So, applying the same design to shape classes, they should provide a constructor that takes all the properties that they declare (size for rectangle, radius for circle, ...).

[Groogy]

Alright yay!

I'll get into testing as soon as I can. So far my walls are built up with shapes so they can't have textures. I'll now start looking into using VertexArray instead for that.

Though before I can start play around with it I have to track down an annoying graphical glitch.

[Nexus]

Okay, back to the star problem. Apart from "point" and "vertex", the term that soonest comes into question is "spike", but I'm not sure if it's really understandable.

But another question: Why do you want the user to access only the outer points (spikes or whatever)? I mean, he specifies the radius of the inner points, too. So he is aware of their existence, but has no access.

Maybe even one step further: Isn't a star shape too specific to deserve an own class in a basic multimedia library? Stars are rarely used as building blocks for more complex shapes. They are rather a nice feature for experiments, aka. "by the way, we have stars" Additionally, I'd personally classify regular polygons (equilateral triangle, square) as more important. But in my opinion, both are a little bit too specific for SFML... At least that's my spontaneous view, perhaps this feature has been requested in the past.

To sum up, I think you shouldn't spend too much time on the interface of sf::StarShape, since stars are unimportant compared to the powerful new API, and they can be easily added later.

[JayArby]

Stars might be real useful for particles, no?

[Groogy]

Not really, too inefficient. A sprite with a star painted on it is much more efficient. When it comes to particles you want to limit as much as possible as of what you send to the graphics card as it becomes quickly the bottleneck. So increasing the amount of points is not good. (That's why with geometry shaders you can create the entire particle system on the GPU by sending data per cloud instead)

[Laurent]

So far my walls are built up with shapes so they can't have textures. I'll now start looking into using VertexArray instead for that.

Just to make it clear: shapes can have a texture with this new API.

But another question: Why do you want the user to access only the outer points (spikes or whatever)? I mean, he specifies the radius of the inner points, too. So he is aware of their existence, but has no access.

I don't want users to only have access to the outer points. It's just that StarShape::SetPointsCount defines the number of spikes, it's more natural like this.

Maybe even one step further: Isn't a star shape too specific to deserve an own class in a basic multimedia library? Stars are rarely used as building blocks for more complex shapes. They are rather a nice feature for experiments, aka. "by the way, we have stars"  Additionally, I'd personally classify regular polygons (equilateral triangle, square) as more important. But in my opinion, both are a little bit too specific for SFML... At least that's my spontaneous view, perhaps this feature has been requested in the past.

You're right, it's just to say "by the way we have stars", nothing more :mrgreen:
But it's the only valid shape that is not convex. So I thought it would be cool to provide it directly.

To sum up, I think you shouldn't spend too much time on the interface of sf::StarShape, since stars are unimportant compared to the powerful new API, and they can be easily added later.

So you suggest that I remove it, rename GetOutlinePoint/GetOutlinePointsCount to GetPoint/GetPointsCountand move them to the public part of sf::Shape?

[Groogy]

Just to make it clear: shapes can have a texture with this new API.

I LOVE YOU! *cries a little* <3  :oops:

[Nexus]

I don't want users to only have access to the outer points. It's just that StarShape::SetPointsCount defines the number of spikes, it's more natural like this.

But then, GetPoint() is expected to return only points in this range, too -- that is, the outer points. If GetPointsCount() returned the number of all polygon points, you could have the convention that even indexes refer to the outer and odd ones to the inner points, just as an example. Or you provide additional methods like Get/SetSpikesCount() which halve that number.

So you suggest that I remove it, rename GetOutlinePoint/GetOutlinePointsCount to GetPoint/GetPointsCountand move them to the public part of sf::Shape?

Yes, I would provide GetPoint() and GetPointsCount() as an iteration interface. And if the sf::StarShape API doesn't conflict with the rest of the design, you can also leave the class

[luiscubal]

Now that I think of it, why not have SFML take advantage of initializer lists? Just add a preprocessor macro SFML_USE_CPP_0X so those parts can be disabled for non-compliant compilers and have the magical ones do all the good stuff.

Code: [Select]


Vector2f x = {1, 1};
Rectangle y = {1, 1, 2, 2};


[gsaurus]

I didn't see the API yet, sorry, but I think a star class should be used as an example of a custom shape, either on sfml examples or provided at the wiki. It doesn't sound very useful as a built in feature of SFML.

[Laurent]

But then, GetPoint() is expected to return only points in this range, too -- that is, the outer points. If GetPointsCount() returned the number of all polygon points, you could have the convention that even indexes refer to the outer and odd ones to the inner points, just as an example. Or you provide additional methods like Get/SetSpikesCount() which halve that number.

But there's no problem here, the two possible solutions are:
- leave everything as it is now
- rename SetPointsCount in sf::StarShape (to SetSpikesCount, for example), and set GetPoint/GetPointsCounts in sf::Shape public

Yes, I would provide GetPoint() and GetPointsCount() as an iteration interface. And if the sf::StarShape API doesn't conflict with the rest of the design, you can also leave the class

... and I still need to find a name for the "spkies" of a star

Now that I think of it, why not have SFML take advantage of initializer lists? Just add a preprocessor macro SFML_USE_CPP_0X so those parts can be disabled for non-compliant compilers and have the magical ones do all the good stuff.

Yes, I'll probably add support for C++11 features in a future version of SFML 2.

[Laurent]

I've added constructors to all shape classes. And default constructors now create empty shapes.

[Nexus]

When I add points to sf::ConvexShape, do they have to be oriented clockwisely? The documentation only speaks about "ordered", the following example doesn't create a line as expected. What do I do wrong?

Code: [Select]

#include <SFML/Graphics.hpp>

int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");

sf::ConvexShape cs;
cs.SetPointsCount(4);
cs.SetFillColor(sf::Color::Cyan);
cs.SetPoint(0, sf::Vector2f(20.f, 20.f));
cs.SetPoint(1, sf::Vector2f(20.f, 21.f));
cs.SetPoint(2, sf::Vector2f(140.f, 21.f));
cs.SetPoint(3, sf::Vector2f(140.f, 20.f));

while (window.IsOpened())
{
sf::Event event;
while (window.PollEvent(event))
{
if (event.Type == sf::Event::Closed)
window.Close();
}

window.Clear();
window.Draw(cs);
window.Display();
}
}
And concerning the new semantics of SetPointsCount() and SetPoint() vs. the old AddPoint(): Is it always defined what happens when resizing? The problem is, there may now be invalid situations, when the amount of points is increased, but no new points are specified. Do these points get valid default values?

[Laurent]

When I add points to sf::ConvexShape, do they have to be oriented clockwisely?

This example is strange, for me the result doesn't depend on the order of the points, but rather on the thickness of the line.

And concerning the new semantics of SetPointsCount() and SetPoint() vs. the old AddPoint(): Is it always defined what happens when resizing? The problem is, there may now be invalid situations, when the amount of points is increased, but no new points are specified. Do these points get valid default values?

They are (0, 0) by default.

[Nexus]

This example is strange, for me the result doesn't depend on the order of the points, but rather on the thickness of the line.

At me, too, sorry. I just corrected it, but you were faster

Might the problem be that you create two additional vertices in sf::Shape? Do you really need them? When I write an own shape class with direct access to sf::VertexArray, it works:

Code: [Select]

#include <SFML/Graphics.hpp>

struct MyShape : sf::Shape
{
virtual unsigned int GetOutlinePointsCount() const
{
return array.GetVerticesCount();
}

virtual sf::Vector2f GetOutlinePoint(unsigned int index) const
{
return array[index].Position;
}

virtual void Draw(sf::RenderTarget& target, sf::RenderStates states) const
{
target.Draw(array, states);
}

void SetPointsCount(unsigned int c)
{
array.Resize(c);
array.SetPrimitiveType(sf::TrianglesFan);
}

void SetPoint(unsigned int i, sf::Vector2f pos)
{
array[i] = sf::Vertex(pos, sf::Color::Yellow);
}

private:
sf::VertexArray array;
};

int main()
{
   sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");

   MyShape ms;
   ms.SetPointsCount(4);
   ms.SetPoint(0, sf::Vector2f(20.f, 20.f));
   ms.SetPoint(1, sf::Vector2f(20.f, 21.f));
   ms.SetPoint(2, sf::Vector2f(140.f, 21.f));
   ms.SetPoint(3, sf::Vector2f(140.f, 20.f));

   sf::ConvexShape cs;
   cs.SetPointsCount(4);
   cs.SetPoint(0, sf::Vector2f(20.f, 20.f));
   cs.SetPoint(1, sf::Vector2f(20.f, 21.f));
   cs.SetPoint(2, sf::Vector2f(140.f, 21.f));
   cs.SetPoint(3, sf::Vector2f(140.f, 20.f));
   cs.SetFillColor(sf::Color::Green);
   cs.Move(0.f, 80.f);

   while (window.IsOpened())
   {
      sf::Event event;
      while (window.PollEvent(event))
      {
         if (event.Type == sf::Event::Closed)
            window.Close();
      }

      window.Clear();
      window.Draw(ms);
      window.Draw(cs);
      window.Display();
   }
}

I've added constructors to all shape classes. And default constructors now create empty shapes.

You should make constructors that can be called with one argument explicit. I always forget this, too...