A few questions to main developers.

[ShqrdX]

Hello, I'm new user of SFML and have few questions..
1. Will SFML internals be rewritten to OpenGL Next(when it is released)?
2. Will SFML get DDS(Direct Draw Format) support for images ?
3. The core API will get changes or it is frozen for backward compatibility forever(like whole C++)?
4. Will basic math routines such as clamp function be implemented or its not "simple" ?

[Laurent]

1. Will SFML internals be rewritten to OpenGL Next(when it is released)?

Of course not... you know that OpenGL Next will not be compatible with previous versions, right?

2. Will SFML get DDS(Direct Draw Format) support for images ?

Why would SFML need to support that?

3. The core API will get changes or it is frozen for backward compatibility forever(like whole C++)?

Backward compatibility doesn't mean that things can't evolve. And for API breaking changes, there are major versions (SFML 3).

4. Will basic math routines such as clamp function be implemented or its not "simple" ?

The M in SFML is Multimedia, not Math.

[ShqrdX]

1. Will SFML internals be rewritten to OpenGL Next(when it is released)?

Of course not... you know that OpenGL Next will not be compatible with previous versions, right?

Oh, then it will be goal for other new libraries ...

Anyway, thanks for answering.

[binary1248]

Of course not... you know that OpenGL Next will not be compatible with previous versions, right?

Oh, then it will be goal for other new libraries ...

I think you misunderstood Laurent's answer. SFML won't be rewritten to support only OpenGL Next (when it is done). If SFML eventually supports OpenGL Next, it will have to be in addition to legacy support since we value being backwards compatible with fairly old hardware.

May I ask why you are asking these questions? They seem rather specific but unrelated to each other.

1. Will SFML internals be rewritten to OpenGL Next(when it is released)?

Do you need OpenGL Next support? What difference would it make for you? Nobody has an idea what it will even look like or be able to do yet, so asking whether it will be supported this early makes no sense. If it will become the only OpenGL API that gets updated by Khronos and implemented by IHVs in the future, then yes, we will have to support it eventually to remain future proof. However, that is still a very very long time from now.

2. Will SFML get DDS(Direct Draw Format) support for images ?

If it's just an image format, can't you load the data yourself? Currently sf::Image supports 32-bit RGBA pixel values and uploads texture data using that format as well. There is an issue on the tracker that investigates potentially adding more formats, and one them might make it easier to be able to load DDS.

3. The core API will get changes or it is frozen for backward compatibility forever(like whole C++)?

The SFML API is currently still evolving, while the general idea of SFML will probably remain the same throughout, there are no guarantees that your code will compile using the next major version. Normally this isn't a problem for users of the library, since they don't decide to upgrade to the next major version within the lifetime of a project.

4. Will basic math routines such as clamp function be implemented or its not "simple" ?

Why do you need a clamp function to be present in a library? Isn't it simple enough to write your own (possible templated) implementation in several lines?

[ShqrdX]

May I ask why you are asking these questions? They seem rather specific but unrelated to each other.

I'm perfectionist in programming, I dont like legacy code and I need some answers for myself about this library(which seems like perfect for 2d game programming for C++).

Why do you need a clamp function to be present in a library? Isn't it simple enough to write your own (possible templated) implementation in several lines?

This is common for C# game libraries(MonoGame,SharpDX). I come from these libraries to SFML because sometimes I tired to write managed code. Basically I'm C# dev with some C++ knowledge.

[binary1248]

I'm perfectionist in programming, I dont like legacy code and I need some answers for myself about this library(which seems like perfect for 2d game programming for C++).

That may be, and it is good that you strive to be perfect, but that doesn't mean that you have to care how a library ends up implementing its functionality. The whole point of using a library is abstraction - not having to know how it really happens at a lower level. As long as the external behaviour is consistent, the library would have done its job. In the end, when you request SFML to draw something in your window, it doesn't really matter whether it happened through OpenGL, Direct3D, Mantle or OpenGL Next does it? That is the reason why you are using SFML as a library, so you don't have to know how it really does things.

Instead of asking whether OpenGL Next will be supported in SFML (which is equivalent to asking whether SFML will implement things in a certain way), you should ask whether features are/will be supported by SFML. Those are questions we might be able to answer now, and if you suggest a feature that is good (this is what the feature request forum is for) it might even get added to SFML at some point.

This is common for C# game libraries(MonoGame,SharpDX). I come from these libraries to SFML because sometimes I tired to write managed code. Basically I'm C# dev with some C++ knowledge.

In C++, there is the standard library (automatically available with your toolchain, the stuff in the std:: namespace) which provides features that everyone uses (and should really use when possible), and external libraries that provide features that the standard library doesn't. Then there is the differentiation between header-only libraries and libraries you have to build. SFML is a library you have to build, whereas Eigen is a header-only maths library (which probably provides many different kinds of clamp functions ). I don't know how it is in C#, but you are less likely to find a C++ library that "does everything". You will have to use multiple libraries if the features you want are very unrelated, as is typical in games programming.

[Mörkö]

The whole point of using a library is abstraction - not having to know how it really happens at a lower level. As long as the external behaviour is consistent, the library would have done its job. In the end, when you request SFML to draw something in your window, it doesn't really matter whether it happened through OpenGL, Direct3D, Mantle or OpenGL Next does it? That is the reason why you are using SFML as a library, so you don't have to know how it really does things.

I disagree. One might use a library because it's abstractions are nice, but why are you stressing that the user should be happily oblivious to what goes on below the abstractions?

As an example, imagine if every time someone uses the SFML network module to send a packet, a copy of that packet is also sent to the SFML developers, Google or NSA, etc. If my packet is received where I intended to send it, then SFML would have superficially accomplished what it promised to do, but I would very much indeed care about what is going on internally.

[Laurent]

imagine if every time someone uses the SFML network module to send a packet, a copy of that packet is also sent to the SFML developers, Google or NSA, etc.

Are you really comparing this to the version of OpenGL used internally? ...
The fact that SFML uses OpenGL might be relevant for some users. Which version(s) of OpenGL is (are) used, who cares as long as it works on all the targeted platforms? This is exactly the kind of low-level questions that people don't want to bother with.

[binary1248]

I disagree. One might use a library because it's abstractions are nice, but why are you stressing that the user should be happily oblivious to what goes on below the abstractions?

You misunderstood me. I am not saying a user should not know (or be able to know) how something is implemented. I am saying they don't have to know. There is a difference.

SFML is open source, anyone can see how it implements stuff, and I also recommend anyone to do so to understand how to best use it if they have the time. The question here however, is whether the user should care about which underlying libraries/APIs are used. If the external behaviour (including performance characteristics) remains the same regardless of the underlying library/API that is used then it makes no sense to prefer one library over another. Does it matter if SFML uses Direct3D or OpenGL internally to draw stuff into your window? If it does exactly that, no more and no less, then it shouldn't matter. The only people left caring about such things are fanboys of either API who don't care about platforms that don't support Direct3D.

As an example, imagine if every time someone uses the SFML network module to send a packet, a copy of that packet is also sent to the SFML developers, Google or NSA, etc. If my packet is received where I intended to send it, then SFML would have superficially accomplished what it promised to do, but I would very much indeed care about what is going on internally.

This example is flawed. The external behaviour in this case would be inconsistent with the API documentation (because it does more... much more). Remember, it is not about what the library does, but how it does it. Your example delves into the territory of verification, making sure code does exactly what it is meant/advertised to do. It is important that security-related applications are verified, that is true, but to go back to my point: If the application does what it is supposed to do and is deemed secure, does it matter how it really does it? Probably not.

A better example:

int multiplyByTwo(int number);

Trying to establish the connection to this thread, someone might ask: Does the function use shifting? And I would also answer: Does it matter? Maybe it would to people who are big fans of shift operations, but for the sweeping majority it wouldn't. Then someone would come along and ask: Does it also do anything else? To which the answer would be: No, you can have a look if you want. Both shift and multiply variants would take care of this person's concerns.

[Mörkö]

Are you really comparing this to the version of OpenGL used internally? ...

No no, I was just making an extreme example.

[Mörkö]

You misunderstood me. I am not saying a user should not know (or be able to know) how something is implemented. I am saying they don't have to know. There is a difference.

In that case we agree, I mistakenly got the impression that you were encouraging people to be ignorant of the internals of libraries.

This example is flawed. The external behaviour in this case would be inconsistent with the API documentation (because it does more... much more). Remember, it is not about what the library does, but how it does it. Your example delves into the territory of verification, making sure code does exactly what it is meant/advertised to do.

Yes it would be inconsistent, and the possibility of such inconsistencies is a good reason why users ought to have an interest into the internals of libraries they run, which is all I'm arguing.

It is important that security-related applications are verified, that is true, but to go back to my point: If the application does what it is supposed to do and is deemed secure, does it matter how it really does it? Probably not.

That depends on what you mean. Deemed secure by whom? In that statement, are you for example including closed source applications, which the deemed secure by the company that created them and seem to do what they promise? In that case I strongly disagree.