This topic contains 3 replies, has 3 voices, and was last updated by 
scurty 1 year, 9 months ago.
-
Posts
-
Usually shaders have a version specifier at the top, but the ones in M2 don’t.
And you can’t specify one yourself because M2 inserts stuff at the start of the shader, and the version specifier has to be specified first in the shader.
So different drivers will use different versions of glsl, and things might not compile everywhere.
The “inverse” function for example doesn’t work in M2’s shaders on my drivers. (maybe not anyones drivers?)
Infact, I don’t even have “mod”… My friend does however!
So a shader version specifier really needs to be added.+1
If only the fragmentation of hardware drivers wasn’t such a big issue. But yeah this would be a great fix.I can add support for #version in future, but if you want shaders that will work everywhere you should just stick with the lowest common denominator glsl features of GL and GLES20, which is AFAICT gles2.0 shaders version 1.00:
https://www.khronos.org/files/opengles_shading_language.pdf
This is what’s used by webgl, gles2.0, and I am 99% sure will work with all desktop gl drivers.
No, it doesn’t have inverse(), transpose() or mod() etc, but that’s the point – not all targets/drivers support these. Stick to this though (and you shouldn’t need to use #version to do this) and your shaders should run everywhere.
In future, a lot of this can be made more flexible, eg: if you don’t want/need to support moble/wasm you should be able to use desktop gl (or alternately, use gles3.0 on mobile/wasm) which will give you better shader support, and you can really start going nuts with #version – but you’re also on your own when it comes to compatibility!
But for now anyway, I just want to get everything going as well as possible on as many targets as possible, and I think stick with gles2.0 shader v1.00 is the best way to achieve that.
I agree a wise person once said: “Get it working(hence lowest common denominator), THEN make it pretty. (The future)” – A person somewhere
Can Mark compile a small Roadmap for Monkey so we don’t forget? It would also prevent many people from commenting on the same requests and what not. These can also give the rest of the community a good sense of what to work on IMO.
Yay or nay?
You must be logged in to reply to this topic.