[Android] Issue or not? static sf::Shader creation results in crash.

[Daid]

Extremely simple. I'm not sure if it is allowed or not. But when I have a global sf::Shader object defined somewhere in the code, the Android version of SFML crashes during startup somewhere in the SFML-Window code (backtrace is sadly useless in this case, so took me quite a while to track down)

Example is simple, just modify the android example code do this:

#include <SFML/System.hpp>
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <SFML/Audio.hpp>
#include <SFML/Network.hpp>

sf::Shader test_shader;

int main(int argc, char *argv[])
{
    return 0;
}
 

(Tested on a S3 phone, which runs the example fine)

[eXpl0it3r]

You should not use global SFML resources since it can cause many different issues.

[Mario]

Despite that, the mobile ports of SFML are still based on OpenGL ES 1.1, which only supports the fixed render pipeline, which means unfortunately there isn't any shader support.

[Daid]

Despite that, the mobile ports of SFML are still based on OpenGL ES 1.1, which only supports the fixed render pipeline, which means unfortunately there isn't any shader support.

Which makes the issue even more odd on that end.

You should not use global SFML resources since it can cause many different issues.

Rogger. Wanted to refactor that code anyhow, but it was quick&dirty working quite fine. (But could also explain why OSX is causing issues)

And I think you mean that no SFML objects should be created before main() is run? Cause a private static member isn't strictly global, but constructed at the same point in time and thus will cause the same issues.

[Jesper Juhl]

Despite that, the mobile ports of SFML are still based on OpenGL ES 1.1, which only supports the fixed render pipeline, which means unfortunately there isn't any shader support.

Which makes the issue even more odd on that end.

How so?
Shaders are not supported. Creating a shader crashes the program. News at 11.
What's odd?

[Daid]

What's odd?

Because on windows and linux, when shaders are not supported, creating an sf::Shader object is just fine, but using it results in warning/error notices that shader support is not working.

Not supported, and crash and burn in hell when you try to use it are two very different things. Especially if the shaders have a function to check if they are available and supported.

(I did assume that "not supported" meant "not implemented", at which point crash&burn is really odd for something that isn't even implemented)

[Rosme]

How is it odd that calling something that don't exist crashes? Windows/Linux is different than Android. You can't assume that because something behaves in some way in A, that it will behave the same way in B. Luckily for us, Windows and Linux have fallback that tells you it's not supported. Android does not.

[Laurent]

And I think you mean that no SFML objects should be created before main() is run? Cause a private static member isn't strictly global, but constructed at the same point in time and thus will cause the same issues.

Yes, we mean global scope, not global access. What's important is when the variable is constructed and destroyed, not how it is available to the rest of the code.

Not supported, and crash and burn in hell when you try to use it are two very different things.

You're absolutely right. A crash is almost always a bug, unless you're doing something that is clearly documented as undefined behaviour.
On platforms that use OpenGL ES 1.1, sf::Shader is an empty shell. So it can be instantiated, and functions can be called. It will just do nothing.