This is however one of the more interesting bulletpoints and also one of the points i feel has a universal reach. An optimized Polymer-like replacement is something that could be very worthwhile, if only so that the Polymer option actually becomes a viable option instead of a Only try this at home feature due to its performance penalty.Graf Zahl wrote:The real answer lies in the middle, of course. It is true that there was very little being added to the existing code - most was replacing entire subsystems indeed.[/quote[
Glossing over your list, it seems that you have replaced a lot more than i initially assumed. I can see certain parts being very useful to the Duke community, and others subject to critical verification (such as replacing the menu code). I can see that being a point of contention. As it stands, its definitely a product of its own and certainly no easy merge of two major codebases, if that ever was the case.
Graf Zahl wrote: [*] Polymer had to be entirely disabled for the time being. The main problem is that it needs too much support code outside the renderer and couldn't be as easily uncoupled from OpenGL as Polymost. I fully intend to bring its core features - but not the renderer implementation itself - back, once the entire engine is in a more stable state than right now. Actually, programming a new renderer that is better equipped to work with current graphics hardware would be where the real fun lies.
The rest is personally a QoL thing for developers, but as i said, acceptance of that may vary. Fortunately due to the BSD license, folks will be free to take a look around and see what sticks and what does not - So overall, this is a good development Graf.