OpenGL ES 3 (or 2) functionality

[Drifty Pine]

Hello!

I noticed in this thread from last year (April 18, 2020):
https://en.sfml-dev.org/forums/index.php?topic=27129.0
eXpl0it3r mentioned that OpenGL ES 1.1 will be used when SFML_OPENGL_ES is defined.

I am NOT very knowledgeable about OpenGL, but  I did some digging in the SFML code and it seems the version for the context is set by EaglContext::createContext() in "src\SFML\Window\EaglContext.cpp" (and for IOS: "src\SFML\Window\iOS\EaglContext.mm"). Does this actually force the context to be 1, or just make sure it is at least 1?

I ask because the file "src\SFML\Graphics\GLExtensions.hpp" has various defines set, particularly around framebuffer functionality, that map calls to actual functions beyond ES1.

Anyway, ES 2, and especially ES 3, offer some serious added functionality that I noticed is not compiled at all when SFML_OPENGL_ES is defined. For example, ES 3 fully supports glMapBuffer() and glBlitFramebuffer(), and ES 2 with extensions even supports glMapBuffer(). With these available, functions like VertexBuffer::update(const VertexBuffer& vertexBuffer) and Texture::update(const Texture&, unsigned int x, unsigned int y) would be available on ES devices.

Also, the SFML Shader fucntions that currently all return false when SFML_OPENGL_ES is defined could be used under ES 3. Perhaps even more of the Frame Buffer Object functionality provided by RenderTexture also. (For example, "GLExtensions.hpp" still defines GLEXT_framebuffer_blit to false when SFML_OPENGL_ES is defined.)

It seems most devices support at least ES 2 and many support ES 3 now days, isn't that correct?

There are 9 files where SFML_OPENGL_ES is currently used to limit functionality. Are there any plans to revisit these and change/refine the places where SFML_OPENGL_ES is used? Perhaps make more use of the ideas implied in "GLExtensions.hpp" for different ES versions?

As I mentioned, I am a novice with OpenGL, but I am certainly willing to help with any modifications to the 9 files by refining what should and should not get compiled, subject to review by someone else. Is there any interest in this?

Thanks to all involved for a truly wonderful library and for your time reading this message (that got a little longer than I expected)!

[NOTE: I originally posted this article to the wrong forum (Help.General), but I think it more likely belongs here (General.Feature requests) so I deleted the original and re-posted here.

[eXpl0it3r]

Yes, SFML currently only support OpenGL ES 1.1, because with ES 2.0 and on-wards the pipeline is very different and you can't as easily use the structure we've been using so far.
In detail, the pipeline is built on shaders and we have to update some internal code to make it work correctly and for backwards compatibility offer (semi-)transparent workarounds.

I think one of the ways would be something like the modular rendering backends, which would abstract the rendering itself.