Buffers and clipping?

[Skomakar'n]

Hello, there.

It would help me out tremendously, if there were any possibility to somehow work with buffers in SFML, or at least clip graphics in some way.

What I mean, is that I want to be able to define a rectangular area on the screen. Anything entirely outside of this area will not be drawn at all, and anything partially within it will be clipped.

Say I have this image rendered (a couple of sprites and shapes):



I then define a clipping rectangle like so (the non-darkened area):



Which will result in this being the final image rendered onto the screen:



I'm pretty sure it can be done in pure OpenGL, at least.
Would it be possible in SFML by modifying the view somehow? Are there other options? It would, again, help tremendously.

[Laurent]

SFML 1
This is not possible with SFML, but it's very easy to do it with OpenGL with the glScissors function.

SFML 2
It will be implemented soon in SFML 2, and it can already be emulated with views and their viewport.

[Skomakar'n]

I seem to have gotten it working with the glScissor() function. Thanks a lot!

[Tank]

SFML 2
It will be implemented soon in SFML 2, and it can already be emulated with views and their viewport.

Very neat! Do you already know how it will be implemented? I've been waiting for that for months.

[Laurent]

Do you already know how it will be implemented?

Most likely with GL clip planes. As for the public interface, it will depend on the new drawable stuff that I'm currently writing.

[Spidyy]

It will depend on the new drawable stuff that I'm currently writing.

At wich point the drawable will change? More precisely about the Render functions and the sf::Renderable?

[Laurent]

At wich point the drawable will change? More precisely about the Render functions and the sf::Renderable?

I want to provide an interface which is much lower-level than the current one. Sprites, texts and shapes are definitely too high level for a library that aims at being a generic building block for 2D drawing.
So that means a definition of the geometry which is closer to what OpenGL provides: vertex arrays, points with position/color/texcoords, etc. Transformations will also probably be separated into their own class, and combined with geometry only at draw time; I don't want this Drawable base class that everybody wants to derive anymore.

I don't know yet if I'll still provide the old sprite/text/shape classes on top of that, but even if I don't, I'll provide them at least on the wiki or as an add-on, so that users can make the transition smoothly.

This stuff is still in a very early stage, but I'm open to any comment or suggestion.

[Tank]

That sounds like a radical change of SFML's current "philosophy". Can you provide some more details of the implementation? Maybe a code example that explains how you'd like to use SFML in the future. (personally I love such examples that don't actually work, but show what features are planned or how the new code should "feel")

Generally I don't think it's a bad idea, you're focussing on the interface that supports things like sprites, texts etc. instead of continuing to develop SFML to a gaming engine -- to be honest, it's already a basic one.

However, I've always liked the fact that SFML enables me to either only access my accelerated hardware or build concrete applications that make use of all the fine little classes that SFML provides.

So I think separating the high-level stuff from SFML is a good idea, but I'd definitely not drop it off from the official release, neither provide the high-level classes as an add-on. What do you think of another SFML package that brings in all the basic high-level drawing classes? Personally I think SFML wouldn't be so useful and popular if it didn't provide those.

Please keep us involved, even in your planning stage. At least I am very interested and also somehow afraid of SFML's future regarding its origin. (not to mention that SFGUI makes high usage of SFML's high-level classes, so I'd be a bit pissed if you threw them away! j/k)

[Laurent]

I have nothing to show you, it's too early. I'm still working on the public interface of the new classes -- I don't even know which classes I'm going to add.

But don't worry, the SFML philosophy won't change. I just want to make things more flexible, not more complicated. My secret hope is that I can find such a clever design that high-level drawable classes won't be needed anymore :lol:

I'll open a new discussion as soon as I have something interesting to show.

[Tank]

Great, already thought so. In that case it just sounds interesting, I'm looking forward to new info, thanks.