Jump to content
  • entries
    21
  • comments
    28
  • views
    34333

Acclimate shading language

Sign in to follow this  
Juliean

1820 views

Last entry:
https://www.gamedev.net/blog/1930/entry-2260721-a-custom-variant-class/

Now for something completely different. Since I'm currently working on the graphics module, I thought I'll talk about one of the coolest features of the engine in that regard: The custom shading language.

Why a custom language?

I started the renderer as DX9, and later added DX11-support. And at some point, I also added GL4-support for a schools project. Now the render backend and interface is build so that you can write grahpic algorithms indifferent of the actually used API. The only problem was, I still had to have each shader in 3 different variations. I already noticed that all those different shaders actually just differed in syntax, but most actualy code was nearly identically. So thus my idea was to write a kind of meta-language, of which I can generate shaders for all different APIs, while just writing the shader once.

The syntax:

So syntactically, what I came up with is a concept of blocks & lines, that make up the base file format. Take a look at a vertex-shader// the definition of the vertex shadervertexShader{ // defines the vertex-attributes, handed over by the input assembler in { float4 vPos; } // defines the output of this shader out { float4 vPos; } // defines a block of shader constants, "Instance" is an engine-specific macro for a certain cbuffer ID input Instance { matrix mWVP; } // the main execution point of the vertex shader main { out.vPos = mul(in.vPos, mWVP); }}
So as you can see, the definition of the shader is really slim. Compare it to the equivalent shader in DX11:struct VS_INPUT{ float4 vPos : SV_POSITION;};struct VS_OUTPUT{ float4 vPos : SV_POSITION;};cbuffer Instance : register(b0){ matrix mWVP;}VS_OUTPUT mainVS(VS_INPUT in){ VS_OUTPUT out = {0}; out.vPos = mul(in, mWVP); return out;}
There is lots of more syntactical "garage" you have to take care of in plain HLSL5. My language automatically takes care of that, allowing for faster creation of shaders. I think most of what is in the vertex-shader I posted should be pretty self-explanatory, alongside the additional comments. Lets look at a pixel-shader next. The concept is pretty much the same:pixelShader{ // pixel shader only has an "out"-block, as input is implicitely generated from the vertex shaders "out" out { float4 vColor; } // this block is new - used textures are declared here textures { 2D Texture; } main { out.vColor = Sample(Texture, float2(0.5f, 0.5f)); }}
Again, pretty lightweight. Maybe I'm biased towards my own work, but I'd consider writing shaders in such a manner way easier and faster than "plain" HLSL/GLSL-shader. Of course you first have to know the syntax.

Writing actual shader code:

So writing actual shader code (what is in the "main" methods), its most of the time pretty straightforward. I've based the language syntax on HLSL5, and all the parser really has to do is replace some function names that are unique to the language (eg. Sample()), as well as replace all used types (float, matrix) for GLSL-targets. So if you are familiar with writing HLSL-code, then coding in the acclimate shading language should be extremely straight-forward.

Moar blocks pls:

In order to support most basic shader features, there are a few blocks that are shared between the different types of shader, while other blocks are shader-specific. Some of the shadered once you've already seen, but there is a few more:

- out: The output of the current shader stage, acts eigther as input for the next stage or writes to the framebuffer (in case of a pixel-shader)
- textures: The main declaration point for textures of all kinds. Eventually needs to be reworked a bit, once I want to support regular buffers, since they shader texture registers, at least in DX11.
- input: The equivalent of DX11-cbuffers, and GL4-uniform-buffers. The actual buffer qualifiers (Instance, Stage, ...) are given by the using framework, since its easier to remember a name than a number, and also easier to change. Thats one thing really hard to emulate right in DX9, everything else is really quite easily translated to the different shading-languages.

- functions: That block is new. Since you can't freely write code all over the place, for being able to declare functions, this block is needed.functions{ float calculateSomething(float4 vPos) { return 0.5f; } float calculateSomethingElse(float2 vTexcoords) { return vTexcoords.x / vTexcoords.y; }}
Wrapping it up:

So thats are the basics of the language. I consider it even pretty good objectively, and really don't want to write shader in plain HLSL/GLSL anymore. Thats not even all though - there are a few more features, which I'm going to talk about next time. For example, there are geometry-shaders, but also direct support for permutations, and a plugin-system for shaders. Thanks for reading, and see you next time!

PS: As a practical example, I've attached an SSAO shader written in this language. Enjoy!
Sign in to follow this  


2 Comments


Recommended Comments

Looks interesting. You have identified a good place for an intermediate language as far as I can see and this would make cross platform development a lot easier.

Its great fun writing languages and I've been guilty in the past of doing it when I didn't really need to smile.png Seems here it solves a very real problem.

Share this comment


Link to comment

Thanks Aardvajk, it really also appears to me that this is a case where I've come up with something uniquely useful. I belive the thing that comes closest to this is the CG-language, but from what I've gathered its syntax is also just a variation on HLSL, and their GLSL-support is not very good.

 

Yeah, I've also got a very strong addiction for writing things that already exist. This is actually the first language I've ever designed, aside from a basic XML-parser I'm using. I find it quite interesting to be honest - though I'm pretty sure my parsing process sucks hard time, up until lately I've just been parsing the shader files by going through a stringstream progressively. I just changed it to parse the blocks/lines into seperate objects the other day, which made the progess quite easier. I'll see where it goes, maybe I'll even release this into the public some day, would just have to break up some engine-dependencies and probably clean up a things here and there.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!