Limitations and future prospects
Today ...

The different topics under "About" and "Features" described the purpose and functionalities of SolidShaderTool as a shader development environment. Like in real life, there are always advantages and disadvantages for a certain issue.

Unfortunately, I have to admit that there are several limitations for SolidShaderTool which result in different restrictions. For example, rendering with DirectX 8.1 means that you are strictly limited to vertex shader version 1.0/1.1 and pixel shader 1.0-1.4, but brand new graphics hardware today supports shader versions 2.0 and higher.

I am confident that there will be time to improve SolidShaderTool's scope of benefits in order to keep the pace with technological advance and let the user participate in these changes.
In the next paragraph you find a list of proposals and thoughts about new functions and improvements for SolidShaderTool which might be realised soon ...

Future prospects ...

DirectX 9.0 & shader versions 2.0+

The first step for a successful redesign of SolidShaderTool will be to port the core render functions from DirectX 8.1 to DirectX 9.0. As a side effect, you are able to use the newer shader versions 2.0 with a higher instruction count and more calculation precision.

Effect file (.FX) support

Currently, there is no possibility to export your shader effect to a standardized file format in order to use it in your own engine or program. After porting SolidShaderTool's core functions to DirectX 9.0, it makes sense to implement an exporter to save customized shaders and settings into the DirectX effect file format (.FX).

Multi-Pass rendering

SolidShaderTool is currently providing just one rendering pass for each shader effect. Unfortunately, this eliminates certain effects like fur generation, advanced cartoon shading and post rendering effects. Enabling the function to render more than one pass will add a big amount of flexibility to the shader development with SolidShaderTool.

Projective textures / render targets

The implementation of render targets such as renderable textures would make effects like video projection in 3d environments or teleporter doors, which already show a projection of the place you will be transported to, possible. Of course, this function is only realisable in combination with multi-pass rendering.

Cube environmental mapping

Render API's like DirectX differentiate between normal and cube textures which are necessary for realistic reflections of the surrounding world onto 3d objects. This feature will be certainly added soon, just because it probably won't be too time-consuming to implement.

Dynamic stream mapping

The declaration of the input stream of mesh data into the vertex shader input registers is currently too restricted for vertex shader versions 1.0/1.1. The stream mapping has to adhere strictly to the size and order of the elements in the vertex buffer. As a consequence, the user is currently just allowed to change the vertex shader input register number for each input variable (position, normal, texture coordinates).
As an alternative, a dynamic vertex buffer system could be implemented which will rebuild and adjust itself each time the stream mapping is changed. Another way is to support DirectX 9.0 which already has an improved stream mapping model without the restrictions mentioned above.

Multiple light sources

Concepted as a one-pass rendering system, SolidShaderTool uses just one dynamic point light source. A second one would be possible, but it is not really necessary for understanding the concepts of dynamic lighting with the use of shaders. Notice that the rendering performance decreases significantly with every additional dynamic light source.

Support of HLSL and/or CG

Although SolidShaderTool's purpose is to help people understand the process of shader development, nobody should be forced to use the assembly language instructions forever. It is obvious that shader languages like HLSL (high level shader language) or CG ease and shorten the development process and are more "human-friendly" than the old-fashioned assembly instruction set.
So perhaps one day SolidShaderTool will support shader languages, too.