Make OpenGL the standard renderer

[SirVer]

I suggest making the OpenGL renderer the standard one. It is way faster than the SDL one and basically all devices have openGL these days. We could still fall back to SDL on problems, but I vote for making OpenGL standard. This also includes removing the highly experimental tag it still has in the advanced options.

Note that it would be cool to fix bug 722196 beforehand, but I do not see it as a prerequisite really.

I'd like to hear more opinions though.

[Hans Joachim Desserud (hjd)]

>We could still fall back to SDL on problems, but I vote for making OpenGL standard.
Would this be possible to do automatically if the system (/device) does not support OpenGL without any user interaction? In other words, how do we plan to handle this? I just envision some user who attempts to start a new game, gets a black screen, doesn't know about the SDL-mode and is unable to play the game. Then again even my five year old laptop ran WL with opengl, so I don't know how much of a problem this actually is.

Oh, and I would prefer bug 722196 was fixed up-front, since this is the main reason why I currently don't use the opengl-mode.

[Shevonar (shevonar)]

Widelands has this automatic fallback implemented at the moment, so there isn't even work to do :)
And I agree with making openGL standard but fixing bug 722196 before.

[Hans Joachim Desserud (hjd)]

>Widelands has this automatic fallback implemented at the moment, so there isn't even work to do :)
How convenient. (How does it work?)

If that's the case then bug 722196 is the only blocker I can see to this change.

[SirVer (sirver)]

shevonar,are you giving bug 722196 a shot?

[Shevonar (shevonar)]

I'm currently working on it, but cannot promise anything :) But the OpenGL code is quite understandable.

[Carli (s3734770)]

Some comments:

>We could still fall back to SDL on problems, but I vote for making OpenGL standard
Linux OpenGL drivers have a fallback mode to software rendering. How do you want to detect if the OpenGL driver is the software one or not?

>I'd like to hear more opinions though.
The current implementation in widelands uses the OpenGL intermediate mode which is deprecated and slow. It produces a 3x call overhead for each landscape tile and for each drawn building or worker. You should fix that first to make OpenGL "really" faster.

[Shevonar (shevonar)]

It seems that you know what you are talking about :) Why don't YOU give it a try. I was working on bug722196 and would try to improve the openGL code, but I have absolutly no spare time to spend for widelands :( I can't do anything till the xmas holidays. Fell free to improve things earlier ;)

[SirVer (sirver)]

Fallback detection could be done via a benchmark (maybe). Maybe there is also some kind of OpenGL flags that can be checked? It seems you are quite knowledgable on the topic Carli, why don't yo give a go?

About the overhead: The current GL Code is *significantly* faster than the software mode and in future it also looks better (as soon as shevonars fixes are merged). It hardly matters if it could be *even faster* (though it would be desirable) as it is fast enough. Deprecation is another topic though, having software that will stop working in the future is hardly a nice asset.

[Nicolai Hähnle (nha)]

I think the only thing we can really do is what everybody does: use heuristics based on the vendor string and other information (essentially what you see when you run glxinfo). At least the Mesa software rasterizer identifies itself clearly.

I agree with Carli that the way the renderer currently works is not very nice, though I don't think the deprecation is a problem in practice. Whether they like it or not, OpenGL vendors will maintain those paths for at least another decade. Still, in the long run, it would be nice to refactor the map rendering so that the inner loops get pushed down into the backend-specific code. It's quite silly to have the same loop over all fields used for both OpenGL and software rendering.

[Nasenbaer (nasenbaer)]

Any news on this bug? :)
I really like the work you've done and shown in the screenshots, Shevonar :).

[Shevonar (shevonar)]

I have been very busy the last months and will be so for the next 3 weeks. After that I will have a look at it again. However I thought it would be even better to realize Carlis suggestions in #6. This would mean a mayor rewrite of the openGL code and will take a lot of time. So I will finish what I did so far for build17 and after that I will see what I can do to improve (and speed up) the openGL renderer even more. Be patient a few more weeks :)

[Nasenbaer (nasenbaer)]

@#11 I definitely will :).
Thanks for your effort so far!

[Angelo Locritani (alocritani)]

Hi,
of course, using OpenGL, the rendering part is faster and less cpu intensive (at least for me). But it seems that it take a lot more loading a game (loading animation part, according to interface).
I'm the only one who noticed it?
Do you think it can be improved?

[Shevonar (shevonar)]

I cannot confirm this. The only thing that can take longer is the loading of terrain textures, cause only the terrain is rendered via OpenGL and therefore the terrain textures are converted. Everything else is done via SDL as before. However the OpenGL rendering and loading can have lots of improvements.

Merged at revision 6242

[Nasenbaer (nasenbaer)]

I just wanted to say thank you for all the work on OpenGL :)!
Thanks Shevonar!

[SirVer (sirver)]

Released in build17-rc1.