Thursday, January 8, 2009

Bringing off the HLSL

I've decided to defer any further HLSL experiments until such time as I have been able to give the whole thing more consideration. Primary reasons are:

  • Decisions on using individual VertexShader and PixelShader files versus using an all-in-one Effect File need to be made. I'll discuss this further below.
  • Concerns over lack of Pixel Shader support on older cards; one of my goals is to have a viable engine that will run on (almost) anything. Vertex Shaders will be very happily emulated in software by Direct3D 9, with performance at least equivalent to fixed functionality. Not so with Pixel Shaders.
  • Lack of a really good IDE for developing HLSL shaders. There's really only RenderMonkey and FXComposer - I've already decided that FXComposer brings too much of it's own weirdness and assumptions to the party, which leaves RenderMonkey. To be honest, the best I can say about it is that it's "functional".
  • Concerns over distribution of shaders. I like to package content as embedded resources, as doing so means that users only need the EXE to get everything, and my content doesn't clash with anyone else's. However, I also like to be able to give people the ability to replace my content with their own if they wish. That bit's easy, it's management of the .rc file, the resource.h, and all the other messing that goes with it that's unpleasant.
Concerning the format, Effect files are probably considered the standard accepted way, but they do have their own difficulties, in that you have to start dealing with Techniques and Passes, with BeginPass and EndPass in particular needing to be called per model. They seem to have some performance loss in comparison to standalone Shader files too. However, standalone Shader files will double the management-of-resources headache. I've written both code paths and I feel that from my own perspective standalone Shaders are probably the way to go. There's just something about Effect files that seems "wrong" to me.

Anyway, HLSL won't be making an appearance any time soon, but this brings me back to the original difficulty of handling that damned water warp update. If I can get the miplevel 1 problem resolved I'd be happy to go with a double-sized texture, a 4 x storage overhead per miplevel seems more acceptable than a 16 x overhead.

0 comments: