Just to give a heads up. I did find a way to make great use of the GLSL stuff and think I should maybe wait with releasing it until that's done so I don't push 2-3 versions within a couple days, the delay will only be about 1-2 days in itself.

The system I have now decided on is the following in case you're interested:
When the game starts parsing shaders, I will scan them for a "program <name>" keyword, which equals a pair of glsl/<name>_vp.glsl and glsl/<name>_fp.glsl.

Subsequently this pair is then loaded and compiled and linked to the affiliated shader_t struct.

For the stageIterator (or in other words the rendering path) I have implemented a new one called StageIteratorGLSL which sets everything up optimized for GLSL rendering and will take care of uniform data, every shader with a "program" specified will use this path.

This stuff is working fine already and in itself would probably be good to go for some first work.

Of course hardcoded shaders work too, but you've seen those already anyway.

Now the way I'll extend it though is the following:
When the glsl program is loaded, I'll scan it for all the uniform data it needs going in and upload those. As of right now it wouldn't be possible to do multitexturing inside the shaders since with such a dynamic system the engine wouldn't know what is needed and what not (yet). This also means you'll have to stick to some additional keywords within your shaders but I don't really think there's a way around it. So if something like "uniform vec3 u_lightOrigin" is in your shader I will upload the current lightOrigin to it and so on.

That's definitely going in for version 1, since otherwise the system wouldn't be fully usable.

Additionally when support for programs is found on the hardware, I'll replace the existing stage iterators with GLSL optimized paths. This means every (Quake 3) shader which doesn't specifiy a custom program will automatically get flagged for a new StageIteratorGeneric/VertexLit/LightmappedTexture which in itself is in reality an optimized glsl program.

So instead of the CPU doing the tcMod or deformVertex operation the GPU will then support the full array of Quake 3 default shader effects through the "generic" shader pair.

I think this'll put GLSL to great use and lead to some substantial performance increases even when not using any custom shaders at all.

Not sure if THIS will make it into version 1 (what would you rather see? get to play with it early and in several iterations or getting your hands on few versions with very significant changes only?).

For the follow up and final version (aside from bugfixing) I'm also planning to integrate FBO's in the engine, don't have a final design for that system yet, but I'm thinking about creating two render targets and then allowing users to ping-pong between them with another special shader keyword, this should allow for pretty much any post-process effect you can think of and will make the system pretty much complete.

I've also taken a look at my VBO code but since that's not exactly useful in itself other than being a performance improvement I guess it can wait.