Open mattdesl opened 9 years ago
I think in the long term only mangling function names when necessary is probably the best approach, but I suspect it's going to be a tricky change. In the short term I don't think it's too much for us to update the list of builtins when we run into something that isn't catered for though :)
Something that might help a little: it's specced out that all variables beginning with gl_
and GL_
are reserved for builtins, so we can catch all of those ones with a tweak to glsl-tokenizer
.
I ran into this the other day with use of standard derivative extension methods in an imported function body. A quick hacky fix that works for now is to pass a reference of the method name to the module.
i.e.
#pragma glslify: myFn = require(./my-std-deriv-fn, fwidth=fwidth)
Ideally, these methods would be either known to glslify or could be augmented by a user with some configuration file (.glslifyrc
?)
Currently if a builtin isn't hard-coded it could break shaders (for example,
fwidth
not being listed might get mangled tofwidth_2_1
). As WebGL2 and new extensions come to browsers, we should be wary of new functions/constants.Some things not listed in the built-ins:
GL_ES
and__VERSION__
-- not sure if that matters thoSome other things like gl_InstanceID, gl_ClipDistance, outerProduct, shadow2DProj, etc may or may not eventually end up in WebGL (in spec or through extensions).
Maybe there is another way of handling this? Like only mangling function names when necessary?