SFML 2.0

[gsaurus]

looks good, it will take a couple of years to do all this right?

I hope to finish it in 2009

How's it going? Any idea about when it will be released?

I plan to remake much of the code of a project that is using SFML 1.5 (structure issues). I should start somewhere on the beginning of 2010 and I wish I can use the final release of SFML 2.
If release isn't planned for soon, I might give the SVN version a try (but final is final, and I also like to avoid eventual compilation problems with the SVN)
Anyway, you're doing an awesome work!

Oh, and merry Christmas to everyone  :wink:

[Laurent]

How's it going? Any idea about when it will be released?

It's not close enough to the final release for me to give an estimation. But I'll try to focus on the changes that break the public API, and keep the additions for future minor 2.x releases.

and I also like to avoid eventual compilation problems with the SVN

I never commit something that doesn't compile. If it happens, simply report it here and I fix it as soon as I can (it's often a matter of minutes).

[Mr. XYZ]

This is a little offtopic, but have you ever considered moving development to a distributed version control system like Git or Mercurial? Maybe you could get more contributions from others if your project were hosted in something like Google Code, Bitbucket or Github (all 3 allow easy forking)?

[Laurent]

I agree with this. Distributed systems like Git / Mercurial make branching and developing your own contribution really easy.

However I don't really want people to start creating branches, developing their own stuff (sometimes huge contributions), and submit it to me. SFML is not a community project, I like controlling and implementing stuff myself, and I like the current system where people write their requests or submit their patches here

[phear-]

Not to mention that I hated using Git in my last project...

[nullsquared]

Any porting notes for 2.x?

What displays in 1.6 does not display in 2.x (blank window), the only change of code I've done is replace View::SetRect() calls with View::SetViewport() calls since SetRect() is gone.

[Laurent]

Any porting notes for 2.x?

Not yet, but of course there will be one for the first public release.

What displays in 1.6 does not display in 2.x (blank window), the only change of code I've done is replace View::SetRect() calls with View::SetViewport() calls since SetRect() is gone.

SetRect has been replaced with Reset. SetViewport sets the viewport, which is a completely different thing.

By the way, the API documentation of this class is up-to-date, you can look at it in the View.hpp header.

[nullsquared]

SetRect has been replaced with Reset. SetViewport sets the viewport, which is a completely different thing.

Thanks, that (semi) fixed it.  What's the point of RenderTarget keeping a reference to the view when you need to call SetView() every time you Reset() it? (otherwise the changes have no effect for me)

Also, is the OpenGL state for the matrices pushed and popped for every single object that is drawn?  I rendered some 2D objects in the same coordinate system as everything else via raw OpenGL - however, now that does not work, the OpenGL-drawn objects are always drawn with an identity matrix.  What exactly changed here and why?

[Laurent]

What's the point of RenderTarget keeping a reference to the view when you need to call SetView() every time you Reset() it? (otherwise the changes have no effect for me)

It doesn't keep a reference to the view anymore, it was changed recently to store the view by value so that you have to call SetView everytime the view changes.

Also, is the OpenGL state for the matrices pushed and popped for every single object that is drawn? I rendered some 2D objects in the same coordinate system as everything else via raw OpenGL - however, now that does not work, the OpenGL-drawn objects are always drawn with an identity matrix. What exactly changed here and why?

Your OpenGL objects are drawn with the matrix that you setup, SFML doesn't alter the OpenGL states.
Note that SFML 2 doesn't actually draw when you call Draw, it stores everything in a render queue and renders everything when you call Display. So if you want to draw something on top of SFML objects, you have to force rendering with Flush.

[nullsquared]

What's the point of RenderTarget keeping a reference to the view when you need to call SetView() every time you Reset() it? (otherwise the changes have no effect for me)

It doesn't keep a reference to the view anymore, it was changed recently to store the view by value so that you have to call SetView everytime the view changes.

Code: [Select]


////////////////////////////////////////////////////////////
/// Change the current active view
////////////////////////////////////////////////////////////
void RenderTarget::SetView(const View& view)
{
    // Save it
    myCurrentView = view;

    // Send the view's viewport and projection matrix to the render queue
    myRenderQueue.SetViewport(GetViewport(view));
    myRenderQueue.SetProjection(view.GetMatrix());
}

This is from branches/sfml2, HEAD revision.  Edit: Wait, myView is not a reference?

Your OpenGL objects are drawn with the matrix that you setup, SFML doesn't alter the OpenGL states.

Could I get a little breakdown of what exactly SFML does during the rendering process?  Not too specific but I want to see how it handles all the transformations and renders from a higher level.

Note that SFML 2 doesn't actually draw when you call Draw, it stores everything in a render queue and renders everything when you call Display. So if you want to draw something on top of SFML objects, you have to force rendering with Flush.

This is why I want the higher level breakdown I mentioned, because from what I can see, the queue essentially filled and cleared every frame?  That has no advantage over immediate mode, in fact, it should be slower.

[Laurent]

This is from branches/sfml2, HEAD revision. Edit: Wait, myView is not a reference?

It wouldn't work if it was a reference. References can only be initialized at declaration, so this would still be a copy anyway. To keep a reference instead of copying the view, the myCurrentView member would have to be a pointer (that was the case before).

Could I get a little breakdown of what exactly SFML does during the rendering process? Not too specific but I want to see how it handles all the transformations and renders from a higher level.

Why? The purpose is that you don't have to care about what SFML does internally, it never impacts what you do with OpenGL outside. I could tell you about the internal details, but there's no point for you to know that, it should even change in the next days.

This is why I want the higher level breakdown I mentioned, because from what I can see, the queue essentially filled and cleared every frame? That has no advantage over immediate mode, in fact, it should be slower.

It allows batching, which is much faster. It also reduces the number of states changes from N (number of drawables) to 1 per frame.

[nullsquared]

It wouldn't work if it was a reference. References can only be initialized at declaration, so this would still be a copy anyway. To keep a reference instead of copying the view, the myCurrentView member would have to be a pointer (that was the case before).

Oh yeah I'm just being stupid.  Comment is a bit misleading.

Why? The purpose is that you don't have to care about what SFML does internally, it never impacts what you do with OpenGL outside. I could tell you about the internal details, but there's no point for you to know that, it should even change in the next days.

Because I want to render with OpenGL under SFML's view transformation.  For example, now there is no way for me to draw 1-pixel-wide lines, for, say, a grid.  Now I have to manually push SFML's view transformation back onto the OpenGL state.

It allows batching, which is much faster.

I don't see any batching, every drawable seems to make a new batch every frame.  Besides, you can't just batch any N drawables together because they might be overlapping, in which case you will get inconsistent behavior (one might show on top of the other even though you want to draw it first).

It would be much more efficient for every drawable to create its own VBO at time of creation or modification, and keep that VBO until it dies.  If the user wants to batch things together, he can use a BatchDrawable which takes the VBOs of N Drawables and puts them all into a single VBO which then moves as a whole.

This is how high-performance 3D engines do it, and it is no different in 2D.

It also reduces the number of states changes from N (number of drawables) to 1 per frame.

I don't understand how reducing the amount of state changes has anything at all to do with the queue.  You can have a list of random objects and still have a single state change, regardless of a queue.

[Laurent]

Because I want to render with OpenGL under SFML's view transformation. For example, now there is no way for me to draw 1-pixel-wide lines, for, say, a grid. Now I have to manually push SFML's view transformation back onto the OpenGL state.

This is intended, SFML doesn't expose its internal states to the outside. Like I already said, you'll have to setup your own OpenGL view to match SFML's one. Any other solution would be a hack, and my break any time after an internal modification.

I don't see any batching, every drawable seems to make a new batch every frame

Look further, into the sf::RenderQueue class.

Besides, you can't just batch any N drawables together because they might be overlapping, in which case you will get inconsistent behavior (one might show on top of the other even though you want to draw it first).

The current implementation takes this issue in account properly. The order of drawing is not modified.

It would be much more efficient for every drawable to create its own VBO at time of creation or modification, and keep that VBO until it dies. If the user wants to batch things together, he can use a BatchDrawable which takes the VBOs of N Drawables and puts them all into a single VBO which then moves as a whole.

I can't assign a single VBO to every drawable. This would be inefficient, and make drawables not sa lightweight as they are currently.
But don't worry, the current code works well and I'm currently making it even better.

I don't understand how reducing the amount of state changes has anything at all to do with the queue. You can have a list of random objects and still have a single state change, regardless of a queue.

Maintaining states through the lifetime of an entire frame (with possibly external OpenGL calls between) requires more work than when everything is done in a single function.

[nullsquared]

This is intended, SFML doesn't expose its internal states to the outside. Like I already said, you'll have to setup your own OpenGL view to match SFML's one. Any other solution would be a hack, and my break any time after an internal modification.

Why not add View::applyProjectionGL() or something like that?

The current implementation takes this issue in account properly. The order of drawing is not modified.

How?  Consider 2 objects that qualify for a single batch (same shader/texture/etc.)  If they are overlapping, their triangles will be part of a single draw call - thus, regardless of the Draw() order, the actual order in which they will appear over each other would be up to the GPU.  There is no clever trick or anything in the code (such as using the ZBuffer), so how is it handled?

I can't assign a single VBO to every drawable. This would be inefficient,

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.

and make drawables not sa lightweight as they are currently.

... They already hold their all vertices, what "lightweight" are we talking about?

Have you actually profiled it against what I'm suggesting?  Or really against anything else?  I'm willing to bet that the old immediate mode code is faster than the current code for a lot of scenes.  Right now you're filling one giant VBO (more if objects vary in texture/shader/etc.) every frame.

[Laurent]

Why not add View::applyProjectionGL() or something like that?

Because I don't want to add such things into SFML

How? Consider 2 objects that qualify for a single batch (same shader/texture/etc.) If they are overlapping, their triangles will be part of a single draw call - thus, regardless of the Draw() order, the actual order in which they will appear over each other would be up to the GPU. There is no clever trick or anything in the code (such as using the ZBuffer), so how is it handled?

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.

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.

... They already hold their all vertices, what "lightweight" are we talking about?

No they don't.

Have you actually profiled it against what I'm suggesting? Or really against anything else?

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?

Now I'll stop discussing, I don't like the way you answer to me. You're talking as if you wrote SFML but you obviously know nothing about it. You talk about critical internal details, but first have a look at the source code and come back when you know that the batching system works well with the drawing order, and that sprites don't "already hold their all vertices". Thank you.