The new graphics API in SFML 2

[gsaurus]

Why do you think that meshes and high-level objects shouldn't share the same states?

For simplicity of the high-level objects, to keep their own state, or part of the state (texture, transform).

If high-level objects use the global state as is, then you'll have sprites/whatever without their own texture & transform.
You can still store their own state internally but you have to explicitly apply it to the render target if you don't want to use/mix with the current global state - resulting in more verbosity.

Code: [Select]

sf::Sprite sprite(someTexture);
sprite.SetPosition(200,100);
window.SetTexture(sprite.GetTexture()); // 1
window.SetTransform(sprite.GetTransform()); // 2
window.Draw(sprite); // 3


The naming issue previously said are to turn 1,2 and 3 in one step, with the side effect of no chance to use the current global texture and transform. As for the other properties like shader, those have to be shared. Again, how it sounds can be a question of function names.[/code]

[Hiura]

Why do you think that meshes and high-level objects shouldn't share the same states? I had the feeling that it would be better if they were mixed, high-level objects would just be a layer on top of the low-level API instead of a separate layer.

Why ? Because I'm getting confused !  :oops:

I can easily implement the old sf::Text, sf::Sprite and sf::Shape classes on top of this new API. But it would probably not be a good idea.

But higher-level objects need to have their own render states, otherwise they are pretty useless

Maybe I misunderstood your words but these two quotes seems to go the opposite way from one other.

A lot have been said and everybody has changed his mind at least three times. Maybe it would be a good idea to make a quick recap of which ideas seem good so far.

[Laurent]

Code: [Select]

sf::Sprite sprite(someTexture);
sprite.SetPosition(200,100);
window.SetTexture(sprite.GetTexture()); // 1
window.SetTransform(sprite.GetTransform()); // 2
window.Draw(sprite); // 3

When the sprite is drawn it sets all its internal states first so you don't have to do 1 and 2.
That my point: high-level objects can set their own states (texture, transform) while being able to use other states that they don't care about (view, shader).

A lot have been said and everybody has changed his mind at least three times. Maybe it would be a good idea to make a quick recap of which ideas seem good so far.

Yup. So far, I'm still on the same solution as in my very first post.

[gsaurus]

That my point: high-level objects can set their own states (texture, transform) while being able to use other states that they don't care about (view, shader).

That's what we have been talking about :lol:

In fact, if all we see for high-level objects is 'object.Draw(window)', I think it's already clear enough that this won't change global states.

So I think this is good enough, go for it. I feel like we have been talking in circles.

[Laurent]

:lol:

So:

Code: [Select]

sf::Sprite sprite;
sprite.SetTexture(...);
sprite.SetPosition(...);

window.SetTexture(...);
window.SetTransform(...);
window.SetShader(...);

window.Draw(sprite); // uses its own texture, transform and the global shader
window.Draw(mesh); // uses global texture, transform and shader
:?:

[danman]

I agree

[gsaurus]

Either target.draw(object) or object.draw(target), do as it is best for SFML.

[Zinlibs]

I agree too

[Laurent]

Great.

Now we can focus on other questions, such as: should high-level objects have their own transform, and keep the same functions as now (Set/Get Position/Rotation/Scale/Origin)? If so, how would one make a sprite relative to a parent object, ie. multiply its own transform by it before passing it to the render target?

[Groogy]

Add further functions, instead of having to GetTransform and SetTransform on the render target you have a MultiplyTransform, like how OpenGL have. Or you have PopTransform and PushTransform.

[otibom]

If so, how would one make a sprite relative to a parent object, ie. multiply its own transform by it before passing it to the render target?

Is this a scene graph ?

[Groogy]

No he's talking about the relationship of spaces trough matrixes/transforms.

For instance if we go from object space to world space we multiply by the object's transformation but if we want to go from world space to object space we use the inverse of the matrix.

[luiscubal]

Add further functions, instead of having to GetTransform and SetTransform on the render target you have a MultiplyTransform, like how OpenGL have. Or you have PopTransform and PushTransform.

Assuming both would have their own transforms(which I'm not 100% sure is the best approach), maybe SetTransformMode(enum TransformMode), where TransformMode can be Inherit, Override or Multiply?

I also feel tempted to suggest not having a global transform at all, and instead let only meshes, sprites, etc. have transforms, though I admit it might not be the simplest-to-use approach.

[Nexus]

Argh, I knew I would miss the most interesting discussion

BlendMode, Transform and View should always be handled by value (copy), whereas Texture and Shader should be handled by reference. To make it clear, the first three will be passed as const references and the last two will always be passed as const pointer to functions that use them.

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 code styles. Until now, pointers in SFML interfaces imply the possibility of being NULL.

Now we can focus on other questions, such as: should high-level objects have their own transform, and keep the same functions as now (Set/Get Position/Rotation/Scale/Origin)? If so, how would one make a sprite relative to a parent object, ie. multiply its own transform by it before passing it to the render target?

Would the high-level objects also provide set/get functions for the transform itself? Then one could do this:

Code: [Select]

sf::Sprite sprite;
sf::Transform tf = sprite.GetTransform();
sprite.SetTransform(tf * other);
In principle, the interface is unnecessarily big with SetPosition() etc., but the above code is too unconvenient to be the standard way of positioning objects. Another option are free functions, even if you don't seem to like them too much in SFML

Code: [Select]

sf::SetPosition(sprite, pos);
// semantically equivalent to the following, but optimizations are possible:
sf::Transform tf = sprite.GetTransform();
tf.SetTranslation(pos);
sprite.SetTransform(tf);
The big advantage is, you can write this function as a template and it works with all positionable entities. Plus, it can be overloaded for other classes, even ones not part of SFML. Member functions either need a common base class like sf::Drawable, or produce a huge code duplication.


By the way, I have read the thread and have tried to reconstruct the proposals and their implications. But I consider this topic quite complex and I fear that some consequences are only visible when experimenting around with them. So I would appreciate if you left the users some time to test the new API after you have a first working draft, instead of releasing SFML 2 immediately

[Laurent]

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.

Would the high-level objects also provide set/get functions for the transform itself?

It would be the most flexible solution, but SetTransform would conflict with other functions. What happens if you call SetPosition and then SetTransform?

In principle, the interface is unnecessarily big with SetPosition() etc.

Really? I think that being able to set/get the transformation components individually is what makes it simple. Would you suggest to remove or simplify this interface?

Another option are free functions, even if you don't seem to like them too much in SFML
[...]
The big advantage is, you can write this function as a template and it works with all positionable entities. Plus, it can be overloaded for other classes, even ones not part of SFML. Member functions either need a common base class like sf::Drawable, or produce a huge code duplication.

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. This is less flexible but more convenient.
Also, storing components separately allows to write getters for them. With a sf::Transform alone, you can't get them back (in fact you could get something but it wouldn't always be the same components that you initially set).

So I would appreciate if you left the users some time to test the new API after you have a first working draft, instead of releasing SFML 2 immediately

Of course! I'm aware that the new API will need to be tested, and probably modified before the final release.
There will always be a release candidate before the final 2.0 release.