The current situation basically originates from my changing the full rendering of everything to use shaders, which was necessary as part of the FoW work so that sprites, meshes and other things are properly covered by FoW. Of course I experimented a bit with different possibilities and now we have something that works but yes, is somewhat messy. It certainly doesn't help that we have so many different configurations. I think it's a worthwhile effort to try and clean it up a bit. Let me first correct/clarify some of your observations:

> * SpriteTextureShader: Applied to meshes ("unused"?) + sprites when requested. Not entirely sure what this does.

This does not apply to meshes but only for sprites. It multiplies the base color of the sprite that is set with glColor*() with the sprite's texture. Note that the "sprite" shaders are also used for other 2D drawing such as points and lines, such as PXS. Those don't have a texture and so the shader for those doesn't include SpriteTextureShader.glsl.

> * SpriteOverlayShader: Applied to meshes + sprites when requested. Probably where player colour comes in?

Again, only applies to sprites. Modulates the pixel color with the color from the overlay texture (Overlay.png) -- so yes, primarily, player color.

> * MeshShader: Gets loaded, but doesn't even exist?

Whoops. I probably started with MeshShader.glsl but then changed my mine at some point. Can go away of course.

> * Shaders dynamically generated from Ogre files.

These can either be dynamically generated or hand-written, e.g. when enabling normal maps for meshes a hand-written shader must be used, which is in Objects.ocd/normal_map_fragment.glsl (not a good location really, but the only place that makes sure this gets loaded before other OGRE materials, so it can be used by other OGRE materials. We might want to load OGRE materials from Graphics.ocg, too, so we can move it there).

> * LANDSCAPE: Set for landscape drawing

Now OC_LANDSCAPE.

> * MESH: Set for meshes

Now OC_MESH.

> * HAVE_LIGHT: Assume we have light information. If set, LightShader+AmbientShader query their respective textures to find how much light we have at the part of the landscape in question. Otherwise, we fall back to a basic shading model that makes sense for showing 3D GUI items.

Now OC_DYNAMIC_LIGHT. This is usually set for ingame objects and not set for GUI objects. Not only relevant for 3D but also 2D sprites.

> * HAVE_NORMALMAP: We have a normal map for our material, use it appropriately for shading calculations.

Now OC_WITH_NORMALMAP. Used both for sprites and meshes; for meshes the shader slice in Objects.ocd/normal_map_fragment.glsl activates this so it is picked up by ObjectLightShader.glsl.

> * CLRMOD_MOD2: Adds player colour overlay instead of multiplying it.

Now OC_CLRMOD_MOD2. Doesn't affect player color but color modulation as set with SetClrModulation. This is activated when the blit mode is set to GFX_BLIT_Mod2 with SetObjectBlitMode, and also used for highlighting objects in the editor when pressing Shift.

> * HAVE_2PX: Set by the landscape scaler, because we need to shade two full pixels for anti-aliasing at the edges.

Now OC_HAVE_2PX.

Plus we now have OC_SKY as mentioned by Clonkonaut.

Overall I think your suggestion makes sense, but we still need all these preprocessor flags, right?

> 3. Merge ObjectBaseShader+ObjectLightShader+SpriteTextureShader+SpriteOverlayShader as ObjectShader (?)

This will need additional preprocessor flags/checks to distinguish meshes from sprites with texture from sprites without texture from sprites with texture and overlay. But that should be fine. Overall I'm not sure we gain too much, but it probably makes sense to try it out and see how it works. I'm somewhat worried we merge some of the files but then have more preprocessor checks in those files. I don't know what's better.