Did you reproduce @Itms steps before the patch?

I would certainly hope none otherwise MacOS has been behaving wrong for years.
The only place I can think of that parses strings to number is GUI sizes, which would previously parse things like "3b" as "0" instead of the 'correct' "3". I don't think there's mods or 0 A.D. code that relied on that - and I'm not sure we want that code to live.

Do we really need that behaviour for wrong strings?

How many lines of our code depend on this behaviour (that wrong strings are still parsed)?

I tested, now the reflection works as after my commit.

In D1976#82463, @Stan wrote:

custom color space might be weird, since the following code would be messing it up :P

It depends, because color correction may present on each side: os, gpu driver, monitor.

I think the patch should be tested on multi-monitor environment and with a custom color space.

Fixes "check".

@wraitii @elexis I'm going to commit it if you don't have other objections.

Fixes notes.

Adds usage of setChangePerspective.

@wraitii could you check that?

In rP22344#33832, @Stan wrote:

I probably should have asked that before, but wasn't std::thread broken/missing features on windows ? https://stackoverflow.com/questions/13134186/c11-stdthreads-vs-posix-threads

In rP22344#33828, @wraitii wrote:

I don't understand the question, sorry?

Why pthread_t was replaced only for the main thread and not for workers?

In D1928#81321, @wraitii wrote:

This is kind of blurring the sort of MVC pattern we had before. Now the part updating the GUI and the part holding the state are in the same component. It's not necessarily an issue (particularly here since this component isn't intended to be re-usable elsewhere) but we should perhaps think of a more general solution.

Removes g_DevSettings.

In rP22310#33814, @aeonios wrote:

There really isn't a better way of doing that. Any given approximation of refraction isn't going to be much different from what we've got.

Yeah, that's what I'm talking about. It's just a little improvement. Though all these flat refraction maps are workarounds.

Fixes @elexis's notes.

Fixes missing file and notes.

Move the g_DeveloperOverlay creation to the session.js.

Fixes compilation.

WAT, why I commandered?

I agree that it's harder to read the code without indents for some people. Only objection that I'm thinking about, if you remove #if with leaving the code you need to fix the indents again that also means you rewrite the blame again.

In D1928#80962, @Polakrity wrote:

Just create an object literal.

var g_DeveloperOverlay = {};
g_DeveloperOverlay.init = function() {}

or

var g_DeveloperOverlay = {
   init = function () {}
};

In rP22310#33789, @aeonios wrote:

Well, red water problems are a longstanding issue. It occurs when it tries to draw areas outside of the water during refraction, and appears at certain angles for reasons that aren't easy to explain but probably have to do with the hack used to produce refraction.

Mostly because of scissoring #2692, but also we have inaccurate refraction projection (inaccurate in relation to the real refraction angles). We may calculate it more carefully.

Fixes notes.

Thank you for the patch!

@elexis @wraitii Any thoughts about new (OOP) version of the overlay?

Do we have places where the removed code might be useful? Why it was added?

Fixes @elexis notes.

Created a fix in D1937.

In rP22319#33628, @Stan wrote:

https://stackoverflow.com/questions/54027717/is-fabsf-part-of-the-std-namespace-in-c11
https://en.cppreference.com/w/c/numeric/math/fabs Maybe missing an include to <cmath> ?

Nope, I was wrong, I thought std::fasbf already presents in C++11. But it doesn't. The include can be added too (though it already presents in the include tree).