Questions about performance: Cybran build drones

The problem is time. I can spent all week on fixing this one performance issue and find something that we can all agree on, make a sample version, etc - or, I can spent a day on it and spent the other six days on other issues. There are hundreds of things that need to be looked at from a performance perspective - this is just one of them .

If I understood correct then due to recent changes only the changed files need to be downloaded. Therefore there is no large download anymore. But don't quote me on that, as it may not be 100% stable yet.

If you want to compare it side-by-side, launch the game with the FAF Develop version and then directly launch the executable of FAF found in the bin folder (Program Data/ForgedAllianceForever/Bin). The latter should use the default init file where as the former is running FAF develop. Then you can view the changes side-by-side.

edit: the purpose of this topic is to make sure the aesthetical change (which is, again - minor in my opinion) is accepted before I do the work. As I do not want to see my time go to the bin.

@arma473 if you enable caching in the client settings the download will only need to happen once. Also I think it won't need to happen multiple times without that because they are actually different files. But turn it on just to be safe.

We limit the number of unique targets. Instead of having each drone (and the engineer build arms) all have their own unique target, they all share the same target (as the engineers). With that we limit the number of entities (to 1 / builder) and the number of emitters (just 1 sparkle emitter / builder).

Do I understand this correctly, that this would make all the drones do their laser "welding" at the same spot?

@blackyps Yes - for each engineer / hive. Two engineers would have two unique welding points, ten engineers would have ten unique welding points - etc. But not each drone and each build arm having a unique welding point.

if you can increase the size or modify the look of the flying drones if function of their tech, then i'm all for reducing their number

@MadMax ?

I'd accept less drones moving less chaotically if you make the build beams teamcolored

@jip said in Questions about performance: Cybran build drones:

@MadMax ?

you rang what's up are you looking for a model from what little I read

Essentially this from Keyser:
if you can increase the size or modify the look of the flying drones if function of their tech, then i'm all for reducing their number

Not sure if having t1 / t2 / t3 drones is visually possible without introducing additional emitters (defeating the purpose of the idea). Would you be interested in making two additional drones?

yeah I can look into it any ideas on how to differentiate them they are quite small so changes may not be to obvious

also do you know the unit name for the drone?

@jip said in Questions about performance: Cybran build drones:

My question to you all is - what do you think, and do you think it is worth changing for the more sim speed?

I don't usually post in these threads as my FAF experience is purely me and a couple of friends doing comp stomps on the weekend. We're filthy casuals, so not exactly uhh... involved members of the community.

But since you asked: Yes I think it is worth it. I am always keen on anything that has the potential to increase sim speed, as that's the number one drag on my games. One of my friends is always playing Cybran.

I'll be on the FAF discord channel on Thursday 21:00 GMT+2 and on Friday 21:00 GMT+2 - please be there if you have questions. I intent to implement the changes this weekend - that way it can be inspected on the Dev branch starting next week and hopefully be live when September starts.

There was no interest last night and tonight I intent to go to the gym, therefore I'm cancelling tonights meeting. I'm going to make the PR this weekend - received the drones from Madmax.

I do not know if it is possible to delve this far into the code, but would it be possible to just make 50 builder drones, then just have them allocated to whatever is on screen, then if anything beyond that needs them to just ignore them. So an object pool of only 50 or something.

Also, what files and such is the code for this all contained in? I have some free time coming up and could look at it.

The problem with caching units is that they still take part in the sim calculations - slowing it down. The allocation / de-allocation of the units only cause a stutter - their existence cause a slow down.

I am working on it as I am writing this and currently managed to get 150 t3 engineers down to 'just' 6 - 7 ms increase when building. I'm aiming for this to be a lot lower than that. I'm in the Discord channel (soon - after finishing dinner) if you're interested in seeing the approach.

@jip Sure. Ill take a look. I have the same name there.

After sitting down with Marlo, Kale, Kazbek and a few others we managed to get the hit of the sim speed at around 6 ms for 150 t3 engineers when building, instead of 10 - 11. If we go with the idea that higher tech engineers have bigger drones (and therefore less drones) we can even get faster than UEF / Seraphim drones, cutting it down to about 3 ms when they start building.

You can see in the previous post how it looks like with 150 engineers and each engineer having 3 drones.

This is how it looks like for 150 engineers, when they have 'bigger' drones:

What we did is:

• Rewrite the Cybran build functions from scratch - ensuring that the best practices performance-wise are applied.
• Dumb down the Cybran bot unit - originally it still called all the logic that any unit would call. As an example, all the table allocations done for a typical unit are done even though we don't use any of it.
• Move a lot of the logic from the drone to the builder (engineer / commander / hive). This allowed us to cut down a lot on the logic performed on each drone.

In the long run the number of table allocations per drone is reduced drastically, the drones execute far less logic overall and the number of effects are reduced without impacting the overall aesthetics too much (in my / our opinion).

Tomorrow I'm going to try and finish it up.

An important disclaimer: the 6 vs 10/11 ms is the situation where the t3 engineer spawns the same number of drones as it did before. Meaning - we made them faster, and almost by a factor of 2. Let alone that the garbage collector is better off too causing less stutters.

Aw man, do the logic reworks mean I can no longer block MMLs with drones? (Jk all these changes sound awesome)

150 hives:
Left side: 1 ms when off, 5.0 - 5.5 ms when turned on
Right side: 1ms when off, 22 - 23 ms when turned on

Note:

• Drone count is divided by 2 (3 drones per hive instead of 6), otherwise the performance would be 11 - 13 ms.
• Hives no longer have blinking lights.

150 t3 engineers:
Left side: 1.2ms when off, 5.5 ms when turned on
Right side: 1.2 ms when off, 14 - 15ms when turned on

Note:

• Drone count is equal.

And when you have less engineers (3x t3). The beams of the engineer go to the same point, all drones go to the same point.

When you have t1 engineers - these look exactly the same as there is only one build arm and only one bot, each having their own unique build spot.

150 t1 engineers:
Left side: 1.2 ms when off, 4 ms when turned on
Right side: 1.2 ms when off, 5.5 - 6 ms when turned on

150 hives:
Left side: 1 ms when off, 4 - 4.5 ms when on
Right side: 1 ms when off, 15.5 - 15.5 ms when on.

Note:

• Effects are not visible, what we see here is the impact of the drones on the sim.

Disclaimer:

• Both instances have their own cores (2 + 2 hyperthreading each) but they do impact each other slightly regardless.

With some additional work from MadMax on the models this entire PR should be ready for review later this week

So hives are literally 4 times as fast with the new approach?
Amazing!