Added minimal atomic operation support in XC_Core, these operations should give the ability to use thread safe access to variables, considering I took these from the UE4 sources, I shouldn't have too many problems with a linux build, unless I actually need updated libraries...
With that done, the game will create up to 4 threads (XC_GameEngine.ThreadCount setting)(I may increase the cap to 8.), dedicated to catching the moment whenever actors are ready to be replicated.
The replication loop will take a whole block targeted to a specific player and process it as a block, this means that once a single thread decides to update a remote player, it does the entire combo of prioritizing/relevancy/replication in the same task.
Since threads can only sleep for 1 millisecond (WINDOWS
) without hogging up too much CPU, the first... and maybe second player's replication task will be processed almost invariantly by the main thread an not the extra ones.Either way, the whole new code caches the actor consider list and dispatches tasks so I can't say that the whole new replication loop being slower at < 4 player count is a failure, while the loop runs 35% slower at 1-3 player scenarios compared to non-XC_Engine loop, it becomes much faster as you add more and more players.
This means that a good box could run a 20 player server at 100 tickrate without having framerate problems, or needing a net rate adjuster.
Other info:
- Before the actor prioritization is done, the player's View is acquired using the event PlayerPawn.PlayerCalcView on the server.
That had to be left out of the multithreaded code due to being an UnrealScript event, UnrealScript uses a lot of global variables in a non-thread safe way, so technically, UnrealScript would NEVER run in more than one thread at a time without having most functions and macros rewritten (full game recompile), I guess that was yet another reason to drop in in UE4.
- Traces have their fair share of non-thread safe stuff, namely a single global variable used for 'bright corners surfaces'... had to grab a UE3 fast trace function and edit it a bit so it could be called from more than one thread.
- Lastly, the 'ReplicateActor' calls needed spin locks, basically, I can never call ReplicateActor (or initialize Channels) more than once at the same time
So in the end not everything in the replication loop runs in parallel, or start running at the same time but having at least 70% of the replication load being distributed among cores is a huge win for me.
PD: Finally fixed that faulty FCollisionCacus encroachment checks, and with no speed loss at all !
With that done, the FCollisionCacus physics behaviour should be 99% accurate to the old one, until I decide to add static mesh collision one of these days (at least for non-movable decorations, trees!)...
