Make CircleShape, RectangleShape, and ConvexShape only be shapes. Not drawables.

[mashedtatoes]

CircleShape, RectangleShape, ConvexShape, and Sprite do very similar things. They all apply a texture to some shape. What I am suggesting is to remove the functionality that allows the shapes to be drawable and add the ability to apply a shape to a sprite. Then you create the shape first and pass that shape into the constructor for the sprite. So rather than creating just a CircleShape, you would create a CircleShape then create a sprite using that CircleShape. When you apply the texture to the sprite, it will only give you a circular cutout of the texture.

This does add an extra line of code but, to me, nothing about CircleShape seems like it should be anything more than a shape (just a bunch of points in some space). You shouldn't be able to apply a texture to this shape and draw it because it is just a shape. It shouldn't be able to represent an image. That is where Sprite and Image should be used.

It just seems a lot more intuitive to me if the process of creating a shaped drawable was

• Create a shape
• Create a container (sprite) using that shape
• Apply the texture to the container

Box2D creates shaped objects in a similar way so if I did not explain it very good and you would like some code to look at, you can look at Box2D's b2Fixture.

[eXpl0it3r]

Shapes are not intended to be used as clipping masks. This feature has been requested for a long time (#1) though.

It essentially is more questionable why shapes can use a texture to begin with. In the end there's very little difference between a sprite and a rectangle shape, both can render a texture quad. Since both are about the same, your suggested hierarchy doesn't really make sense.

Keep in mind however that you can do all of this by writing your own class hierarchy based on vertex arrays.

[Nexus]

What I am suggesting is to remove the functionality that allows the shapes to be drawable and add the ability to apply a shape to a sprite.

These are indeed some interesting ideas.

It essentially is more questionable why shapes can use a texture to begin with. In the end there's very little difference between a sprite and a rectangle shape, both can render a texture quad. Since both are about the same, your suggested hierarchy doesn't really make sense.

It would not make sense with the current sf::Shape hierarchy, but it would with a hierarchy of purely logical shapes, as suggested by mashedtatoes. Exactly the fact that sf::Sprite and a textured sf::RectangleShape are so similar indicates that some parts of the API can potentially be improved.

Shapes are not intended to be used as clipping masks. This feature has been requested for a long time (#1) though.

Good you mention clipping masks. I see different approaches to implement them in OpenGL, each with different flexibility: scissors (rectangles), clipping planes (convex polygons with a point limit) and stencil masking (arbitrary pixel-based masks). The fragment shader is a further user-side possibility to not render certain pixels. All approaches are however different from shapes, which are split into triangles a priori and don't require additional resources (stencil buffer) or checks (stencil check, clipping check) to function. Thus I don't think one mechanism can replace the other.

By the way, write masks are a different concept, they limit rendering based on color components, not areas.

[Hiura]

That's indeed some interesting food for thought. I've two things to add:

 a) I think it was already mentioned somewhere around here, so if I remember correctly it was Laurent who explained that we haven't merged Sprite and RectangleShape because the former was for a simple usage/beginners.
 b) We should probably push the discussion further to examine a broader generalisation of the concept for SFML 3. I have in mind something similar to my Curve tool where you can draw an arbitrary curve if you have its mathematical representation. Would it make sense to have something similar in SFML or is it too high level? Can we make it even better?

[mashedtatoes]

Curves would be a neat feature. That actually gives me another idea though. Maybe you can split Shape up even more into a group of Line(s). A line would be a set of continuous points with no curve greater than 180^o. A shape is a set of lines chained together (each line shares an endpoint with only two other line). Then you could have curved lines and straight lines on a single shape and make some real funky shapes. So a circle shape would be made with 2 lines. Both of them are 180^o curves and they are linked together by their endpoints. A rectangle would be just four lines linked together...

[Gambit]

If drawing was removed, how would one go about drawing a circle or a square? I guess you would have to query a list of lines or points then draw them yourself with a shader or something?

[mashedtatoes]

how would one go about drawing a circle or a square

If you are talking about drawing a shape without a texture that is a good question. I guess the Sprite would initialize with some drawable shape depending on the shape you pass into it. Then you would be able to fill it with a color or change the size or line thickness like you can with shapes now.

[eXpl0it3r]

As seen by Hirua's code, things like that can be built on top of SFML, thus I don't think it needs to be part of SFML.

Things like a clipping area which is currently rather hard if at all to implement on top of SFML (without using raw OpenGL), seem to be a limitation.

Requiring an additional shape object for every sprite would make things very quickly, very annoying. In 2D about everything is done with quads, even when the objects are round one mostly just uses a round texture. Making this basic usecase more complicated than necessary isn't really a good idea.

Also if you go down to "lines" you might as well just go down to vertices, which is exactly what shapes (and sprites) are, a collection of vertices that build a convex polygon.
Making edges of shapes curved is an interesting idea, but keep in kind that if you want an area you'll have to write some sort of a solver to get the triangles layed out properly etc. This is something rather specific (not that many applications would need that), it can already be written on top of SFML and thus it's too complex and too high-level IMHO.

[Hapax]

how would one go about drawing a circle or a square

If you are talking about drawing a shape without a texture that is a good question. I guess the Sprite would initialize with some drawable shape depending on the shape you pass into it. Then you would be able to fill it with a color or change the size or line thickness like you can with shapes now.

Doesn't a sprite without a texture already default to white? Then setting its (filter) colour would change its colour.

However, removing the shapes as drawable objects also removes extras that sprites don't (currently) have. I can think of outlines/inlines. Would this suggestion then be to add outlines to the sprite class?

[mashedtatoes]

eXpl0it3r actually did a good job at interpreting what I was really requesting and it was shaped clipping masks. I just didn't know what it was until he mentioned it.

However, removing the shapes as drawable objects also removes extras that sprites don't (currently) have. I can think of outlines/inlines. Would this suggestion then be to add outlines to the sprite class?

Yes, this would mean that any drawable functionality currently in shape would get put in sprite.

Also if you go down to "lines" you might as well just go down to vertices, which is exactly what shapes (and sprites) are, a collection of vertices that build a convex polygon.

I see what you are saying, but I still feel like the difference between a shape and a sprite should be more distinct. If you are going to use a shape at all, it should be as a clipping mask. Otherwise, like you said

even when the objects are round one mostly just uses a round texture.

There isn't any real reason to have a shaped drawable (that I can see) when you can just make the texture whatever shape you want.

[Gambit]

That creates a lot of unnecessary assets for applications, especially for simple games with simple geometry and coloring.

[mashedtatoes]

That creates a lot of unnecessary assets for applications

Good point. I over looked that. How about this. First off, remove the ability to apply a texture to a shape. Next, create a ClippingMask class that Sprite will inherit. That way, you can still use shapes to generate simple graphics in a game without many assets. Then, Sprite would be used for pretty much everything else. When you create the sprite, you set the size and/or shape of the clipping mask. I guess this would replace the current setTextureRect in sprites with some setShape thing or setClippingMask.

Or maybe you leave the setTextureRect and add a setShape that selects some shape in the current texture rect.

[Hiura]

So there're two things here:

 a) disassociating shape from drawable
 b) having clipping mask.

Regarding the latter, have a look at the task tracker here (https://github.com/SFML/SFML/issues/1). Unless I'm mistaken it is not specific to sprite. It should work with any drawable (even raw vertices). Thus no inheritance should be involved here.

Now, about the former idea: Yes it can build on top of SFML but still we could provide the basic system. And if the API is well designed we don't need an extra shape for each sprite. By default it could still be a rectangle. But we could have factories to create other shape. And of course a more general constructor for generic shaped sprites. (I'm on my phone so it's very cumbersome to write code but if my thoughts are not so clear then tell me and I'll show something later this weekend.)

[Gambit]

I still dont like the idea of removing drawable from shapes. While it might make sense in some cases, it doesnt make sense in others. For example: It makes sense to remove drawable from shapes IF you are going to use something else to draw the shapes instead (Example being that you only need the verticies of the shape or something). It does not make sense to remove drawable from a shape for applications which draw shapes.

If I have a program which draws 4 squares on the screen, then I would just make 4 sf::RectangleShapes then draw them. Having to make a texture just to draw a square is pointless and as I said early, creates unnecessary assets for these types of applications.

Alternatively, one could use a geometry shader to work around this but not everyone has the knowledge to do that.

[Nexus]

So there're two things here:

 a) disassociating shape from drawable
 b) having clipping mask.

Yes, exactly. As mentioned in my last post, the concepts of shapes and clipping masks are different. In particular, the latter are either very limited (finite number of clipping planes) or expensive (stencil buffer and check). I still don't think it's a good idea to implement convex shapes via clipping masks.

And as always in designing an API, let's not focus on technical details ("A is assigned a B", "I don't like if X no longer inherits Y")... It makes no sense to discuss at them as long as we're not clear what functionality is actually desired.

As far as I see it, there are different requests:

• Allow sprites to be rendered using different shapes than rectangles
• Keep shapes simple to use even without a texture
• Reduce redundancy in sprite/shape API