How does SFML 2.0 rendering works aka is it worth to change my code

[waxx]

Do you now use batching at least or VBO?
Would like to get detailed answer if you can Laurent.

Thanks

[Laurent]

There are 3 main things to know:

- SFML now uses vertex arrays (not VBOs because it still has to handle potentially small/dynamic geometries)
- it optimizes out redundant OpenGL states
- it implements minimal batching: it pretransforms and accumulates small geometries into larger buffers (so the typical use case of drawing several sprites that use the same texture is well optimized)

You can also directly look at the source code, it's not complicated.

[waxx]

Damn it man, if not your awesome interfaces I wouldn't even consider adapting my code. And those changes seem superb. Especially last one.

Just wondering why so many changes to the interfaces? sf::Image->sf::Texture? Is there a lot to work on in my code in 1.6 to make it work with 2.0? What do you think?

[Laurent]

I forgot something: in SFML 2 you can also define your own geometry (and thus batches!) with custom vertex arrays (sf::VertexArray or simply std::vector<sf::Vertex>).

Just wondering why so many changes to the interfaces? sf::Image->sf::Texture?

Most changes are cosmetic (CamelCase to camelCase, SetSubRect to setTextureRect, etc.) and won't be hard to apply.
Major modifications are all explained in their own thread on the General forum, as well as in the corresponding ticket on the task tracker.
http://en.sfml-dev.org/forums/index.php?topic=5503.0
https://github.com/SFML/SFML/issues/18

[waxx]

Well, it's...painful.

Already few problems. e.g.:

what happened to renderwindow?
Events? how do I change  Event.Key.Code == sf::Mouse::Button::Right  to work with 2.0 ?
sf::Shape::Rectangle? where are you?

thx


edit:
goddamn, so many unecessary changes
like removing sf::Vector2f position parameter from sf::Sprite is beyond my imagination for why did u do so
guess sfml 2 is gonna be only used for newer projects or little to small

[Laurent]

what happened to renderwindow?
Events? how do I change  Event.Key.Code == sf::Mouse::Button::Right  to work with 2.0 ?

The online doc (and soon tutorials) + remembering the CamelCase to camelCase change should solve all your problems.

sf::Shape::Rectangle? where are you?

Look at the online doc + corresponding thread in the General forum.

like removing sf::Vector2f position parameter from sf::Sprite is beyond my imagination for why did u do so

What do you mean? sf::Sprite still has a sf::Vector2f position.

This is SFML 2.0, not 1.7. Don't expect it to be the same as 1.6.

Please take the time to understand the modifications, they all make sense. Read the doc and the general forum, you should be able to find 99% of the modifications by yourself. After that, if you really have relevant feedback regarding the new API, I'll be glad to discuss it.

[waxx]

I know it's 2.0. I just can't understand why you dropped position from arguments in constructor of sf::Sprite. It's not a reasonable update, only creates more harm for upgrading the code.

But yeah, my first shock is gone, sorry.
Anyway, I was always wondering about this:
Is creating sf::Sprite object each frame to draw something very heavy performence-wise?

[Laurent]

I just can't understand why you dropped position from arguments in constructor of sf::Sprite. It's not a reasonable update, only creates more harm for upgrading the code.

sf::Sprite has a lot of properties, it was insane to have them all in the constructor. And as far as I know, only a minority of developers used this constructor. And what harm does it do, except adding one extra line to your code?

Is creating sf::Sprite object each frame to draw something very heavy performence-wise?

Not at all. It just contains a pointer to a texture, a sf::IntRect and 4 sf::Vertex (statically allocated). Filling the 4 vertices' attributes is very cheap.

[waxx]

sf::Sprite has a lot of properties, it was insane to have them all in the constructor. And as far as I know, only a minority of developers used this constructor. And what harm does it do, except adding one extra line to your code?

Guess I'm in minority then. And it's not an extra line. Hundrends of extra lines for each time I did it. My project is big. I just thought that if something doesn't need to be changed / it won't have any effect - it shouldn't be done.

[Laurent]

Then just create your own sprite constructor and we're back to one extra line in your whole code

sf::Sprite newSprite(sf::Vector2f position, ...)
{
    sf::Sprite sprite;
    sprite.setPosition(position);
    return sprite;
}

[waxx]

I know man, I'll just edit src of SFML directly... Just saying eh. 

[Sathorod]

Isn't the point of a library to have a small, basic, generic collection of tools that are supposed to be easily modifiable to a persons more specific needs? It's pretty much a given that in a large project you're going to have specific needs which means at some point you're going to be making modifications to satiate those needs.

[heishe]

@Laurent

So there is some automated batching when drawing sprites directly?

Good, I thought you had to take care of the batching manually.