-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#define
nested in function body produces parse error
#117
Comments
Yeah… not supported so far. 😢 I need to find a better way to represent and parse CPP directives. Right now, they work because I represent them as part of the AST, but they should be implemented cross AST. I’m still looking for ideas and ways to do that efficiently. |
|
@mitchmindtree may I ask where those examples can be found? I’d love to integrate them to |
Thanks for the update! And no worries, I have no qualms with moving the defines to the global space 👍 You can find those shaders at the Vidvox repo here. |
I’m working on the preprocessor issue. :) |
Is there any news on this? |
Closes hadronized#64. Closes hadronized#117.
Closes hadronized#64. Closes hadronized#117.
Closes hadronized#64. Closes hadronized#117.
Closes hadronized#64. Closes hadronized#117.
Closes hadronized#64. Closes hadronized#117.
I just attempted to parse a large collection of test shaders, and they all worked beautifully, except one!
Here's the culprit in its entirey:
The panic provides the following error:
This refers to the
#define
in thetransition
function towards the bottom.I'm unsure - are nested
#define
s like this even officially supported as a part of GLSL? I haven't seem them before. That said, this shader is one of the standard shaders provided with VDMX (quite a popular VJ application), so I guess there's at least one GLSL parser out there that does support it.The text was updated successfully, but these errors were encountered: