dsfml.graphics.transformable

The interface and template are provided for convenience, on top of $(TRANSFORM_LINK).

$(TRANSFORM_LINK), as a low-level class, offers a great level of flexibility but it is not always convenient to manage. Indeed, one can easily combine any kind of operation, such as a translation followed by a rotation followed by a scaling, but once the result transform is built, there's no way to go backward and, let's say, change only the rotation without modifying the translation and scaling.

The entire transform must be recomputed, which means that you need to retrieve the initial translation and scale factors as well, and combine them the same way you did before updating the rotation. This is a tedious operation, and it requires to store all the individual components of the final transform.

That's exactly what $(U Transformable) and $(U NormalTransformable) were written for: they hides these variables and the composed transform behind an easy to use interface. You can set or get any of the individual components without worrying about the others. It also provides the composed transform (as a $(TRANSFORM_LINK)), and keeps it up-to-date.

In addition to the position, rotation and scale, $(U Transformable) provides an "origin" component, which represents the local origin of the three other components. Let's take an example with a 10x10 pixels sprite. By default, the sprite is positioned/rotated/scaled relatively to its top-left corner, because it is the local point (0, 0). But if we change the origin to be (5, 5), the sprite will be positioned/rotated/scaled around its center instead. And if we set the origin to (10, 10), it will be transformed around its bottom-right corner.

To keep $(U Transformable) and $(U NormalTransformable) simple, there's only one origin for all the components. You cannot position the sprite relatively to its top-left corner while rotating it around its center, for example. To do such things, use $(TRANSFORM_LINK) directly.

$(U Transformable) is meant to be used as a base for other classes. It is often combined with $(DRAWABLE_LINK) -- that's what DSFML's sprites, texts and shapes do.

1 class MyEntity : Transformable, Drawable
2 {
3    //generates the boilerplate code for Transformable
4    mixin NormalTransformable;
5 
6    void draw(RenderTarget target, RenderStates states) const
7    {
8        states.transform *= getTransform();
9        target.draw(..., states);
10    }
11 }
12 
13 auto entity = new MyEntity();
14 entity.position = Vector2f(10, 20);
15 entity.rotation = 45;
16 window.draw(entity);

$(PARA If you don't want to use the API directly (because you don't need all the functions, or you have different naming conventions for example), you can have a $(U TransformableMember) as a member variable.)

1 class MyEntity
2 {
3    this()
4    {
5        myTransform = new TransformableMember();
6    }
7 
8    void setPosition(MyVector v)
9    {
10        myTransform.setPosition(v.x, v.y);
11    }
12 
13    void draw(RenderTarget target, RenderStates states) const
14    {
15        states.transform *= myTransform.getTransform();
16        target.draw(..., states);
17    }
18 
19 private TransformableMember myTransform;
20 }

$(PARA A note on coordinates and undistorted rendering: By default, DSFML (or more exactly, OpenGL) may interpolate drawable objects such as sprites or texts when rendering. While this allows transitions like slow movements or rotations to appear smoothly, it can lead to unwanted results in some cases, for example blurred or distorted objects. In order to render a $(DRAWABLE_LINK) object pixel-perfectly, make sure the involved coordinates allow a 1:1 mapping of pixels in the window to texels (pixels in the texture). More specifically, this means:)

• The object's position, origin and scale have no fractional part
• The object's and the view's rotation are a multiple of 90 degrees
• The view's center and size have no fractional part