SFML 3 - What is your vision?

[silverweed]

One thing I'd really like to have is the ability to independently set the translation, scale and rotation origin for sf::Transformable. I know I can use sf::Transform directly, but I think a middle-ground solution would be convenient, as the complication of using sf::Transform is barely justified for such a common¹ need IMHO.

¹ "common" in my experience, of course. Maybe there are far fewer people than I think who ever need this capability.

[eXpl0it3r]

Can you elaborate more on your problem?
sf::Transformable has all the set and get functions for transform, scale and rotation.
Or do you mean, you want to access a transform that has only set the scale or only set the transform?

Personally, I would say if such transforms are needed, then your own custom "layer" might be useful that provides such an interface and generates the various transforms.
I mean SFML itself doesn't hold the transforms separately, so they would need to be calculated anyways.

[Hapax]

It sounds like Silverweed would like to be able to use a separate origin for each transformation.

[Sygmei]

I do agree, separate origins would be nice, I needed it and had to create a whole class for it.

[Phanoo]

- Automatic batching of draw calls that use the same texture
- More powerful Text class : set line height, letter spacing, align releative to user defined bounds, automatic wrapping...
- Drag & drop support
- Clipboard support

[Laurent]

set line height, letter spacing
Clipboard support

All done (will be released in 2.5). This kind of non-breaking changes don't need to wait for SFML 3, and we can discuss them at any time in the "feature request" sub-forum.

Don't hesitate to have a look at github to be aware of the coming / pending changes.

[Phanoo]

Very nice ! I think i'll get the development version to start using it.

[MetalCoder]

Will there be a C and .NET port of SFML 3?

[Laurent]

Will there be a C and .NET port of SFML 3?

If someone writes them, yes.

[MorleyDev]

Not sure if this has been brought up before, probably has, but it occurs to me a current limitation with SFML is that you cannot dynamically swap the underlying rendering platform at runtime. To use Irrlicht as an example, you can create DirectX drivers, OpenGL drivers, and Software Rendering drivers and decide on which one to use at runtime.

If SFML allowed for this, even if it only had one officially supported driver, it would serve to document *how* a person who needs to can modify SFML to support a different rendering platform, which at the moment feels more like going in and 'hacking SFML apart until it works'.

This could aid future efforts for support for new platforms that may not necessarily have any OpenGL access, and would make porting to DirectX, or even back down to older versions of OpenGL, or to Vulkan, or to a chosen version of OpenGL ES easier for people who decide they want to do so for whatever reason.

It would also keep a migration path open for developers if/when SFML moves up to newer OpenGL versions as they come out and settle, allowing for older ones to have official support deprecated without immediately breaking code and requiring a new major release.

Additionally, if SFML was also 'interface-driven' (which fits nicely with the above), then SFML could be easily mocked out when unit testing the graphics code, and that'd also be quite nice. At present you need to write a facade around SFML to accomplish this. Though I admit, not as many people care about unit testing their game rendering code as should darn it

[Laurent]

I'm not in favor in abstracting the graphics back-end. I don't think it has any practical benefit (except the "technical challenge" and "others do it"), and would make the code less maintainable (any addition has to be implemented in all the back-ends) and less optimizable.

However, I know that other team member(s) have a different opinion on this topic, so who knows

[Tank]

I don't like it much because I fear that more projects would use DX because it's more known or "all the other AAA games use it so it must be better". Lots of SFML projects aren't cross-platform already because people use platform-specific path separators ('\' vs '/'), Windows-only headers or case-insensitive filenames. With a DX backend, people might be more tempted to use DX-exlusive features.

[DeathRay2K]

I think it would only make SFML more flexible to include a layer of abstraction over the graphics back-end. I don't think it makes sense for that to include developing additional back-ends though. There's no reason there should be an official DirectX back-end, but a developer who knows they need such a thing will have the option to create one and ensure it will integrate relatively easily with SFML.

If someone is using SFML more casually, they will surely use the default OpenGL back-end and have the best chance of developing cross-platform code. Besides, with a common abstraction for all graphics back-ends, there's no opportunity for adding DX-specific features without sidestepping the abstraction or building the feature into it.

A clean abstraction should make the code easier to maintain as well, as long as it doesn't mean developing additional back-ends.

[MorleyDev]

Sorry if this wasn't clear, but I wasn't specifically suggesting actually maintaining multiple official backends. The key point was more:
* "If SFML allowed for this, even if it only had one officially supported driver, it would serve to document *how* a person who needs to can modify SFML to support a different rendering platform, which at the moment feels more like going in and 'hacking SFML apart until it works'."

That and the interface-driven point, namely interfaces enabling mocking out of SFML for easier unit testing of code that calls SFML

[Laurent]

It's nearly impossible to design a robust abstraction for graphics rendering with only a single back-end in mind. You have to cope with limitations and design philosophy of all back-ends -- at least the two major ones. This also means that your abstraction, being a common denominator, will be less flexible and optimized, compared to what we do currently with the direct OpenGL integration.

Is there any use of interfaces other than for unit testing?