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 commandeered it? Sorry anyway! @Angen could you take it back?

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.

Partially 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. Fixed in rP22321.

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). Also it shouldn't break compilation of the pyrogenesis binary, only tests.

In D1753#79796, @wraitii wrote:

Anyways what I'm saying is that I won't commit this, I don't really mind it being committed but it's likely to be forgotten. Have you ever actually used it more than once @vladislavbelov ?

In D1753#79771, @wraitii wrote:

feels like a bit of a long script for something that can be approximated by (syntax pending) git diff --name-only -- *.cpp | sed -i 's/Copyright ([cC]) 20[0-9][0-9] Wildfire Games/Copyright © 2019 WildfireGames'

In D1927#79606, @Stan wrote:

yeah I meant a - b > epsilon || - a + b >= epsilon

I think it really depends on a compiler. Theoretically std::fabs can be faster because of less number of arithmetic operations and less number of comparisons.

In D1927#79601, @Stan wrote:

Test pass in release and debug mode for me.

Thank you!

In D1926#79570, @Stan wrote:

Do you see the black spot where the shield should be ? People will complain.