Gettin' kinda shady
I've been muddlin' around about including support for compiled HLSL shaders and different drawing pipelines in my game. Originally I had what I thought was a pretty cool method of supporting different shaders without having to worry about which shaders required what parameters, etc. I'd have a standard set of parameters that my game could supply (transformation matrices, lighting details, textures, etc) and after I'd accumulated all the draw calls for a shader, it would query the shader for what parameters it requires and set as necessary.
This sounded like it would be quite flexible and cool. Then I realised that it would violate my new matra for game dev: "Keep it simple, stupid". While I would allow the game concept to be moderately complicated and the features it implements could have some complexity, I wanted there to be as few "uber-flexible-and-shiny" subsystems as possible. The temptation for me is usually to make a subsystem as general as possible so that I can "use it again next time". The problem is, this usually ends with me spending weeks or months on just implementing this one subsystem and the project as a whole suffers.
So the compromise ended up being that I'll still have a big blob of graphical state data that my shaders can grab their parameters from, but instead of one monstrous generalized "shader handler" class, I'll just have individual classes for each shader I'll use. These classes subclass from a shader superclass that defines some common functionality, but they each define their own drawing function so they can grab whatever parameters they need, set whatever states, etc.
I'm pretty happy with that so far. It's not terribly scale-able though. If I had tonnes of artists using many shaders, this might be a problem. However, since I'm a one-man-team and I won't be doing anything too revolutionary in the shader department, I hope it'll work okay.