[Solved] Problem with precision qualifiers in a shader for android

[Bigfoot71]

I had a problem rendering with a shader for android due to the precision of the float numbers, so I wanted to add these precompilation instructions so that the floats are automatically `highp` if possible.

Code: Select all

#ifdef GL_ES 
#ifdef GL_FRAGMENT_PRECISION_HIGH
precision highp float;
#else
precision mediump float;
#endif
#endif

But I get this error:

Code: Select all

ERROR: highp : overloaded functions must have the same parameter precision qualifiers for argument 1
ERROR: highp : overloaded functions must have the same parameter precision qualifiers for argument 3
ERROR: highp : overloaded functions must have the same parameter precision qualifiers for argument 4

Which matches this line:

Code: Select all

vec4 effect(vec4 color, Image texture, vec2 texture_coords, vec2 screen_coords)

My question is why? Because on the other examples I've seen on the forum it seems to work for everyone.
The version of OpenGL ES on the device that produces this error is 3.2 if that helps.

[Bigfoot71]

Does anyone have any idea about this problem? The only solution I could find is to specify `highp` on a case-by-case basis but this can be problematic on some devices, does anyone use the technique I showed or another?

[slime]

My question is why? Because on the other examples I've seen on the forum it seems to work for everyone.

I don't know about other examples on the forum but that won't work because love declares the effect function before your default precision line, so the declaration would use mediump and the definition would use highp which isn't allowed.

specify `highp` on a case-by-case basis but this can be problematic on some devices

If you're talking about very old devices which don't support highp in pixel shaders at all, you could use the preprocessor to use highp for those variables when it's available and use mediump otherwise.

love does that itself for some of its internal variables, and it has a LOVE_HIGHP_OR_MEDIUMP define to make it a bit simpler to use.

e.g.:

Code: Select all

LOVE_HIGHP_OR_MEDIUMP vec4 foo;

Or you could just not support those old devices for your game.

[Bigfoot71]

If you're talking about very old devices which don't support highp in pixel shaders at all, you could use the preprocessor to use highp for those variables when it's available and use mediump otherwise.

love does that itself for some of its internal variables, and it has a LOVE_HIGHP_OR_MEDIUMP define to make it a bit simpler to use.

e.g.:

Code: Select all

LOVE_HIGHP_OR_MEDIUMP vec4 foo;

Or you could just not support those old devices for your game.

Thank you very much for this solution it is what I needed!

And yes I very well could have but I'm doing this for a game using g3d and I've taken the trouble to optimize it so it can run on an old tablet as well as newer hardware, last issue was on a "stupid" shader so I would have liked to do things completely

Besides, I did not find this information in the documentation of Löve, should it have been there? (here or here) (or maybe i searched wrong)

I don't know about other examples on the forum but that won't work because love declares the effect function before your default precision line, so the declaration would use mediump and the definition would use highp which isn't allowed.

For the other examples I had been able to find on the forum using the example I showed here are two:

viewtopic.php?f=4&t=82087&p=197592
viewtopic.php?f=4&t=83890&p=212185

Thanks again

[slime]

I did not find this information in the documentation of Löve, should it have been there?

It's more of an internal thing, I'm not sure if it should be officially supported like that. It's pretty simple to implement yourself in any case:

Code: Select all

#if defined(VERTEX) || __VERSION__ > 100 || defined(GL_FRAGMENT_PRECISION_HIGH)
	#define MY_HIGHP_OR_MEDIUMP highp
#else
	#define MY_HIGHP_OR_MEDIUMP mediump
#endif

For the other examples I had been able to find on the forum using the example I showed here are two:

Ah, those were using love 0.10 where it might have incidentally worked because some of love's internals were different - but it was never an officially supported thing.

[Bigfoot71]

Okay, I had roughly thought the same thing in view of the seniority of these posts. Thanks again for these clarifications.