Hi all,
I just started to use (well, learn, as I don’t have any experience so far) shaders and I do have a few problems already, but for now the most simple question.
How, at runtime, can I check if a shader was compiled successfully?
Seems as if defineEffect always returns false, independent of success or failure.
Thanks,
Michael
I’m checking with Engineering on it.
Hello!
graphics.defineEffect() does not return a value, aka nil. When converted to boolean, it produces false. Also, it doesn’t compile anything. It only stores your shader text in internal “database” of available shaders. It would be combined and compiled into real shader right before it is used for the first time, which doesn’t necessarily happen in same thread as Lua is running, It happens “between the frames”.
As result - there is no ability to ret runtime status of compiled shader, because shader compilation is deferred.
From other hand - if you compiled shader once, it would always compile. GLES syntax is rather strict. It doesn’t necessarily would work efficient everywhere, but it would compile, so this is rarely the issue. By the way, if you’re trying to get started with shaders, I recommend our shader playground: https://shader.coronalabs.com, we also have subforum about shader effects.
Thanks for your reply.
You’re absolutely right with regards to the result of a function not returning any value - should’ve guessed/tested this by myself.
The shader playground is quite cool and it’s great to experiment and modify existing shaders.
With regards to the shader compilation - the idea behind the question was simply to be able to use a fallback if, on a device, a shader does not work due to some features not supported on that device.
F.i. right now I’m doing a text rendering system and so in this case I’d rather prefer a lower quality rendering than no rendering and from the 4 Android devices I use for testing at the moment on 3 I have issues with the fwidth/dFdx/dFdy functions (i.e. the GL_OES_standard_derivatives extension).
I did check the GL_EXTENSIONS and each one reports the extension as available.
The preprocessor #define GL_OES_standard_derivatives seems to also be defined but as soon as I add a #extension GL_OES_standard_derivatives : enable to the code and/or use any of the functions, the shader does not work anymore and instead my quads get a solid color fill.
My devices are mostly cheap and/or older ones but, besides this shader issue, they easily handle everything my code needs so they should be quite good for testing lowspec requirements.
Also … I had to repeat myself … live builds with extremely short turn around times on multiple devices at the same time are an amazing feature.
Sorry to disappoint… My point is that if shader compiles doesn’t mean that it would run correctly. Most of the time it would compile and not work properly in my experience.
I see. That’s sad - I just tried all kinds of variations to get a feeling for what happens, f.i. added intentionally syntax errors to see what the results are etc.
A quick test in Love2d, btw. just made the app kind of freeze when I enable the extension/use the functions on the problematic devices.
So somehow Corona does a better job here and given the quads from my mesh get’s just a solid fill with the currently set color i just guessed Corona somehow catches an error and sets the default shader?
Anyway - I spend far to long at this already and, even it’s slightly more inconvenient, I can manually work around the issue, so no showstopper to me.
In general, is there any website/article or whatever about which shader features usually work and which don’t on the typical target platforms? Maybe I was just very unlucky, but if I bump into a (local) 75% incompatibility with just my tiny experiment I wonder how developers handle more ambitious projects. Especially if there’s no way to handle the error and fallback to another codepath.
I’m checking with Engineering on it.
Hello!
graphics.defineEffect() does not return a value, aka nil. When converted to boolean, it produces false. Also, it doesn’t compile anything. It only stores your shader text in internal “database” of available shaders. It would be combined and compiled into real shader right before it is used for the first time, which doesn’t necessarily happen in same thread as Lua is running, It happens “between the frames”.
As result - there is no ability to ret runtime status of compiled shader, because shader compilation is deferred.
From other hand - if you compiled shader once, it would always compile. GLES syntax is rather strict. It doesn’t necessarily would work efficient everywhere, but it would compile, so this is rarely the issue. By the way, if you’re trying to get started with shaders, I recommend our shader playground: https://shader.coronalabs.com, we also have subforum about shader effects.
Thanks for your reply.
You’re absolutely right with regards to the result of a function not returning any value - should’ve guessed/tested this by myself.
The shader playground is quite cool and it’s great to experiment and modify existing shaders.
With regards to the shader compilation - the idea behind the question was simply to be able to use a fallback if, on a device, a shader does not work due to some features not supported on that device.
F.i. right now I’m doing a text rendering system and so in this case I’d rather prefer a lower quality rendering than no rendering and from the 4 Android devices I use for testing at the moment on 3 I have issues with the fwidth/dFdx/dFdy functions (i.e. the GL_OES_standard_derivatives extension).
I did check the GL_EXTENSIONS and each one reports the extension as available.
The preprocessor #define GL_OES_standard_derivatives seems to also be defined but as soon as I add a #extension GL_OES_standard_derivatives : enable to the code and/or use any of the functions, the shader does not work anymore and instead my quads get a solid color fill.
My devices are mostly cheap and/or older ones but, besides this shader issue, they easily handle everything my code needs so they should be quite good for testing lowspec requirements.
Also … I had to repeat myself … live builds with extremely short turn around times on multiple devices at the same time are an amazing feature.
Sorry to disappoint… My point is that if shader compiles doesn’t mean that it would run correctly. Most of the time it would compile and not work properly in my experience.
I see. That’s sad - I just tried all kinds of variations to get a feeling for what happens, f.i. added intentionally syntax errors to see what the results are etc.
A quick test in Love2d, btw. just made the app kind of freeze when I enable the extension/use the functions on the problematic devices.
So somehow Corona does a better job here and given the quads from my mesh get’s just a solid fill with the currently set color i just guessed Corona somehow catches an error and sets the default shader?
Anyway - I spend far to long at this already and, even it’s slightly more inconvenient, I can manually work around the issue, so no showstopper to me.
In general, is there any website/article or whatever about which shader features usually work and which don’t on the typical target platforms? Maybe I was just very unlucky, but if I bump into a (local) 75% incompatibility with just my tiny experiment I wonder how developers handle more ambitious projects. Especially if there’s no way to handle the error and fallback to another codepath.