Compatibility
For most PC systems, backwards compatibility has always been a bit of a headache. In a perfect world, all game-players would have a useable version of the game, even if they're running on a P-60 with a standard 2D graphics card. Unfortunately, it's impossible to write games that can run on any hardware; a cut-off point must always be made. For the moment, over half of the buying public are running hardware which can accelerate the fixed-function pipeline in hardware, but a very small percentage have hardware which can accelerate vertex shaders. So, until next generation graphics cards make up ~10% of the market, the only people that really need to worry about vertex shaders are people who are working on OEM titles, and the really big companies who are keen to use all the latest graphical effects. Although, that said, vertex shader emulation does mean that particularly cool types of vertex processing can still be carried out in software on older hardware T&L cards.
Pixel shaders are also fairly rare in the marketplace at the moment, and, as there is no possibility of emulation on older hardware, the texture cascade system is going to be around for a good few years to come. You may remember that one of the biggest problems with the texture cascade system is that you have to program for lots of different type of hardware. Pixel shaders promised to vastly reduce the amount of compatibility code in game engines. Unfortunately, DX8.1 has shown us that things might not be moving in the perfect direction. For DX8, we had two types of pixel shader, PS1.0 and PS1.1. However DX8.1 introduces PS1.2, PS1.3 and PS1.4. If this carries on for DX9 and DX10, we could end up supporting about ten different versions of pixel shaders, and each one will probably correspond to a small number of hardware devices. It would seem more sensible to only increment the version numbers for each major release, and then, to only increase them by one.
Summary
Overall, it's going to be impossible not to use vertex shaders and pixel shaders within a few years' time. The hardware vendors and Microsoft all like the new paradigm, so closing your eyes to the shader implementations won't get you anywhere!
It's a shame that a lot of the work that used to be done by the driver has been moved into the domain of the games programmer, but we're just going to have to learn to make the most of it. The currently available vertex shader implementation makes it very difficult to get much out of shaders without writing complicated API wrappers such as the fragment-based system described above. With any luck, DX9 will introduce flow control into the vertex shader architecture. At that point, we should be able to carry out the lighting with a constant piece of code for each vertex shader. The lighting itself can be specified in the constant memory, but it looks like the code-size limit will remain, so it may still be necessary to have a simple form of fragment processing, in order to avoid reaching this limit.
There is no doubt that the shader architecture opens up new possibilities within the hardware. The software implementation of vertex shaders is good enough to emulate useful vertex shaders on older hardware, and if you're writing technical demonstrations, you'll love the freedom that the shader architecture gives you. For game engines, you'll need to look at what shaders will give you, versus the amount of work shader support will require.
Hopefully this article has introduced a few methods that you may be able to use to open up the shader architecture within your own projects, as well as shedding some light on the pitfalls associated with them. It's not a perfect architecture, but it does let us produce some great effects.
