Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: How does SFML 2.0 rendering works aka is it worth to change my code  (Read 3044 times)

0 Members and 1 Guest are viewing this topic.

waxx

  • Newbie
  • *
  • Posts: 26
    • View Profile
Do you now use batching at least or VBO?
Would like to get detailed answer if you can Laurent.

Thanks

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: How does SFML 2.0 rendering works aka is it worth to change my code
« Reply #1 on: June 04, 2012, 03:21:52 pm »
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.
Laurent Gomila - SFML developer

waxx

  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: How does SFML 2.0 rendering works aka is it worth to change my code
« Reply #2 on: June 04, 2012, 03:35:13 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: How does SFML 2.0 rendering works aka is it worth to change my code
« Reply #3 on: June 04, 2012, 03:46:43 pm »
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>).

Quote
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
Laurent Gomila - SFML developer

waxx

  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: How does SFML 2.0 rendering works aka is it worth to change my code
« Reply #4 on: June 04, 2012, 05:17:18 pm »
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
« Last Edit: June 04, 2012, 05:33:37 pm by waxx »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: How does SFML 2.0 rendering works aka is it worth to change my code
« Reply #5 on: June 04, 2012, 06:11:40 pm »
Quote
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.

Quote
sf::Shape::Rectangle? where are you?
Look at the online doc + corresponding thread in the General forum.

Quote
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.
Laurent Gomila - SFML developer

waxx

  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: How does SFML 2.0 rendering works aka is it worth to change my code
« Reply #6 on: June 04, 2012, 06:33:16 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: How does SFML 2.0 rendering works aka is it worth to change my code
« Reply #7 on: June 04, 2012, 07:30:55 pm »
Quote
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?

Quote
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.
Laurent Gomila - SFML developer

waxx

  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: How does SFML 2.0 rendering works aka is it worth to change my code
« Reply #8 on: June 04, 2012, 09:05:05 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: How does SFML 2.0 rendering works aka is it worth to change my code
« Reply #9 on: June 04, 2012, 09:09:06 pm »
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;
}
Laurent Gomila - SFML developer

waxx

  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: How does SFML 2.0 rendering works aka is it worth to change my code
« Reply #10 on: June 04, 2012, 09:40:50 pm »
I know man, I'll just edit src of SFML directly... Just saying eh. 

Sathorod

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: How does SFML 2.0 rendering works aka is it worth to change my code
« Reply #11 on: June 10, 2012, 04:05:15 am »
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

  • Full Member
  • ***
  • Posts: 121
    • View Profile
Re: How does SFML 2.0 rendering works aka is it worth to change my code
« Reply #12 on: June 10, 2012, 10:50:54 am »
@Laurent

So there is some automated batching when drawing sprites directly?

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