Comment 4 for bug 939709

re #1: Thanks :-)

I am not using GLSL. Actually, the code in the branch right now uses at most two texture units at a time, and it does the "edge fuzzing" (which I will rename to "edge dithering", I prefer that term now that I've read it) using multiple passes. My rationale for this was that it allows minimizing the number of state changes. All triangles are sorted by terrain type, and then all triangles involving a fixed terrain type are drawn at once using a vertex array.

The downside is that in the worst case, where every pair of adjacent triangles is of a different terrain type, every triangle will be drawn 2.5 times on average.

So using multiple passes can cause more overdraw. However, the GPUs that are limited in terms of framebuffer fill rate are probably the same GPUs that run into limitations doing the 6-stage multi-texturing of the old renderer. I don't think it makes sense to try to reduce the number of passes unless there is really concrete timing evidence in its favour.

As far as this bug is concerned, I believe that my branch will essentially fix the issue once it is done. However, I don't plan to introduce GLSL. I don't think that this is the right time to start using GLSL anyway. It is true that modern OpenGL is GLSL+VBO+etc., but for Widelands I would prefer to just be pragmatic and support the widest possible range of systems while keeping the number of different code paths small. We can talk about it again once we hit a system that supports GLSL without also supporting fixed function (GLES on some mobile device, perhaps?), or consider some feature that really depends on it.

re #3: So far, I haven't actually touched a lot of code. I believe it is mostly limited to this:
1. I split GameView into two different classes, one for minimap rendering and one for the actual view rendering.
2. I added an option to the picture loading code that allows loading GL_INTENSITY textures. I use this for the "edge fuzzing" mask texture (Technically, one could also change the "pics/edge.png" to use an alpha channel; the choice is largely arbitrary - mostly, I didn't feel like opening GIMP - but the texture does require slightly less memory using the approach I have now chosen).
3. I added an "edge_fuzz_layer" option to the Terrain_Descr. This option allows some control over how edges between different terrains are handled. The old renderer had an approach that resulted in some IMO strange and noticeable asymmetries. In the new code, this old approach is only used for different terrains that are on the same layer.