Shader "Example"
{
Properties
{
LightPosition Vector3 = (0.0 10.0 0.0)
Distortion Float = 0.1
MainTexture Texture2D = "Name of Texture"
}
Pass
{
Lighting On
Color (1.0 0.0 0.0 1.0) // red
Blend ONE ONE_MINUS_SRC_ALPHA
SeparateSpecular On
Material
{
Ambient (0.0 1.0 0.0 1.0)
Diffuse (1.0 1.0 0.0 1.0)
// ect...
}
SetTexture MainTexture
{
// texture refers to the most recently set texture
// primary refers to the color calculated by lighting or the vertex color
MODULATE texture primary
}
}
// Another pass demonstrating embedding GLSL
Pass
{
GLSLPROGRAM
void main()
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
FRAGMENT
void main()
{
gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
}
ENDGLSL
}
}
Creating a fixed functionality "shader"
I've designed a language in which I'm able to specify basic fixed functionality parameters (that is analogous to OpenGL states for the most part) and embed GLSL programs into.
A basic example that doesn't do anything, but illustrates the syntax of language would be:
If anyone is familiar with Unity's ShaderLab, this is very similar.
Anyways, on to the actual question. The language is very data and state oriented. It can literally be directly translated into some booleans, enum variables, ect... I don't know what the best way is to parse this. I could just read through it line by line and try to parse it myself - this would probably result in an unreliable parser though. What tools could I use to do this (in C#)? I was thinking about using these two tools:
http://plas.fit.qut.edu.au/gplex/
http://plas.fit.qut.edu.au/gppg/
Admittedly, I don't know much about using lex/yacc, but from what I've read it seems that you can't really use them at run-time. They create separate tools that parse the source, which I don't want.
Thanks!
Compiler compilers generate code (a FSM) that parses the input according to some grammar definition.
Whether you're familiar with them or not, to design a language you cannot avoid using some formal grammar to describe it. Reliability of parsing is not a coding problem (bugs get fixed), but that of unambiguous grammar. Tools that exist for that validate several such conditions.
- Define grammar
- Process it through compiler compiler
- Attach actual code to actions
Formal grammars are fairly small and by all means well researched area. They are used for parsing of such files during run-time. The compiler itself is statically generated, but the input is then provided as a string.
Although, is there really need for one more shader language?
Whether you're familiar with them or not, to design a language you cannot avoid using some formal grammar to describe it. Reliability of parsing is not a coding problem (bugs get fixed), but that of unambiguous grammar. Tools that exist for that validate several such conditions.
Quote:but from what I've read it seems that you can't really use them at run-time.
- Define grammar
- Process it through compiler compiler
- Attach actual code to actions
Formal grammars are fairly small and by all means well researched area. They are used for parsing of such files during run-time. The compiler itself is statically generated, but the input is then provided as a string.
Although, is there really need for one more shader language?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement