Writing shaders for all platforms

[gajop]

We've been writing Ludum Dare games with Spring that tend to rely heavily on shaders which tends to be a cheap way to achieve great effects, hide bad models/textures and even provide visual feedback.
The greatest issue with them is that there's no obvious way to test if they would work for all systems. What's worse is that while some of the normally functioning shaders might fail, others will work, and that leaves a really mixed experience (it's not totally broken so the players might not realize that there even are issues, and instead think the game just has poor graphics by design).

Are there any solutions? Is it possible to make the engine compile shaders more strictly, so we get some sort of guarantees of their correctness?

I think jk sent this link once (http://developer.amd.com/tools-and-sdks ... /#download), although I hadn't actually try it out yet. Is this the answer?
Can we perhaps get the full log (warnings too) from the shader? As far as I know, all we receive right now are errors, and that's usually not useful (I could be wrong).

Am I missing something else? Does stuff like "#version 330 compatibility" in the shader help at all?

Insights appreciated!

[Silentwings]

which tends to be a cheap way to achieve great effects, hide bad models/textures and even provide visual feedback ... Is it possible to make the engine compile shaders more strictly, so we get some sort of guarantees of their correctness

Re-using such shaders is cheap, but writing them is not. For the moment I think making stricter requirements on what Spring will compile as a shader carries a risk of making shaders less likely to be written.

Iirc setting DebugGL=true in springsettings will expose a much larger range of warnings/errors.

[gajop]

Re-using such shaders is cheap, but writing them is not. For the moment I think making stricter requirements on what Spring will compile as a shader carries a risk of making shaders less likely to be written.

The idea isn't to add an extra barrier to shader development but to make sure users can write shaders that will work on all platforms (supported by Spring), or in the worst case know about potential issues they may run into (print warnings upon compiling).
I've researched a bit and there were some claims that Nvidia driver isn't standards compliant and accepts all sort of badly written (technically incorrect) code.

I have examples where my GFX card would happy accept things that are clearly wrong such as:

• editing what should be a const (https://github.com/spring1944/Scenario- ... 4/issues/8),
• type errors (https://github.com/SpringCabal/Flove/issues/16: ERROR: 0:23: '*' does not operate on 'int' and 'float'),
• and issues when no vertex shader is specified (http://hastebin.com/onidiwubul.xml ERROR: 0:16: error(#164) l-value required: assign "gl_Vertex" (can't modify an input)).

Iirc setting DebugGL=true in springsettings will expose a much larger range of warnings/errors.

Thanks, I tried that and also DebugGL=1 (which I thought was intended?), but neither exposed any shader warnings/errors.

[Peet]

Am I missing something else? Does stuff like "#version 330 compatibility" in the shader help at all?

Yes be explicit as possible about the gl featureset being used, including the version and any additional extensions. Depending on the platform/compiler this can make all the difference.

You're right about the Nvidia compiler being ridiculously forgiving, I've noticed that on the mobile Tegra platform as well. I don't know what the state of affairs with the AMD drivers are nowadays but I've heard of it verging in the opposite direction with supposedly correct code breaking much more often than it should....and the situation with both vendors is complicated by the growing traction of their respective FOSS driver implementations for which presumably we want good support also.

The approach of an engine-specific shading language which is mapped to vendor-specific subsets of Cg/GLSL seems to be pretty popular these days, though obviously this project doesn't have the labour available to pull something like that off.

I'd definitely recommend using the aforementioned vendor tool (and nvidia has an equivalent) to craft a feature-rich and proven cross-platform base shader library for games to use selectively. Automated testing on multiple platforms would be a serious boon to this process. I suspect this is the only real option in a development community rife with cargo-cult and copy-paste programming such as this one.

The idea isn't to add an extra barrier to shader development but to make sure users can write shaders that will work on all platforms (supported by Spring),

These certainly could be interpreted as the same thing - disallowing the game developer from writing unportable shaders. Not a bad thing if you don't want to accidentally alienate a big chunk of your userbase.

[PicassoCT]

So- this is sort of a ridiculous race to the bottom?
He who takes arglgarbl-syntax and compiles it to a valid - maybe usefull shader, binds the clueless makers to his cards?
Then, why is there even a discussion?

+1 for gajops proposal. Also not optional. Make it binding.
Fuck this sort of companycompatability

[gajop]

@Peet Thanks for the post, it reaffirms some of my suspicions.

These certainly could be interpreted as the same thing - disallowing the game developer from writing unportable shaders. Not a bad thing if you don't want to accidentally alienate a big chunk of your userbase.

My first step is not in that direction though.
Instead of making "unsupported" shaders fail to compile, I think it's far more important to reveal potential cases where it might refuse to compile on other platforms.
I've made a small commit to the engine that will allow access to the shader compilation infolog even when the shader compiles just fine.
This already reveals some useful info (provided that the shader error log is printed in Lua even if it doesn't fail to compile).

This should be the first step in helping us detect *potential* problems and thus reduce cross-platform development time significantly.

[Silentwings]

Afaics there is nothing to tell the user that those messages actually relate to shaders. Nor anything to say (in the case of a widget containing multiple shaders) which shader(s) they relate too.

There is already the config tag DebugGL=1 to specify when you want such info printed - of course it would be better to not ignore it.

[gajop]

Afaics there is nothing to tell the user that those messages actually relate to shaders. Nor anything to say (in the case of a widget containing multiple shaders) which shader(s) they relate too.

There is already the config tag DebugGL=1 to specify when you want such info printed - of course it would be better to not ignore it.

These messages aren't printed by the engine. There's already a function to obtain the infolog from shader compilation (see gl.GetShaderLog at https://springrts.com/wiki/Lua_GLSL_Api). The original implementation would always have the log be empty if the shader compiled successfully, which was hiding a lot of potential issues from the user. My change just made the log available always, even when it succeeds to compile.

This of course means that you can easily tell what widget/shader it occurred as you'd be printing this information immediately after the gl.CreateShader, e.g.

Code: Select all

local shader = gl.CreateShader(...)
local shaderLog = gl.GetShaderLog()
Spring.Echo("MyShader's infolog:")
Spring.Echo(shaderLog)

Engine could be made to automatically print it, but I didn't want to change the original implementation's design too much.

[Silentwings]

Oh, didn't realize your infolog in commit msg was augmented by a widget, thanks.

[gajop]

These minor changes might be of interest to other game developers:
https://github.com/SpringCabal/LD35/com ... ebfc062740
https://github.com/SpringCabal/LD35/com ... 648ea0ae6d