The new graphics API in SFML 2

[Groogy]

The pointers are a good way to make clear that the arguments are referenced after the call and no temporaries are passed, but you should be careful that you don't mix two design policies in SFML. Until now, pointers in SFML interfaces imply the possibility of being NULL.

That's another reason why I need pointers: NULL means no texture/shader.

Well the same could be achieved by using the concept of Null Objects cant it? And might be an option for you if you don't like pointers.

[Laurent]

Well the same could be achieved by using the concept of Null Objects cant it? And might be an option for you if you don't like pointers.

This is not an option here. I already thought about special objects such as Texture::None and Shader::None, but because of the current implementation I can't have global Texture or Shader instances inside SFML. I could use new types and overload SetTexture/SetShader, but that would make the API a little more complicated than it should.
Unless you were suggesting something different.

Anyway, I don't like pointers in public API but I think it's necessary to use them here to make a difference between states that are handled by value and states that are handled by reference.

[gsaurus]

I think that being able to set/get the transformation components individually is what makes it simple.

Definitely.

Position/Rotation/Scale are stored separately, and combined always in the same order. (...) With a sf::Transform alone, you can't get them back

Thus I guess a SetTransform would just bring confusion. Though there may be constructors or some kind of reset/create function taking a Transform. A const GetTransform may make sense too.
So to combine a sprite with some transform it can be achieved by a call to GetTransform, combine it, and remake the sprite with it.

Argh, I knew I would miss the most interesting discussion

I wondered where you were  :lol:

[Nexus]

That's another reason why I need pointers: NULL means no texture/shader.

Then it's perfectly ok

But it doesn't work
The interface based on Position/Rotation/Scale is not equivalent to manipulating a sf::Transform directly. sf::Transform accumulates all the transformations that you apply to it, while Position/Rotation/Scale are stored separately, and combined always in the same order.

Ah, you are right. So, I see the following possibilities:

• High-level entities keep a sf::Transform member and a (position, rotation, scale) tuple. The final transform is the combination of both. This is the most flexible solution, but people might confuse the two independent transforms, especially if there is a third one at sf::Window.
• Keep only sf::Transform, remove the tuple. I agree this is probably not a good idea because of the two reasons you mentioned (same order of transformations, possibility to get components).
• Store only the (position, rotation, scale) tuple, as done in the past. Then some transforms cannot be applied except globally at sf::Window, but the interface is probably the most simple one.

Anyway, do you already have concrete ideas how high-level objects and sf::Mesh interact? Just private aggregation? Or is the mesh part of the high-level object's public interface?

[Laurent]

Anyway, do you already have concrete ideas how high-level objects and sf::Mesh interact? Just private aggregation? Or is the mesh part of the high-level object's public interface?

I think it would be a bad idea to mix high-level functions with the low-level ones (sf::Mesh). High-level objects hide the sf::Mesh interface behind their own, simpler functions. It wouldn't make sense to provide both.

[luiscubal]

There's a forth option:
To have a SetTransformCombinationMode(pick better name), to choose which(or what combination) of transforms should be used. But this might even add further to the confusion.
Another variant of this is EnableHighLevelTransforms(again, pick better name).

[Laurent]

The point of providing high-level classes is to keep the same simplicity as before. Trying to make them as flexible as the low-level API doesn't make sense in my opinion. So the third option looks good to me

[Nexus]

That sounds reasonable. Something came to my mind that isn't very relevant in the context of this discussion, but for the library developer: There is still a lot of code duplication (getters, absolute setters and relative setters for each of the transformations in each high-level object).

And to avoid the loss of track, I try to sum up which class holds which public properties (along with some name suggestions ), please correct mistakes:

Vertex (Point)
- Position
- Color
- TexCoords

VertexArray (Mesh)
- Dynamic array of Vertex elements
- Geometric primitive (Triangle, Quad, ...)

RenderTarget
- View
- Texture
- Shader
- Transform
- BlendMode

High-level object
- Position
- Rotation
- Scale
- Origin
- Color
- Specific properties (e.g. sub-rect at sf::Sprite)

[Laurent]

Perfect

I think I'll create a Drawable base class, but it would only define a virtual Draw function, so that people can write window.Draw(object), as well as a class that defines the transformation stuff (position, rotation, scale, ...). sf::Mesh would inherit Drawable, high-level objects would inherit both, and user classes would have the choice.

A detail about "origin": I don't think that it was used a lot as the origin of translation and scaling, therefore I was thinking about changing it to "rotation center", which would remove all the confusion about it.

[Nexus]

as well as a class that defines the transformation stuff (position, rotation, scale, ...).

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

A detail about "origin": I don't think that it was used a lot as the origin of translation and scaling, therefore I was thinking about changing it to "rotation center", which would remove all the confusion about it.

From my own experience, I used it a lot for translation. It provides an easy way to align objects properly. For example to refer to right-upper corner instead of the left-upper one, if the object must be positioned relative to an object right from it.

[Laurent]

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

Absolutely. The "Transformable" name would be perfect as a base class, but I want it to be usable by aggregation as well (it will have no virtual function). Any idea?

From my own experience, I used it a lot for translation. It provides an easy way to align objects properly. For example to refer to right-upper corner instead of the left-upper one, if the object must be positioned relative to an object right from it.

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

[Spidyy]

A detail about "origin": I don't think that it was used a lot as the origin of translation and scaling, therefore I was thinking about changing it to "rotation center", which would remove all the confusion about it.

I think it is often used for the scale, particularly to center the scaling of the text in scaling effects. Origin is still the best name for me.

[Groogy]

I'm not really interested in this myself but there might be people out there who are. Will geometry shader come with the shader changes? Just found out some good use cases for it today in 2D applications. Though it's more a way to optimize repetive rendering I guess by minimizing bandwith. If interested I can write more what I am thinking about and some math behind it.

[Laurent]

I think it is often used for the scale, particularly to center the scaling of the text in scaling effects. Origin is still the best name for me.

Hmm ok, so I won't touch that.

Will geometry shader come with the shader changes?

No, it's too recent.

[Lokk]

maybe sf::Transformable?

or sf::Spatial ?