SFML crash on Galaxy S22

[Zombieschannel]

Subject of the issue

So this gets quite complicated but here is what I got.
While testing I found that for some unknown reason the SFML 2 app crashes on the Samsung galaxy S22. Since I've previously tested the same code on a dozen different devices from different manufacturers, it was quite weird. Well, it seems to crash in the window.draw() function no matter what you ask it to draw. I've tested another app that just clears the screen to a specific color and doesn't draw anything and it works without any issues.
I've captured the call stack of the crash:

as well as the specific line that it crashed on:

My conclusion:

It seems like the galaxy S22 series has a completely new GPU compared to literally any other smartphone.
The Xclipse 920 that it has is the only Xclipse GPU ever. The now new s23 series no longer has this Xclipse GPU.
So I guess it could be a graphics driver issue. Or something similar. I haven't tried just removing this line that the program crashes on as I'm unsure what it does exactly.

Your environment

Android Studio 2022.1.1 on Windows 10
SFML 2.6.x branch
Used CMake, Ninja, Android NDK 25

[Zombieschannel]

After analyzing this issue further, it seems like the S22 indeed does not have this extension glBlendEquation (or at least not when using GLES 1.0) resulting in a crash. Simply changing the else { ... } to else if (GLEXT_glBlendEquation) { ... } should be a fix. I'll make a pull request soon.

[Zombieschannel]

Just an interesting observation, after "upgrading" SFML to use GLES 2, all of the issues are gone.

[vittorioromeo]

Just an interesting observation, after "upgrading" SFML to use GLES 2, all of the issues are gone.

Are you planning to PR your https://github.com/Zombieschannel/SFML/tree/emcc branch into SFML upstream eventually? It would be a fantastic addition to SFML 3.x, and I've wanted Emscripten support for a long time!

It would actually make SFML usable for web browser games, greatly increasing its usage.

[Zombieschannel]

Just an interesting observation, after "upgrading" SFML to use GLES 2, all of the issues are gone.

Are you planning to PR your https://github.com/Zombieschannel/SFML/tree/emcc branch into SFML upstream eventually? It would be a fantastic addition to SFML 3.x, and I've wanted Emscripten support for a long time!

It would actually make SFML usable for web browser games, greatly increasing its usage.

Although I agree it would be cool to have SFML on the web, that branch does not have much progress (just SFML with GLES2 and some slight changes) as I currently do not have much time to work on it. Also, I am absolutely not familiar with Emscripten, so it will take time. I am planning to work on this branch more during this summer.
But yes, eventually.

This branch would also require SFML to use GLES2 and while I do have an SFML 2.6 branch which mostly works https://github.com/Zombieschannel/SFML/tree/GLES2, it would still need to be approved and I'm not sure could that happen considering that newer OpenGL is planned for SFML 4...?

[vittorioromeo]

Just an interesting observation, after "upgrading" SFML to use GLES 2, all of the issues are gone.

Are you planning to PR your https://github.com/Zombieschannel/SFML/tree/emcc branch into SFML upstream eventually? It would be a fantastic addition to SFML 3.x, and I've wanted Emscripten support for a long time!
It would actually make SFML usable for web browser games, greatly increasing its usage.

Although I agree it would be cool to have SFML on the web, that branch does not have much progress (just SFML with GLES2 and some slight changes) as I currently do not have much time to work on it. Also, I am absolutely not familiar with Emscripten, so it will take time. I am planning to work on this branch more during this summer. But yes, eventually.

This branch would also require SFML to use GLES2 and while I do have an SFML 2.6 branch which mostly works https://github.com/Zombieschannel/SFML/tree/GLES2, it would still need to be approved and I'm not sure could that happen considering that newer OpenGL is planned for SFML 4...?

I'd love to steer our priorities and directions to support SFML on the web -- I think it would make the library much more popular for game jams, to easily distribute smaller games and prototypes, and potentially to support mobile devices much more easily. @ChrisThrasher, thoughts?

Regardless, isn't GLES2 quite ancient now? I remember reading it being deprecated in Unity/Android in favour of GLES3. Is it that much more different?

[Zombieschannel]

GLES2 is quite ancient now, yes, however there aren't any SFML features that would use GLES3 functionality. So sticking with GLES2 would just support more hardware (although all Android devices in the last ~10 years have GLES3)

Also, SFML currently uses GLES1 which isn't compatible with GLES2 (you cannot mix them like you can mix OpenGL 1 with OpenGL 4 on pc) while GLES2 can be mixed with GLES3.

The main issue with SFML on mobile currently is this mixing issue as GLES1 does not support shaders.
GLES2 supports shaders and that is an issue since SFML does not force the user to provide shaders. Since shaders work how they work, users would need to know names of uniforms SFML uses (I think I read somewhere on forums that SFML is not ready for modern OpenGL because of this). My branch added 2 default shaders in case the user does not provide any (making any current SFML 2.6 project work out of the box with my branch as long as it doesn't use shaders, shader code will have to be split between GLSL and GLES SL)
Hope all this makes sense 🙂

[vittorioromeo]

GLES2 is quite ancient now, yes, however there aren't any SFML features that would use GLES3 functionality. So sticking with GLES2 would just support more hardware (although all Android devices in the last ~10 years have GLES3)

Also, SFML currently uses GLES1 which isn't compatible with GLES2 (you cannot mix them like you can mix OpenGL 1 with OpenGL 4 on pc) while GLES2 can be mixed with GLES3.

The main issue with SFML on mobile currently is this mixing issue as GLES1 does not support shaders. GLES2 supports shaders and that is an issue since SFML does not force the user to provide shaders. Since shaders work how they work, users would need to know names of uniforms SFML uses (I think I read somewhere on forums that SFML is not ready for modern OpenGL because of this). My branch added 2 default shaders in case the user does not provide any (making any current SFML 2.6 project work out of the box with my branch as long as it doesn't use shaders, shader code will have to be split between GLSL and GLES SL) Hope all this makes sense 🙂

Makes complete sense, thanks for explaining. I think this is the right way forward for SFML :)

[ChrisThrasher]

I think it would make the library much more popular for game jams, to easily distribute smaller games and prototypes, and potentially to support mobile devices much more easily. @ChrisThrasher, thoughts?

It would be really cool if SFML could target the web one day. As for getting there, SFML 3's mandate explicitly excludes overhauling or heavily reworking the rendering code. Perhaps once the v4 development cycle begins hopefully next year we can start investing what it would take to support targeting the web.

[binary1248]

@vittorioromeo Someone already worked on this 9 years ago but as described above, the changes couldn't be merged into upstream because sfml-graphics still used legacy OpenGL and getting the non-legacy OpenGL change to be merged was a hard ask at that time because it would have required user shaders to be written differently. Also, the recent rewrite of the audio backend to use miniaudio was in part motivated by the experience of porting sfml-audio back then. In the OpenAL implementation SFML still had to run its own thread to continuously feed sf::SoundStream data, and at that time threads were not supported by the emscripten compiler (it was still pretty new).

If anyone wants to see the code: https://github.com/binary1248/SFML/tree/emscripten

That experimental port was actually successfully used to build some games submitted to the SFML game jam that took place around the same time (what a coincidence huh? 😁).

Oh look what I found here: https://duerrenberger.dev/pub/Synth-Guitar.html @eXpl0it3r will attest that this was actually written in SFML. 😁

Some big changes targeting SFML 3 and more coming in SFML 4 have been leading up to being able to provide first-party support for web applications written with SFML. This has been 10 years in the making and is still on the TODO list.

We should start holding SFML game jams again. It would be interesting to see how the SFML 3 changes will effect how code is written now, almost 10 years after the last one. 😁

[vittorioromeo]

@binary1248: it's great to see that SFML was successfully used in the past with Emscripten -- but also sad to see that all your work was never integrated into the main branch.

Emscripten/GLES2 support is something I am greatly interested in, I think it should be a priority for SFML to run on the web and more mobile devices.

How do you suggest we make this happen for 3.x?

I think starting with GLES2 support would be a good option, using the approach where SFML comes with some default shaders.

What are the biggest difficulties and roadblocks in making this happen, and do you think we can come up with a rough roadmap?

I'm happy to do the work, but I am not very experienced with GLES2 and Emscripten, so I'm not entirely sure what would the best course of action be.

[binary1248]

The scope of the changes required to properly support GLES 2 in SFML 3 is too large, and we want to release at some point. That's why all OpenGL/Vulkan/Emscripten related stuff should take place after 3 is released and we start working on 4. Starting to work on it now would only delay the release by at least a year while the new API matures and the implementation stabilizes.