SFML 2.0

[nullsquared]

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?

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.

No they don't.

Code: [Select]


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


Of course I did.

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]

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

Then they will belong to the same batch.

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.

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.

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.

[nullsquared]

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?

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.

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]

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.

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.

And replaced with what?

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

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.

[Nexus]

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?

[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.

Do you think it's enough to keep smooth images by default?

[Nexus]

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?

[Laurent]

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

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.

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.

[Nexus]

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));

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?

[Laurent]

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

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

Yes.

[bullno1]

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]

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

[kolofsson]

Hello. Today, on 12 April 2010, the Visual Studio 2010 has been released. Are there any plans to support it in SFML?

[Laurent]

Absolutely.

[Merkoth]

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