The new graphics API in SFML 2

[gsaurus]

sf::Mesh would inherit Drawable, high-level objects would inherit both, and user classes would have the choice.

Hm inheritance :roll: ... Sometime in the past I had a problem with the restrictions caused by the drawables inheritance. If I still remember I had an abstract CompositeDrawable derived from sf::Drawable, and at some point I wanted a leaf deriving from CompositeDrawable and from sf::Sprite, causing a diamond problem which I couldn't solve.

As for the center, I used it a lot too, it's very handy. Particularly, if you implement flip operations on Sprite, do it around the center. But I think Scale/SetScale is enough, I'd discard the old flip operations (negative scale to flip)

[Laurent]

Sometime in the past I had a problem with the restrictions caused by the drawables inheritance. If I still remember I had an abstract CompositeDrawable derived from sf::Drawable, and at some point I wanted a leaf deriving from CompositeDrawable and from sf::Sprite, causing a diamond problem which I couldn't solve.

Inheriting from sf::Drawable means that you define your own drawing.
Inheriting from sf::Sprite means that you use a high-level objects that has its own drawing.
-> So what does it mean to inherit from both?

The new sf::Drawable class will only define the Draw virtual function, all the transformation stuff will be in a new class. Maybe this new design would solve your problem?

[Laurent]

Do you have something in mind like I did here, but in one class, maybe sf::Transformable?

I can see that you have no function to set X or Y alone (in Positionable and Scalable). I was thinking about removing these functions in SFML, what do you think about it?

And also... Point/Mesh or Vertex/VertexArray?

[Nexus]

You're right. But I'd really like to make it less confusing, there are too many threads about this on the forum.

I think this is only possible when storing 3 separate origins for translation, rotation and scale. But it would probably bloat the interface too much (one hardly needs to set all three centers). So, maybe this should belong to the category "full customization with low-level API".

I can see that you have no function to set X or Y alone (in Positionable and Scalable). I was thinking about removing these functions in SFML, what do you think about it?

Hm, difficult to say. After a short search for "SetX" and "SetY" in my main projects, it seems like I haven't used them a single time. Technically, they are not necessary either, since one can easily write a free function to set them. Otherwise -- strictly following the convenience/consistency argument -- you should also add SetOriginX/Y() and maybe even SetColorR/G/B/A().

In my opinion, you can give it a try, you also encourage vector-based instead of component-based operations. And if it turns out to be totally unacceptable, you can still add the functions -- better than the other way around

And also... Point/Mesh or Vertex/VertexArray?

I prefer Vertex/VertexArray, since it describes the functionality more clearly. Also, I associate "mesh" with 3D models...

[Laurent]

So, maybe this should belong to the category "full customization with low-level API".

I think I'll just keep it as it is now: a single origin for all transformations.

In my opinion, you can give it a try, you also encourage vector-based instead of component-based operations. And if it turns out to be totally unacceptable, you can still add the functions -- better than the other way around

Yep

I prefer Vertex/VertexArray, since it describes the functionality more clearly.

But do these words make sense for someone who is totally new to graphics rendering?

Also, I associate "mesh" with 3D models...

Me too. But again, what about people with no background in graphics programming?

[Nexus]

I see it like this: The low-level API of SFML requires some knowledge anyway, common terms alone are not enough if the theory behind them is unknown. For example, a beginner might understand "Point", but gets stuck at "TexCoords" because he doesn't know about texture mapping. Apart from that, I doubt "Mesh" is such a self-explanatory notion, at dict.cc I get about 10 translations none of which is related to graphics programming.

The documentation has to be read in every case, so you could spend one phrase to explain what a vertex is. The advantage is that you stick to common terms and don't confuse people who already have some graphics programming background. And the relation between vertices and vertex arrays is obvious.

[Laurent]

I doubt "Mesh" is such a self-explanatory notion, at dict.cc I get about 10 translations none of which is related to graphics programming.

In french the translation is perfect. And I already got positive feedback on this name:

Other than sf::VertArray I don't think you can get much more descriptive than sf::Mesh.  Although "mesh" tends to suggest (to me) three dimensions.

sf::Mesh fits perfectly as the name.

Other than that, your points are all valid

However, Vertex and VertexArray could suggest 3D as well. In fact the perfect name would be something that implies 2D. But I don't think it exists.

[gsaurus]

I like Vertex and Mesh. Vertex instead of Point because Point suggests a location in world space. Mesh instead of VertexArray because it's more than a vertex array, it has texture coordinates associated and looks more like a matrix. I think mesh fits perfectly.

what does it mean to inherit from both?

You know, extension of families of classes. For some reason I wanted to add new functionality to the whole family. I made it in one way or another anyway.
Well since the new sf::Drawable is just an interface that shouldn't be a problem, but where will you put the code that is common to Sprite/Text/etc?

[Laurent]

but where will you put the code that is common to Sprite/Text/etc?

Transformations will be defined in the Transformable class.
Color will be duplicated in every class, because it can't be implemented in a generic way anymore (I have to change the color of every vertex).
Blend mode will stay a global state.

[Spidyy]

Do you have something in mind like I did here, but in one class, maybe sf::Transformable?

I can see that you have no function to set X or Y alone (in Positionable and Scalable). I was thinking about removing these functions in SFML, what do you think about it?

And also... Point/Mesh or Vertex/VertexArray?

Function to set X and Y alone are a nice mean to shorten the code. I mean, I prefer doing a little SetX(val); instead of SetPosition(sf::Vector2(value, GetPosition().Y));

Also, Mesh and Vertex. Thoses are names used in 3D design and creation. Even in a 2D space, a vertex is a vertex. You could add a typename Point for thoses unfamiliar with Vertex, but for the beginners, I think it is a good thing to initiate them with standard naming. Same reasoning with sf::Transform instead of sf::Spatial.

[Laurent]

Function to set X and Y alone are a nice mean to shorten the code. I mean, I prefer doing a little SetX(val); instead of SetPosition(sf::Vector2(value, GetPosition().Y));

There will still be SetPosition(x, y)

Same reasoning with sf::Transform instead of sf::Spatial

sf::Transform exists and won't change. sf::Spatial was suggested as a replacement to sf::Transformable.

[Mikademus]

Another issue is that the current set of blend modes is inadequate. Our application makes heavy use of particle effects, and only alphablend, additive and multiply blend modes are insufficient. Primarily we need the subtractive mode, but some effects we are importing also needs screen and interpolation blending. A very common need out in the wild is also a premultiplied alpha mode.

Personally, I think that the best way to handle this is by:
1) Adding at least the Subtractive, Screen and perhaps also the PremultAlpha modes to the enum, and
2) Allow custom blend modes by providing a function where the user can specify the glBlendFunc arguments himself.

This will allow keeping the API simple while allowing advanced users to do what they need to.


Resources:
* Earlier thread with some pictures a search turned up.
* Parameter values for some additional modes on jMonkeyEngine's blend api docs.

[Laurent]

Thanks for your feedback, and for finding these useful resources.

Blend modes definitely need some improvements and more flexibility, I'll try to think about it and submit some ideas, maybe in a dedicated thread.

[Laurent]

I was thinking about renaming "SubRect" in sf::Sprite. Would "TextureArea" or TextureRegion" be better?

[thePyro_13]

I don't read TextureArea or TextureRegion as more descriptive than SubRect.

Perhaps incorporating the word 'crop' would be more descriptive, that's what is used in image editing programs to describe essentially the same function as SubRect.