improve ShaderToy mode detection about shader-toy HOT 9 CLOSED

1. Yes I agree.
2. Wouldn't it be easier and also necessary to replace the version directive? For WebGL2 you probably need 300 es right? While the linter needs 310 es at least to generate SPIR-V from ES at all and 320 es or 440 for all the features like input blocks.

Yeah I see, here and there

Also this is awesome. Now I can use #ifndef SHADER_TOY instead.

Also looks like iGlobalFrame is missing. By the way I guess you could simplify your code a bit by using some defines in shaderPreamble like

#define iGlobalTime iTime
#define iGlobalFrame iFrame

from shader-toy.

I added a couple lines to ignore the version directive, it's shown by green squiggles that they are ignored.
For now I avoided inserting version directives because it caused some issues to do naïvely.
Also documented the case of void main(void)
Lastly add iGlobalFrame by your suggestion.

from shader-toy.

Thanks for bringing up these issues 👍

Considering your first point. Imho it is far beyond the scope of this extension to implement a real preprocessor rather than the stupid string finding thing we have. The code inserted before compilation, not just by us, might contain more preprocessor directives that we can't really know about. Just speculating here though, I'd need to read more about this stuff. If we know more about this we can rethink if it's worth it to make a better preprocessor, but I doubt so.
So I would vote for documenting how the automatic generation of void main() works and make clear that using void main(void) is an actual backdoor to defining a main that doesn't prevent generation of it. What do you think?

Considering the #version directive, it should be quite simple to look for it on line 1 and reserve its space in the transformed shader and move it back to line 1. I can look into that later this week.

Keep the suggestions coming if you have more problems 😃

from shader-toy.

1. Yes I agree.

Then I'll fix that for the next version

2. Wouldn't it be easier and also necessary to replace the version directive? For WebGL2 you probably need 300 es right? While the linter needs 310 es at least to generate SPIR-V from ES at all and 320 es or 440 for all the features like input blocks.

Quite honestly I wasn't quite sure what versions are supported (or necessary) for WebGl and WebGL2, I wanted to take a look at the specifications when I have more time on the weekend. If a user provided #version is ignored/replaced, it sounds like something the user should be told. So maybe if this is how it will work a message should be displayed (that can be disabled in settings). I'll look more at it on the weekend. Or if you have a clear idea of it already and the time to spare you can draft a PR.

Yeah I see, here and there

Good catch 😃
I wasn't consciously aware that includes were compiled with an explicit #version, but from what you say it would make sense to do this. However since the extension should also support WebGL and not just WebGL2, it might be necessary to pick that depending on what's available?

Also looks like iGlobalFrame is missing. By the way I guess you could simplify your code a bit by using some defines in shaderPreamble like

#define iGlobalTime iTime
#define iGlobalFrame iFrame

Wasn't aware of iGlobalFrame, that should be easy to add. Using the preprocessor for these is also a good idea 👍

from shader-toy.

Quite honestly I wasn't quite sure what versions are supported (or necessary) for WebGl and WebGL2, I wanted to take a look at the specifications when I have more time on the weekend.

Unfortunately only up to 300 es. Let's hope for WebGPU.

If a user provided #version is ignored/replaced, it sounds like something the user should be told.

Maybe some squiggles in the editor.

I wasn't consciously aware that includes were compiled with an explicit #version, but from what you say it would make sense to do this. However since the extension should also support WebGL and not just WebGL2, it might be necessary to pick that depending on what's available?

It would have to be a quite old VSCode version to not support WebGL2.

from shader-toy.

Unfortunately only up to 300 es.

If that's both WebGL and WebGL2 then it's simple to do though.

Maybe some squiggles in the editor.

Good idea again, I'll take a look.

It would have to be a quite old VSCode version to not support WebGL2.

Risking to sound like an idiot here, but can't that be dependent on drivers rather than just VSCode? There's no question for VSCode supporting it because we require a version new enough for using WebView already.

from shader-toy.

If that's both WebGL and WebGL2 then it's simple to do though.

WebGL is 100 only.

Risking to sound like an idiot here, but can't that be dependent on drivers rather than just VSCode? There's no question for VSCode supporting it because we require a version new enough for using WebView already.

I'm not sure, Chromium uses ANGLE to translate it to DirectX iirc so it should be well supported.

from shader-toy.

Chromium uses ANGLE to translate it to DirectX iirc so it should be well supported.

And what happens on Linux and OSx?

from shader-toy.

Yeah it just occurred to me it's cross-platform after all 😅
Don't know.

from shader-toy.