Creating a fixed functionality "shader"

Started by
1 comment, last by bronxbomber92 15 years, 10 months ago
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:
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
	}
}
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!
Advertisement
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.

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?
Thanks! Can you suggest any compiler compilers? Right now I'm considering ANTLR.

This topic is closed to new replies.

Advertisement