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

Author Topic: SFML 2.0  (Read 102865 times)

0 Members and 1 Guest are viewing this topic.

nullsquared

  • Newbie
  • *
  • Posts: 27
    • View Profile
SFML 2.0
« Reply #135 on: January 12, 2010, 12:20:36 pm »
Quote from: "Laurent"

It is handled so that the current batch is stopped whenever a state changes. Even if the same states are set again later, the corresponding geometry will not belong to the same batch. This way, the drawing order still has the priority.

Right, I noticed.  However, consider two objects qualify for the same batch, as so:
Code: [Select]

// Check if the current batch differs from the new render states
    if (!myCurrentBatch || !myCurrentBatch->Matches(myCurrentTexture, myCurrentShader, myCurrentBlendMode, myCurrentViewport))

Same shader, same texture, same blend mode, same viewport.  Then what?

Quote
What are you talking about, that's how high performance 3D renderers work. Batching is left up to the user via a BatchDrawable or something that will combine VBOs of other Drawables. See above as to why auto-batching everything won't work.

High-performances 3D renderers work with models, not with 2D quads. It's very different, and it can't be handled the same way. Optimizing a generic, low-level 2D API is not straight-forward.

Quote

No they don't.

???
Code: [Select]

    ////////////////////////////////////////////////////////////
    // Member data
    ////////////////////////////////////////////////////////////
    std::vector<Point> myPoints;           ///< Points composing the shape


Quote

Of course I did.

Quote
Right now you're filling one giant VBO (more if objects vary in texture/shader/etc.) every frame.

What's wrong with that?

I believe that filling up a giant VBO with all the objects every frame is not efficient.  I'd love to see your profiling results that say otherwise.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFML 2.0
« Reply #136 on: January 12, 2010, 12:34:06 pm »
Quote
Same shader, same texture, same blend mode, same viewport. Then what?

Then they will belong to the same batch.

Quote
???
Code: [Select]
   ////////////////////////////////////////////////////////////
    // Member data
    ////////////////////////////////////////////////////////////
    std::vector<Point> myPoints;           ///< Points composing the shape

This is sf::Shape. Shapes are custom geometrical shapes, there's no higher-level way of storing their geometry. sf::Sprite and sf::Text however don't store their geometry, it is deduced from their parameters when they are rendered, which makes them lightweight.

Quote
I believe that filling up a giant VBO with all the objects every frame is not efficient.

Well, it's obviously a lot more efficient than immediate mode rendering. I didn't say that it was the best technique ever, it's just the best that I found that matches all the requirements of low-level 2D rendering.

Quote
I'd love to see your profiling results that say otherwise.

I didn't write a profiling log, sorry. But in worst case (every drawable uses a completely different set of states, thus no batching happens) it performed the same as the old implementation based on immediate mode, and in the best case (like a tilemap, a particle system, a GUI, etc. ie. many sprites using all the same states) I got an average speed increase of 5x.

You shouldn't bother with this discussion, automatic batching will probably be removed soon, I'm currently working on it.
Laurent Gomila - SFML developer

nullsquared

  • Newbie
  • *
  • Posts: 27
    • View Profile
SFML 2.0
« Reply #137 on: January 12, 2010, 01:09:13 pm »
Quote from: "Laurent"
Quote
Same shader, same texture, same blend mode, same viewport. Then what?

Then they will belong to the same batch.


Code: [Select]

rt.Draw(blue);
rt.Draw(red);

How is the draw order guaranteed if both end up in the same batch, if the batch is rendered as a whole?

Quote

Quote
I believe that filling up a giant VBO with all the objects every frame is not efficient.

Well, it's obviously a lot more efficient than immediate mode rendering.

Actually it's not that obvious at all.  Thus why I asked for profiling results.  I'll look into it myself.

Quote

You shouldn't bother with this discussion, automatic batching will probably be removed soon, I'm currently working on it.

And replaced with what?

I think I might have a go implementing my own ideas and benching that when I find the time.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFML 2.0
« Reply #138 on: January 12, 2010, 01:27:47 pm »
Quote
How is the draw order guaranteed if both end up in the same batch, if the batch is rendered as a whole?

OpenGL renders triangles in the same order as they are in the buffer. I couldn't find a spec that clearly says that, but I can't find a reason why the vertices would be rearranged by the driver.

Quote
Actually it's not that obvious at all. Thus why I asked for profiling results. I'll look into it myself.

It's obvious when you compare the number of driver calls required for both techniques. And driver calls are exactly what needs to be optimized in SFML.

Quote
And replaced with what?

With whatever I'll find that is good enough ;)
I'm still experimenting.

Quote
I think I might have a go implementing my own ideas and benching that when I find the time.

That's an excellent idea. This is the most important area in sfml-graphics, and I still haven't found the perfect solution so far, so your help is appreciated.

Please keep in mind that I want both performances and easiness (I mean in the public part of the API), so if you come up with an optimized solution that requires tons of extra calls on user side it will be as bad as a clean solution with poor performances.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
SFML 2.0
« Reply #139 on: April 09, 2010, 02:11:39 pm »
For SFML 2, I would suggest to deactivate the smooth filter for sf::Image by default.

A lot of beginners (me inclusive, when I started) are confused about why a drawn sprite looks different than in the source file. Related problem threads seem to come up again and again (some examples: 1 2 3). In my opinion, it would be more intuitive to render an image 1:1 by default, and let the smooth filter be an additional feature which can be activated when required.

How do you see this?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFML 2.0
« Reply #140 on: April 09, 2010, 02:15:13 pm »
The rendering is now 1:1 in SFML 2 even with the smooth filter activated, as long as your coordinates match the window pixels.

Do you think it's enough to keep smooth images by default? :P
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
SFML 2.0
« Reply #141 on: April 09, 2010, 02:20:18 pm »
Quote from: "Laurent"
The rendering is now 1:1 in SFML 2 even with the smooth filter activated, as long as your coordinates match the window pixels.
Hm, what exactly has changed here since SFML 1? I'm not very well versed in SFML 2 smooth filters. ;)

And do you mean that if the sprite's coordinates are not integers, the sprite will be blurred? If so, how to avoid that? Rounding manually?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFML 2.0
« Reply #142 on: April 09, 2010, 02:47:39 pm »
Quote
Hm, what exactly has changed here since SFML 1? I'm not very well versed in SFML 2 smooth filters

A lot of things. The internal rendering process is completely different, I've removed some tricks and added some others to get to this result ;)

Quote
And do you mean that if the sprite's coordinates are not integers, the sprite will be blurred?

Kind of. Pixels that don't exactly map to one pixel will not be rendered perfectly.

Quote
If so, how to avoid that? Rounding manually?

Yes. This may look very annoying, but I can't help much. In a previous version I was applying an automatic rounding, but some users found that this was preventing smooth transitions when a sprite was translated/rotated/scaled slowly. So basically we need these blurred pixels to make dynamic things smooth.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
SFML 2.0
« Reply #143 on: April 09, 2010, 03:15:39 pm »
Quote from: "Laurent"
A lot of things. The internal rendering process is completely different, I've removed some tricks and added some others to get to this result ;)
Okay. Maybe you remember the artifacts bug. Since it is fixed, SFML seems to render quite nicely. But I haven't experimented too much... Probably I should do it, especially with newer revisions.

So, with a simple code like that, one could expect a 1:1 rendering?
Code: [Select]
sf::Image image;
image.LoadFromFile(...);
sf::Sprite sprite(image, sf::Vector2f(20, 30));

Quote from: "Laurent"
Yes. This may look very annoying, but I can't help much. In a previous version I was applying an automatic rounding, but some users found that this was preventing smooth transitions when a sprite was translated/rotated/scaled slowly. So basically we need these blurred pixels to make dynamic things smooth.
Just a spontaneous idea: Would another switch to either round automatically or manually bloat the interface?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFML 2.0
« Reply #144 on: April 09, 2010, 03:20:00 pm »
Quote
Okay. Maybe you remember the artifacts bug. Since it is fixed, SFML seems to render quite nicely. But I haven't experimented too much... Probably I should do it, especially with newer revisions.

I tried to gather all the codes related to rendering artifacts which were posted to this forum, and they all succeeded with the current implementation.
But don't hesitate to experiment, I'm sure that you can find something. It's like this problem has no solution anyway ;)

Quote
So, with a simple code like that, one could expect a 1:1 rendering?

Yes.
Laurent Gomila - SFML developer

bullno1

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
SFML 2.0
« Reply #145 on: April 11, 2010, 01:18:40 pm »
I suggest adding some method to the Renderer to support vertex arrays too. That should further reduce driver calls.

The Renderer will soon become "fat".  But you can't really have both speed and simplicity at the same time.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFML 2.0
« Reply #146 on: April 11, 2010, 05:14:08 pm »
Quote
I suggest adding some method to the Renderer to support vertex arrays too. That should further reduce driver calls.

It doesn't help at all to render single quads.
It's a little too easy to say "use VA/VBO, it's faster", you have to look at the whole rendering process ;)
Laurent Gomila - SFML developer

kolofsson

  • Full Member
  • ***
  • Posts: 100
    • View Profile
Support for Visual Studio 2010
« Reply #147 on: April 12, 2010, 11:16:46 am »
Hello. Today, on 12 April 2010, the Visual Studio 2010 has been released. Are there any plans to support it in SFML?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFML 2.0
« Reply #148 on: April 12, 2010, 12:02:58 pm »
Absolutely.
Laurent Gomila - SFML developer

Merkoth

  • Guest
SFML 2.0
« Reply #149 on: April 12, 2010, 05:41:30 pm »
I'm sorry if this is kind of off-topic, but since it didn't seem appropriate to start a thread just to ask a single question: I'm currently planning to code a little 2d engine and I'm planning to use SFML. Since it's going to take some time to get it ready: should I stick with the 1.x branch and somewhere in the future port the thing to 2.x or should I use 2.x directly?

I don't mind some breakage from time to time, but I don't want to spend most of my time fixing the thing instead of implementing my project :P