Make OpenGL terrain rendering less demanding on hardware

I've linked nhas current opengl branch. I am not sure if he does use GLSL, but i can confirm that the terrain multitexturing is working with his code on win32.
It looks very good and promising...

awesome that you are back at work nicolai!

Note that I am currently doing big refactorings which will land soon - if you can avoid it, please do not move too many functions/files around :-)

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.

I agree with nicolai, it is not the time to switch to cutting edge opengl for widelands.

It is kinda hard to say what to do with this bug. For now it is won't fix, but in the future, we might want to take it on again.

I totally agree with you. The intent of this bug report was to achieve the same visual style with OpenGL as with SDL on as many hardware configurations as possible. My rather (very limited) research on the issue pointed to GLSL...

But the current solution seems much nicer, because it just don't use multitexturing any longer (or in another way) and is therefore not dependant on the very differtent support for this on older and newer hardware.

So my vote would even go to "Fixed" as long we do not find hardware which does not deliver the same OpenGL style as the SDL Renderer does.

I quickly refurbished this bug to match the ongoing work :)

Should be fixed in trunk in r6501.

Released in build-18 rc1.