SFML community forums

Help => Window => Topic started by: Daid on July 15, 2015, 10:19:35 am

Title: [Android] Issue or not? static sf::Shader creation results in crash.
Post by: Daid on July 15, 2015, 10:19:35 am
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)
Title: Re: [Android] Issue or not? static sf::Shader creation results in crash.
Post by: eXpl0it3r on July 15, 2015, 10:31:43 am
You should not use global SFML resources since it can cause many different issues.
Title: Re: [Android] Issue or not? static sf::Shader creation results in crash.
Post by: Mario on July 15, 2015, 11:30:27 am
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.
Title: Re: [Android] Issue or not? static sf::Shader creation results in crash.
Post by: Daid on July 15, 2015, 05:36:05 pm
Quote from: Mario on July 15, 2015, 11:30:27 am
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.

Quote from: eXpl0it3r on July 15, 2015, 10:31:43 am
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.
Title: Re: [Android] Issue or not? static sf::Shader creation results in crash.
Post by: Jesper Juhl on July 15, 2015, 08:06:29 pm
Quote from: Daid on July 15, 2015, 05:36:05 pm
Quote from: Mario on July 15, 2015, 11:30:27 am
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?
Title: Re: [Android] Issue or not? static sf::Shader creation results in crash.
Post by: Daid on July 15, 2015, 10:18:35 pm
Quote from: Jesper Juhl on July 15, 2015, 08:06:29 pm
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)
Title: Re: [Android] Issue or not? static sf::Shader creation results in crash.
Post by: Rosme on July 15, 2015, 10:38:16 pm
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.
Title: Re: [Android] Issue or not? static sf::Shader creation results in crash.
Post by: Laurent on July 15, 2015, 11:14:31 pm
Quote
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.

Quote
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.