Error Message On Incorrect ContextSettings

[Hapax]

Setting one of the context settings' attributes to one that will fail causes an error message to be displayed. I don't think it's always been like this; to quote the documentation for sf::ContextSettings:

No failure will be reported if one or more of these values are not supported by the system; instead, SFML will try to find the closest valid match.

which obviously isn't true anymore.

Is there, at least, a way to suppress this error message? Preferably, at least for release mode.

Here's some short code that now causes the error message to be shown:

#include <SFML/Graphics.hpp>
int main()
{
        sf::ContextSettings contextSettings;
        contextSettings.antialiasingLevel = 128; // changing just one unsuccessful setting can make SFML display an error message

        sf::RenderWindow window(sf::VideoMode(800, 600), "Context Settings", sf::Style::Default, contextSettings);
        while (window.isOpen())
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                                window.close();
                }
                window.clear();
                window.display();
        }
        return EXIT_SUCCESS;
}

Error message (on my computer):

Warning: The created OpenGL context does not fully meet the settings that were requested
Requested: version = 1.1 ; depth bits = 0 ; stencil bits = 0 ; AA level = 128 ; core = false ; debug = false
Created: version = 4.2 ; depth bits = 24 ; stencil bits = 8 ; AA level = 4 ; core = false ; debug = false

I intentionally overshot the anti-alias maximum value by using an impossibly high value but it works the same if you overshoot it by anything (e.g. on my computer, trying 8). Overshooting seemed to be the solution previously due to not knowing the maximum (anti-alias level) it could achieve.

Commenting out the anti-aliasing assignment stops the error message as ContextSettings having default values for all of its attributes will cause it to find a match with no error message.

This also brings up another question: is it possible to disable the stencil buffer - or depth buffer - (as mentioned in this tutorial) as it requires the stencil bits to be set to zero but this is ContextSettings' default value and finds a match (see error message above).

EDIT: Turns out that for depthBits and stencilBits, anything lower will be 'promoted' while anything higher will cause the same error message.

[Nexus]

The ContextSettings error message was introduced not too long ago, the documentation has not been updated yet.

There is currently no way to suppress this specific message. We plan to make error reporting more flexible in the future, i.e. give the user more control about what errors are generated.

[Hapax]

That makes sense. I thought it was a new addition; I don't remember it happening before. Even the example codes cause this error and there isn't really a way to avoid it (other than using default settings).

More control over which errors is a good thing and something I look forward to. However, with this particular error (and others that can't be disabled and show in standard usage), until this flexibility is introduced, it should be disabled for the release build.

[Nexus]

Is it really a problem? On Windows, Release builds usually have no console, so nobody ever sees the messages. And in any case, you're able to drop std::err()'s underlying stream buffer.

[Hapax]

It's not a massive problem. I was just suggesting a more user-friendly approach.

I don't think saying that Windows usually have no console is a solution. Sometimes Windows programs do have consoles. Moreover, that doesn't solve it for other operating systems.

Dropping std::err()'s stream isn't a particularly good solution either. Just because it's a release build does not mean the program will not want to output errors.

[Nexus]

It's not a massive problem. I was just suggesting a more user-friendly approach.

Yes, and it will come when the error output is redesigned

I don't think saying that Windows usually have no console is a solution. Sometimes Windows programs do have consoles.

Yes, hence "usually" and not "always". Those cases are rare in the real world, especially for games. In the few cases, where the console constitutes a relevant part of the user interface, you'd generally want to redirect sf::err() to another place, in order to not interfere with the user experience.

I'm not saying it's a solution, by the way, merely an observation.

Dropping std::err()'s stream isn't a particularly good solution either. Just because it's a release build does not mean the program will not want to output errors.

You wrote: "However, with this particular error (and others that can't be disabled and show in standard usage), until this flexibility is introduced, it should be disabled for the release build."

So, unless you want to disable sf::err() entirely, which errors would that be? Different users will have different views on what errors are considered important; arbitrarily disabling some messages will make other people unhappy. I don't think having a half-hearted interim solution is the way to go, we should rather think about making error output truly configurable.

[Hapax]

unless you want to disable sf::err() entirely, which errors would that be? Different users will have different views on what errors are considered important; arbitrarily disabling some messages will make other people unhappy.

Probably crashing errors, maybe major-usage-breaking errors, but not something that isn't even an error - it's merely the result of trying to set something, as you usually would "for games". You want anti-alias in your game, you can't risk setting it at all in case of your end-user receiving a harrowing message.
However, this was not my point about std::err(). The program itself might want to send errors; it should be allowed to do this using the standard error stream.

I don't think having a half-hearted interim solution is the way to go, we should rather think about making error output truly configurable.

The configurable solution is honourable and will be worth the wait, I'm sure (I think that sounded sarcastic so this comment is to assure you that it was sincere), but I don't think it's a "half-hearted interim solution" when what would be happening is removing a recent addition that shouldn't be forced, especially during release builds.

[Nexus]

However, this was not my point about std::err(). The program itself might want to send errors; it should be allowed to do this using the standard error stream.

sf::err() was introduced to allow independence from std::cerr, for this very reason.

but I don't think it's a "half-hearted interim solution" when what would be happening is removing a recent addition that shouldn't be forced, especially during release builds.

Yes, it should have warning/info rather than error nature, but at the moment this isn't possible. Maybe you're right about the Release/Debug difference, as that's already happening for alCheck/glCheck (which are errors).

Would be nice to hear other opinions on this topic.

[Hapax]

sf::err() was introduced to allow independence from std::cerr, for this very reason.

I totally missed this distinction. I'm sorry.

(Attempt to) disable the stream on release builds it is, then!