In D4279#182375, @wraitii wrote:

I believe Vlad's point is that you could actually just query 4 height map points and draw a more accurate polygon.

Not really, the problem with the patch's approach is that it uses a single point. And it might differ significantly in neighborhood.

In D4279#182345, @s0600204 wrote:

I might be wrong, but from what I can tell, the problem with that approach is that it seems to ignore the water plane.

Sure, and you can easily do max(waterHeight, mipmapHeight).

Maybe you could get average height from HeightMipmap?

Fixes "system".

In D3037#181783, @Angen wrote:

Do you mean setguiscale to take string and parse number from it?

In D3037#178829, @Langbart wrote:

I noticed some thin black lines, and the numbers in the selection list appear a bit smudged.

In D4108#181466, @Stan wrote:

Forgot the build-osx-libs.sh file :)

Thanks!

Uses @s0600204 and @wraitii patches.

Committed in rP25905.

In D4265#181272, @Stan wrote:

What's the benefit of having an extra file to load for fowarding?

Is intended to always center the placeholder? One might want to have it on top.

An easy try to fix the unused constant.

In D4251#180887, @Stan wrote:

Does that mean mac and Linux can no longer deserialize CStr?

Fixes compilation.

In D4251#180770, @Stan wrote:

What's the advantage of templates here? Is it faster, safer, better C++ (vs C style code) ?

Type safer. Also allows to remove unidoubler in future.

In D4245#180502, @Stan wrote:

Ok. We should find a way to test this patch with the _UNICODE defined like on OpenSuse.

In D4245#180492, @Stan wrote:

Would be nice to commit D4223 first if it's correct, because this patch might make rebasing complicated.

Moves the assert above.

In D4244#180458, @Stan wrote:

For OGL 3.3 deprecation it needs to work on macOS first. :)

In D4244#180451, @Angen wrote:

Strange unrelated calltack from running vs, not happening without the diff:
1 vcruntime140.dll!memcpy() + 78 bytes
2 vcruntime140.dll![Frames below may be incorrect and/or missing, no symbols loaded for vcruntime140.dll]
3 [External Code]
4 nvtt.dll!nvtt::Surface::Private::Private(const nvtt::Surface::Private & p)
5 nvtt.dll!nvtt::Surface::detach()
6 nvtt.dll!nvtt::Surface::toGamma(float gamma)
7 nvtt.dll!nvtt::Compressor::Private::compress(const nvtt::InputOptions::Private & inputOptions, const nvtt::CompressionOptions::Private & compressionOptions, const nvtt::OutputOptions::Private & outputOptions)
8 nvtt.dll!nvtt::Compressor::process(const nvtt::InputOptions & inputOptions, const nvtt::CompressionOptions & compressionOptions, const nvtt::OutputOptions & outputOptions)
9 pyrogenesis.exe!CTextureConverter::RunThread(CTextureConverter * textureConverter)
10 pyrogenesis.exe!Threading::HandleExceptionsBase<&CTextureConverter::RunThread,void (__cdecl*)(CTextureConverter *)>::Wrapper(CTextureConverter * <args_0>)
11 [External Code]

In D4244#180446, @Angen wrote:

It crashes on unit demo without writing/displaying any error, crashdump is 0kb

Adds @Angen suggestion.

In D4244#180438, @Stan wrote:

My point is that there is no way we can lower the number of bones of some of the models armatures in the current state if there is no way to keep attachpoints :)

I don't remember.

In D4244#180436, @Stan wrote:

Well it matters a lot for artists since we basically have to duplicate bones to have objects like swords helmets etc.

GPU doesn't care about artists. It just have a limited amount of memory for uniforms.

In D4244#180434, @Stan wrote:

Does that count prop bones ?

In rP25843#53452, @wraitii wrote:

I would argue against it, as the transformation is less efficient. For that matter, I'm not entirely sure we actually need to transform much here.

The commit can be reverted after fixing the bug in the tex.cpp. Reported the original bug in #5022.

Fixed in rP25794.

In D4159#177332, @wraitii wrote:

Oh, I was mostly thinking about actual disk space, not GPU memory.

Nah, our disk space waste is much bigger than just UI previews. But previews add own wasted space as well.

Also some of our previews have alpha channel which is useless.

In D4159#177320, @wraitii wrote:

Mh, would it really matter? The individual PNGs are about 160Kb each. At best we'd gain 1-2 MB total maybe?

Sure, in total we leak 40MB of GPU memory. So we can save 20MB.

I think our previews are bad in terms of wasting space. They can be easily reduced to 512x256 without quality loss.

Related thing: https://wildfiregames.com/forum/topic/13163-cmatrix3d-multiplication

According to the Valgrind website, they don't - and probably never will - support Windows systems[1], so I've also made it non-Windows option.

Agree with C++ changes.

In D4107#176237, @Langbart wrote:

The images from Barracks, Stable, Elephant stable and Heroes look a bit too dark. For the Stable and the Elephant Stable, the rank symbols are not as clearly visible as in the Barracks image.

Agree, too dark and rank images have low resolutions.

Actually the same bug can be achieved and before the patch, but it requires additional step.