In D1926#79568, @Stan wrote:

Unless the props is really complex and needs its own ao they should have none. That means more space for the main structure and less drawcalls. Also having fifty different aos for one barrel kills the idea XD

In D1926#79566, @Stan wrote:

Two AOs seem like a waste of space. Also might require multiple uvs which isn't good. Updqtung props means rebaking aos anyways and now that I found a way to do it on the Gpu it should be faster

In D1926#79561, @Stan wrote:

Edit: Will also need to rebake Ao or it might look weird.

Wouldn't it better to split refactoring and adding new feature?

Yeah, I think it'd be good in future to have an option like a follow the platform scale (of course after UI scale fix).

The patch looks good for me.

I didn't review a data flow yet. I'll try to do an analysis of possible locks/concurrency accesses later.

In rP19674#33122, @elexis wrote:

Well then this doesn't indicate an issue with path.h (there might still be one despite the lack of indication though :P)

Yep.

In rP19674#33120, @elexis wrote:

Are you sure that g_args_ isn't constructed yet on Slackware or that it is only not guaranteed to be constructed yet?

Yes, it's not guaranteed, and it's not constructed. I just tested it on Slackware 14.2.

In rP19674#33117, @weberkai wrote:

But I think declaring them as static const will not be possible.

I don't see a problem for a local static const except wrong dependencies.

In rP19674#33099, @elexis wrote:

@vladislavbelov do you see undefined behavior for the std::wstring path member in the path.h constructor that could explain why Slackware segfaults but not the other distributions, see stacktrace at #4789?

There is no undefined behaviour in the path.h. The problem is in the commit. g_args isn't constructed yet.

In D1584#76397, @elexis wrote:

This one does & 0xFFFF.

This line will present in the code anyway, because it's for result, not for seed.

In D1584#76343, @elexis wrote:

Then at last, there is http://www.cplusplus.com/reference/random/linear_congruential_engine/ (@vladislavbelov)

In D1847#76097, @wraitii wrote:

I think perf impact is negligible (it's definitely better, but probably not by much, and the main impact is likely a lower number of draw calls).

Yeah, the same thoughts. It shouldn't increase and might decrease rendering time. So it's worth to not render invisible objects.

In D1847#76051, @Stan wrote:

What's the perf gain like ?

I don't have any objection to use the fast random function, because it won't be used for visual things where non-uniformness is visible.

In D1804#75938, @wraitii wrote:

I think I'll check out how that changes because that might have been WAD by me tbh. Up to personal preference I guess.

The current patch is just a workaround to remove glitches. The shader code should be refactored in future.

In D1804#75904, @wraitii wrote:

Right, I missed that (didn't actually delve back into this file much). I'd much prefer changing it to foaminterp.x * abs(WindCosSin.x - WindCosSin.y); then to be honest.

In D1804#75402, @wraitii wrote:

Wouldn't it be better to max(0, ...) the whole calculation? This is magic-graphical-code but you're changing behaviour a lot here.

It makes less sense, because you'll get no flares for some angles.

I tested and it works for me on VS2013.

In D1784#75860, @Stan wrote:

For Windows we officially dropped it when we committed #5098. For the rest of the platforms most of the ticket are about being compatible, but there is no clear decision.

What's about 2.9?

In rP22207#32992, @wraitii wrote:

Any chance you can test that?

I can test on VS2013.

In D1784#75828, @Itms wrote:

I think that if we keep supporting 2.8 we need to build patches with it, else we will commit a lot of 3.0+ changes without noticing. I believe the overwhelming majority of distributions used by our devs and contributors ships 3+.
I would be in favor of officially moving to 3+, which is possible if it is available (not necessarily the default,since it is for devs and package maintainers) on the platforms you mention.

I definitely agree to move forward and drop old versions. But probably we still have users with OS that uses 2.8 (and sometimes can't use newer versions without pain) by default or we recommend to use 2.8 by our build instructions.

Which version of boost starts support it?

I suppose we won't loose distribution here, at least we won't notice it.

The WELL512 usage was introduces in rP10446 along a bug fixing. So the only question is: would be enough to have the mt19937 to prevent the bug.

mt19937 seems ok for me, but I'm worrying about performance. Could you test how many calls of the UploadPropertiesAndPlay function we have on the biggest map with biggest number of units per second?

In D1821#74573, @Stan wrote:

That's a test so it doesn't matter much.

Actually we run all tests on our server for each diff, so it does matters if it significantly slower.

What's about performance?

In D1584#74541, @Stan wrote:

Maybe we should use boost after all https://stackoverflow.com/questions/20998470/random-numbers-c11-vs-boost

@Angen thank you for the patch!

I tested the patch and it works. Since the problem is reported by cppcheck (probably by some compiler too) I don't see a reason to refactor the whole file, because it's a bit other problem.

In D1584#74336, @Stan wrote:

Does setting the seed reset the rng ?

In D1584#74323, @Stan wrote:

Can't really make it static since we always want to generate the same number for a given Actor seed.

In D1584#74317, @Stan wrote:

https://pastebin.com/mFhKWCAu

In D1584#74312, @Stan wrote:

1000000 Samples

Could you attach the source?

In D1584#74289, @Stan wrote:

How should I test it ? I'm not really confident with profiling :)

But! mt19937 could be a bit slower of faster than the previous solution for many sounds, could you test it?

I tested the patch, it works well. We already use mt19937 but from boost. I don't see any strong reason to use the boost one. Maybe someone wants to replace them by the std:: version in future. By https://trac.wildfiregames.com/wiki/CppSupport all supported compilers support <random>.

In D1816#74161, @Angen wrote:

clamp has int as parameters (32 bits), std::max returns only 8 bits so might not bee needed. But I am not sure about that.

Clamp is a template function, so a compiler deduce a type from its arguments.

The model works now without any error, but the berries looks too polygonized. Did you smooth normals?

In D1799#74092, @Itms wrote:

If you want go ahead! Else I can commit it in an hour or two

In D1799#74058, @Itms wrote:

Still good after testing! The text improvement is a good idea yeah ?

In D1799#74045, @Itms wrote:

Do you want me to test on Windows @vladislavbelov?

As you want, I just wanted you check the text :)

The C++ part is clear for me.

In D1809#73950, @elexis wrote:

Then add it to CC.

CC is to allow people to chose between multiple syntactically and semantically correct solutions.
It's not a convention that we avoid bugs.

But CC helps to make less mistakes.

In D1809#73924, @elexis wrote:

This commit is not a cleanup, but a bugfix with some additional cleanup.
So it makes sense to add a comment so that people don't reintroduce the bug.

Then add it to CC.

In D1809#73904, @elexis wrote:

But even better might be adding the comment to the code itself, so that people stubmle upon it while reading the code.

About what? It's too common thing and it's related to many places in the code. So I'd prefer to add comments to our CC.

I got an error on the African Plains map:

ERROR: Could not load mesh 'art/meshes/gaia/berry_bush_02.dae'
ERROR: CObjectEntry::BuildVariation(): Model art/meshes/gaia/berry_bush_02.dae failed to load