AgateLib

kanato:
Sounds like you've done your homework. I will look into that ATI project and see what the effort involved for porting to C# would be. Or (worst case), how much effort there is in getting it to compile as a managed C++ binary.

Initially I was going to target both, but it turns out it's very difficult to build an abstraction on top of GLSL and HLSL because they have had very different design philosophies from the get-go. Based on my research, the design philosophy which went into HLSL is a lot smarter. Additionally, HLSL has never had access to any fixed function state, and OpenGL finally deprecated the fixed function with OpenGL 3.0 and GLSL 1.3. That's good for AgateLib, because exposing any of the fixed function pipeline would be a huge coding effort. For GLSL, I'd really like to target OpenGL 3.0 / GLSL 1.3, but OpenGL 3.0 support is pathetic outside of nVidia and ATI. In particular, I'd like to see support on Intel hardware and Apple machines but it's still not there. 1 year old Intel hardware doesn't have proper support for framebuffers. Cg might be a viable alternative, but I am not excited about including a dependency on the Cg libraries.

I've thought about both the other options you mentioned, developing ASL or helper classes. The most severe disadvantage of both is that AgateLib consumers wouldn't be able to take advantage of the large amount of existing literature / examples on both HLSL and GLSL. The second is that either approach will wind up being a tremendous development effort on my part, and probably still won't be as flexible as either HLSL or GLSL.

A better alternative would be to just make AgateLib use HLSL, and implement a converter from HLSL to GLSL. Actually, ATI developed an open source converter which is BSD licensed, so it could be ported to C# and included in AgateLib.

My current plan is to get support for HLSL going and then figure out how to shoehorn GLSL to fit into the same structures.

The idea with helper classes is good.
But similar to codedom,.. I dont know, CodeDom is not complicated to use but requires some coding.

Kanato seems to target GLSL and HLSL.
You can take a look at the source here: http://agate.svn.sourceforge.net/viewvc/agate/branches/agate3d-3.2/
As you can see its still in a branch means it is not finished.

It sounds like the new vertex/pixels functionality is very DirectX specific. How will this affect the driver functionality? Will OpenGL still be fully supported?

I guess the idea I was trying to convey focuses less on introducing a new shader language syntax more than abstracting it's implementation above GLSL, CG, and HLSL.

GLSL is *mostly* cross platform. However, some platforms very specific to Microsoft's domain such as Silverlight and XNA (at least for X-Box deployment), the only option you have there is HLSL (though I've heard that CG and HLSL are nearly interchangeable). And as I mentioned above, Silverlight is limited further to Shader 2.0 functionality. And finally, should HLSL/CG/GLSL diverge at any point in terms of functionality, other cross-platforming challenges arise.

A good compromise would be to take what you've suggested a step further: Eliminate the shading language syntax altogether and create helper classes that would build the desired output shader syntax (similar to how the code dom works in .Net to emit C# or VB or IronPython, etc. from the object graph representation of the source).

The factory in Agate that decides what rendering driver to use could inject the proper shader syntax converter for the helper/builder classes.

I do agree that common effects classes could be made. The helper classes could be used to create those in a truly cross-platform way.

I dont think a extra shader language is a good idea.
If you want cross platform shading you could use GLSL or CG.
Maybe some effect classes for eg. explosions, smoke, fire that people without shader knowledge could use.

I know this post comes late as I'm new here, but here is my unsolicited opinion. :)

Since Silverlight is a Web 2.0 technology, and web surfing is one of the primary uses of most PC's (and would be the only use if Google had it's way), it might be safe to say that the machine capabilities Microsoft is targeting here could be a good litmus as to where at least the minimum should/could be. Perhaps even the maximum.

Silverlight 3 allows up to Pixel Shader 2.0 specifications.

In terms of what specification I would utilize, I personally would find the shader versions where one could most comfortably target both HLSL/GLSL with the most intersecting features (Maybe call this subset the ASL - Agate Shading Language). This would ensure custom shaders to work across all of the platforms and make the driver model a bit more manageable to implement and maintain across the open source and Microsoft binded platform providers you have in place. This would allow you to scale it up over time to handle future shader models while hiding the details from the client code (which would probably go a long way to ensure backward compatability)

Just my two cents anyway.

Ok, that's good to know. The first iteration of this will implemented with Direct3D 9 only, so it will only be shader model 2.0 and 3.0. OpenGL and Direct3D 10/11 will come after that.

I plan to support cards which are newer than GeFore 6000 and not older than 4-5 years.
Means they should have mostly 3.0.

If you create a software which uses shaders it mostly uses a lot of other things and needs a good modern graphic card.
Also 'you' should plan for the future if you now start to create a game and you would finish it in one or two years 2.0 would be old/outdated and 6.0 would be the standard of modern graphic cards.

So I would prefer 2.0 or even consider 3.0 but it is also a question for what you need it and what 3.0 has and 2.0 not.