Optimizing a lot of sprites

[Foaly]

OK thank you very much for explaining so clearly! Makes a lot of sense! I will use a sf::Transform then and store position and angle myself. And of course the transformPoint method

I was confused on how to use multiple textures. But I see now, that I can simply put them in a spritesheet and pick the right one with the texture coordinates.

The whole process seams fairly complex to me. Are you sure this will be noticeably faster then using sprites?

Thanks again for all the explanations!

[Laurent]

I will use a sf::Transform then and store position and angle myself. And of course the transformPoint method

The point to use a position and angle directly is not to use sf::Transform

The whole process seams fairly complex to me

It's not really complex, once you're familiar with vertices I'm sure you'll find it easy.

Are you sure this will be noticeably faster then using sprites?

Absolutely sure.

[Foaly]

Absolutely sure.

Awesome!

The point to use a position and angle directly is not to use sf::Transform

What do you mean by that? That a sf::Transform would also consume a lot of memory? Doing positioning myself seems simple, but how would I do rotation and scaling?

[Laurent]

sf::Transform creates a 4x4 matrix from your position/rotation/scale, and then applies it to the input point to compute the final position. This is useful when:
- you want to send it to the graphics card (the 4x4 matrix can be givn to OpenGL as is)
- you want to reuse the transform matrix for multiple points (applying a matrix is cheaper than applying the individual transformation components)

Since this is not the case in your application, there's no point using sf::Transform; unless you want a simpler code, but if I understand correctly you rather want the best performances.

Applying a position/rotation/scale is not hard:
- position -> add
- rotation -> sin/cos
- scale -> multiply

The exact formula depends on the order in which you want to apply them, and on the origin of the rotation/scale.

[Foaly]

Ok I get it! Yeah I'd rather have maximum performance, so sf::Transform seems not what I want.

Well in my case the origin would be in the middle of the texture, so it would be (8,8). The scale is only set once in the beginning and doesn't change afterwards. The position and the rotation are changed every frame.
So I guess my order would be translate, rotate, scale. (But I feel like the order doesn't really make a difference in my case, does it?) I don't know how I would calculate the vertex position with this though...

[Laurent]

If the scale is just an initial size, you don't need to apply it all the time, but instead to your initial positions (the ones that you'll transform every frame with the position/rotation).

If you always rotate around the center, then you can also directly define your 4 vertices around their center -- top-left corner would be (-size/2, -size/2) and bottom-right corner would be (size/2, size/2).

So all you have to do every frame is:

transformed.x = initial.x *  sin(angle) + initial.y * cos(angle) + position.x;
transformed.y = initial.x * -cos(angle) + initial.y * sin(angle) + position.y;

I'm not sure about the order and sign of the sin/cos, you should check (ask Google for "2d rotation formula").

[Foaly]

Thank you sooo much Laurent! That is exactly what I needed! I'll try to implement it! Thanks again!

edit: I googeled and the first thing that came up was this: http://www.siggraph.org/education/materials/HyperGraph/modeling/mod_tran/2drota.htm
So I guess the formula is:

transformed.x = initial.x * cos(angle) - initial.y * sin(angle) + position.x;
transformed.y = initial.x * sin(angle) + initial.y * cos(angle) + position.y;

right?

[Laurent]

Yep, looks good. Maybe you'll have to invert the sign on Y operations, because the Y axis in SFML is from top to bottom.

[Foaly]

Wow!! I just finished a test implementation and the performance is incredible!!! I can easily draw 20000 objects (80000 vertices) now, before noticing the program slowing down. This is awesome! Thank you Laurent for making such an amazing API that let's you create things so easily! And all the great help of course

Maybe you'll have to invert the sign on Y operations, because the Y axis in SFML is from top to bottom.

I can't see anything being inverted or drawn wrong, so I'll just leave it

Thanks again to everybody!

[masskiller]

I'm not sure about the order and sign of the sin/cos, you should check (ask Google for "2d rotation formula").

Note that the formula for 2D rotation is to multiply each vector of the four vertexes by a 2x2 matrix, to get some crazy transformations you could make a 2D matrix class and implement matrix multiplying (or use thor's vector algebra module or a linear algebra library if you don't want to reinvent the wheel). As well as getting an even nicer notation since all you do is use the respective operators of your matrix and your vector, hiding the formula and making the code more understandable for people if that's your approach.

Instead of:

transformed.x = initial.x * cos(angle) - initial.y * sin(angle) + position.x;
transformed.y = initial.x * sin(angle) + initial.y * cos(angle) + position.y;

You get:

transformed = transformed * RotationMatrix(angle);

If you like to experiment with math you can perfectly have a fun time working with it and at the same time discover new and different effects of alternate versions of the usual rotation matrix and anything you may come up with.