phosit

The simulation requires much time in the late game. While this is expected we still should ompimize it. For reference: https://trac.wildfiregames.com/wiki/SimulationArchitecture There are many ideas: @Freagarach tried to send messages only to some entities. https://code.wildfiregames.com/D2704 [[Abandoned]] @Mercury and @wraitii think about multithreading. i.a: https://wildfiregames.com/forum/topic/90006-mutex/ Mercury also made an allocator. https://code.wildfiregames.com/D4718 There is a new datastructure from wraitii. https://code.wildfiregames.com/D1739 Meta: Isn't that (many improvement ideas) a sign of a deeper problem. Should we change the message system or move away from it altogether? Do you have other idears? (Did we change the system already, why is there a 2 after Simulation?)

Did you see https://trac.wildfiregames.com/ticket/2195 ? surendering is part of that.

In the lower left there is "Alpha XXIV" but there should be "Alpha XXVI: Zhuangzi" For me community/0ad a26-1 and a26-2 work.

I also tryed to describe this but wasn't that precise.

"It does not always capture the curser" is it that what you are saying? Im on a wayland display and had the same issue. It can solved by using SDL_VIDEODRIVER=wayland as a environment variable.

The changes are reverted: Not all were discussed in this thread and I made some bad examples. The diff is attached To explain all of them: Were to Include third party libraries was not defined in the CC. I formulated wat Vladislav said on IRC. The example with boost/optional is bad since we try to have few dependencyes on boost. I replaced "Use STL when appropriate." with a link to C++ Core Guidelines rule. At "Use nullptr" I added "This convention should be implicit but stated hear because there are still many places were `NULL` is used." I removed "Don't do `if(p) delete p;`". I havent seen this pattern in code and somebody knowing C++ would not write that -> will be pointed out at code-review I replaced the paragraph about auto with a link to C++ Core Guidelines and the sentence "Be aware that overuse of `auto` can also cause problems in the long-run." I moved the Code And Memory Performance guidelines to the bottom and added a link to C++ Core Guidelines. Algorithms I didnt wan't to write a harsh rule("No raw loop") or a wage one("Use algorithms when appropriate"). So wat i did was write a reason why not to use raw loops. here again the excample was bad since I wrote std::ranges::iota instead of std::views::iota and we don't require support for either. CC.diff

Scenario: two component of different type lock their mutex. But both could access a shared/global resources. Oh... now i get the question of this whole thread: you asking about thous shared resources. I don't know but i suspect there are many. And much code to check, also JS. We have information about the cpu's used: https://feedback.wildfiregames.com/cpu/

I made changes to CC: http://trac.wildfiregames.com/wiki/Coding_Conventions?version=56 The part about C++ Core Guidelines and that about algorithms are not as present as i wish them to be. But i didn't know what to write

Every component could do anything. Because of that it is hard to paralelize the message-system; and it is hard for the compiler to make optimizations. Did i understand you correctly: you want one mutex per ComponentType? That would be useless because a recource might be mutated by multiple ComponentTypes. The function taking long is PostMessage. This function sends a message to all components which have subscribed to the messageType. Some subscribed components do nothing: RangeManager subscribes to PositionChanged but has to check if it "trackes" the entity (CCmpRangeManager.cpp L570). This could be changed to first ask all subscriped component if they realy are interested in the message (This could be done in paralell). And then sending the message to the interested components (in sequence). An other idea: At the moment most Components have a switch in the HandleMessage. If Messages were static types this switch would not be necesary. This aproach might interfere with JS.

A link to CppCoreGuidelines would indeed be usefull. Yes but why? Would you go for str::FromDouble? The misc part will not go in to CC. "use std::string were possible" would be to harsh.

Ref: https://trac.wildfiregames.com/wiki/Coding_Conventions#C auto This paragraph should be removed/shorted, because sometimes it does make the code more verbose by adding very little value, sometimes it is slower because of implicit conversion, and sometimes it is impossible lambda; structured binding and trailing return type. The CC should state instead: Use const auto& or auto&& in range based for loops and algo-lambda-parameter or write a comment why not. const int i = std::reduce(vec.begin(), vec.end(), [](const auto& l, const auto& r){return l + r;}); l and r is what i mean by algo-lambda-paramerer. algorithm There is already: But STL is an ambiguous term and this paragraph does not appreciate std::algorithms enought This general rule is not good. Because sometimes i have iterators or the body is an existingt function. In both situations it is bether to use std::for_each. I would also write a paragraph about avoid old stile for-loops because iterations could be bypassed from within the body: // avoid for (size_t i = 0; i != 9; ++i) { // The iterator can be mutated. This loop never ends. ++i; } // saver for (const size_t& i : std::ranges::iota(0, 9)) { ++i; // compile-error } Misc could we try to integrate the code from source/lib? Licence; brace style; string type. propably rewrite it in source/ps. Own string type is a bad solution to add more functionality: free functions do it as well.

I remember a ticket were they talked about distuinguish phase by backgroundcollor.

I don't know what this "man throwing a discus" is. I'm a noob i know I start a new game: If it is ordered by function i know it produces units and in is enabled on phase 2 or 3 (since it is disabled on phase 1) If it is ordered by phase i know only that it is enabled on phase 2 or 3 (since it is between a building of phase 2 and one of phase 3)