sf::ContextSettings, opengl version hint

[Laurent]

Ok, that's what I thought. Thanks for clarifying it. But what happens in 3.1 contexts? Deprecated functions are removed, but there's no compatibility profile yet, so what?

[l0calh05t]

Ok, that's what I thought. Thanks for clarifying it. But what happens in 3.1 contexts? Deprecated functions are removed, but there's no compatibility profile yet, so what?

If I'm not mistaken, you are quite plainly out of luck (SOL) if you have a system which only supports 3.1 and want to use GL 1.x functions. I presume this is why they introduced the concept of profiles in 3.2 (should have thought of it earlier...). For SFML this means that to be technically correct you would have to do the following:

• If the user requests 3.2+ with compatibility profile, and 3.2 is not available, ask for 3.0 (without setting the compatibility profile bit and mask), since 3.0 supports all 1.x functionality, but 3.1 does not.
• If the user requests 3.2+ without compatibility profile, you have to go to 3.1, again without setting the bit and mask. In this case, the lack of 1.x support should not matter (otherwise a compatibility profile would have been requested)
• When directly requesting 3.1 or 3.0 ignore the compatibility setting, as it wouldn't be valid (or maybe jump to 3.0 when 3.1 is selected with compatiblity)

It's ugly, but I don't think there is any clean way around this. The cleanest solution would probably be to combine mercurios array solution with a hardcoded exception when 3.2 fails and for 3.0 and 3.1 (as they don't support the mask and bit)

Or you could simply decide that you ignore this, as pretty much every graphics card that supports 3.0 also supports 3.1 through 3.3 (except, according to wikipedia the Intel sandy bridge 2000 and 3000 which only support 3.0). Personally though, I think this would be a bad, as you do know that there is a potential problem, and it is not that hard to solve.

[Laurent]

In fact the compatibility bit is set internally by SFML, because I need the deprecated functions. So I must disable 3.1 contexts, that's it.

[l0calh05t]

In fact the compatibility bit is set internally by SFML, because I need the deprecated functions. So I must disable 3.1 contexts, that's it.

Oh, ok, that is certainly simpler. Are you still using the begin/end drawing?

[Laurent]

Are you still using the begin/end drawing?

For now yes, but I'd like to change it for SFML 2.

[mercurio7891]

I am not sure, but I thought that the purpose of the forward compatibility bit is a stop gap measure by the opengl team, to allow code to still work with the old API.

However in future, all vendors would eventually drop support for the old functions. In such cases when calling with the compatibility bit set, it would allow a user to use the old functions, but it probably wouldn't work, as the card and drivers would no longer support them.

I am not 100% sure about this though.

Maybe in future, when Laurent upgrade the internal opengl code, we can ignore the compatibility bit in the 3.0++ versions?? and if user require the old functions, they can still request for a 2.0 version. Anyway if a user request a 3.0 version, it would mean they would be making changes to support a 3.0 version, and since they are making changes, it would be highly likely that they would change all code to support it rather than mixing 3.0 with 2.0 context.

It would be analogous to a person who is using DX9, but only upgrade half the program to run in DX10, normally a person would probably upgrade the whole program to run fully in DX10, and not in a manner when half the code uses DX10, and half uses DX9.

regards

[l0calh05t]

I am not sure, but I thought that the purpose of the forward compatibility bit is a stop gap measure by the opengl team, to allow code to still work with the old API.

Forward compatible would mean without the removed functions, "compatibility profile" would mean with the removed functions still available (backward compatible).

However in future, all vendors would eventually drop support for the old functions. In such cases when calling with the compatibility bit set, it would allow a user to use the old functions, but it probably wouldn't work, as the card and drivers would no longer support them.

I am not 100% sure about this though.

That may be the plan, but large vendors like nVidia already stated that they would continue supporting all OpenGL features for all new cards.

Maybe in future, when Laurent upgrade the internal opengl code, we can ignore the compatibility bit in the 3.0++ versions?? and if user require the old functions, they can still request for a 2.0 version. Anyway if a user request a 3.0 version, it would mean they would be making changes to support a 3.0 version, and since they are making changes, it would be highly likely that they would change all code to support it rather than mixing 3.0 with 2.0 context.

What SFML would need is different versions of the rendering code, one for 1.x to 3.0 (as 3.0 still includes all 1.x features!) And one for 3.1+ as the 3.1+ code would not work with GL versions 1.x through 2.x. But I believe a more flexible rendering backend is in planning anyways since it is needed for GLES as well.