Code review comment for lp:~widelands-dev/widelands/graphics

Revision history for this message
SirVer (sirver) wrote :

Welcome back in action, Nicolai!!

The code does not compile without some changes with glbinding and once it is done compiling it crashes: Pastebin link: http://pastebin.com/9iBGe7iS
It also seems that my system (Mac OS X, Early 2013) cannot run the GL 4 code path.

Could you change the owner of the branch to widelands-dev so that fixes can be pushed?

I did not read through the code yet, but I want to open the discussion early. I would be interested in some benchmark numbers comparing the code paths. For my discussion, I am going by these assumptions, please let me know if they are incorrect:

1) GL2 code path is showing up in profiling, but is not the bottleneck in bigger maps/long games, i.e. where it matters.
2) GL4 code path creates the exact same output then GL2.
3) GL2 can not be removed, since this would cut off a significant amount of customers.
4) Offloading work from the CPU to the GPU is desirable, since Widelands is CPU bound while the GPU is mostly idle.

Given 1) and 3), I dislike the idea of introducing another renderer. We got rid of the b18 software renderer because maintaining 2 render paths was painful and therefore not correctly done (many bugs, not the same capabilities after some time for divergence). I would hate to have to support 2 render paths again. Also there is still the dream of having Widelands on mobile - which seems to be essentially GL2 ES or GL3 ES - which seems closer to the current GL2 code path.

Given 4) the question is how much can we get from your changes into the GL 2 code path? For example, using texture lookups for the minimap seems feasible in GL2 as well afaik, but terrain rendering probably is not.

My ideal outcome of this proposals is that we get as many features as possible backported into the GL2 code path and drop the GL4 code path entirely. Is that feasible?

« Back to merge proposal