Questions about performance: Cybran build drones
-
Loud removed them completely didn't they? and they got tons of performance from it. worth it. IMO. the graphics are less important than performance.
-
That isn't true and we all know it. Graphics is as much part of a game as the gameplay is, especially for people that are just starting out. This PR will bring the costs of cybran engineers in the same range as any of the other engineers, without impacting the aesthetics too much. Imagine the speedup when you're playing with four cybrans in the game, all making hives at some point
. -
yeah I understood that not suggesting the PR be changed. also I said "IMO"
-
@tatsu I 100% get you. you are right, but only to a degree. Most of us play "icon manager" from the far zooms, so it's the norm, but in the interests of growing the community keeping some of the interesting aesthetics is important. After all we command around robots and tanks, not datatype UEL0106@0xffaff99
-
Awesome improvements!
I have one small nitpick, though: It looks a bit awkward when the SACU or a hive has multiple drones and they all weld the same spot. In my personal opinion I would give them back the needed number of dummy entities. I would focus on other non-visual performance improvements first. You mentioned that there is actually a lot to gain by just optimizing a lot of function logic all over the game. If we after that see that we absolutely want to squeeze the last performance drops out of the game, we can still talk about optimizing the drones even more. -
@BlackYps I can experiment with removing that part of the optimization, but it will introduce some additional emitters too (for the welding effect). Note that for tech 1 engineers the aesthetics are the same.
-
@BlackYps After thinking about it a bit more I am reluctant. The reason I choose for having a constant number of weld points (one for the builder, one for all drones) is to prevent using tables. Tables need to be allocated and (eventually) deallocated. Deallocation is something we have no control over, that is what the garbage collector does for us and that is part of the stuttering that you see late game when you would be able to speed up the game. That is why Crotalus is looking into whether we can reduce the table count in various places.
The problem with it is that I can not definitively tell you that not having tables will reduce stuttering. We have no control or info over the garbage collector as to what it clears, when it clears it and whether it causes stutters. All we know is that it runs quite aggressively and quite often (each one or two seconds) and that is also the stuttering that you can see in the video. Because of it we can not test how much these (relative small, but in large amounts) table allocations 'cost' us indirectly, I can only give you a gut feeling that it matters.
I am making it look more natural, specifically:
- Make them change weld points with the original speed.
- Make the weld points be assigned randomly for the first time (this ensures when many engineers start at the same time that not all weld points are at the same time of their animation, e.g., it looks more random).
- I've made the drones fly higher, this makes it less awkward in general.
All these changes have no impact on the sim, but it does look better.
-
Doesn't the same apply for all things in memory? If you have a single dumy entity per hive you still need to allocate and deallocate it.
You are more experienced than me, so if you feel that it is a big issue, then I can't really argue against it.
I just wanted to remind that we don't have to try to fix every performance issue by focusing on the cybran drones and there are other topics to tackle that won't have any visual implications at all.Although I realize that it is a bit shitty to come around the corner and say "You know, maybe you should not implement this and work on something else first" after the work has already been done, but I didn't really have time for this earlier.
-
Doesn't the same apply for all things in memory? If you have a single dumy entity per hive you still need to allocate and deallocate it.
Yes - the (constant - two) entities would still need to be allocated / deallocated. But we can hold a constant number of references on the stack, where as the latter would require a table to keep the references each time a cybran engineer decides to build something and spawns drones. That table is part of the heap, where we keep a reference to the table on the stack. Common example when table re-allocation is quite high: when assisting a factory the drones tend to go away before the next unit is made. This means that for each unit we make / assist we allocate tables that we just threw out.I just wanted to remind that we don't have to try to fix every performance issue by focusing on the cybran drones and there are other topics to tackle that won't have any visual implications at all.
I understand, but I also think that if we can do without then why should we go with. Note that:- t1 engineers are the most common engineers, and they look exactly the same as they did before.
- Hives are typically build in groups, and once you have more than 5 hives they essentially look the same unless you keep staring at it intensely.
- t2 / t3 engineers and the (support) command units are aesthetically different - yes. I can not argue against that. Again, in large groups, it doesn't matter that much.
edit: and to answer to this:
Although I realize that it is a bit shitty to come around the corner and say "You know, maybe you should not implement this and work on something else first" after the work has already been done, but I didn't really have time for this earlier.
This is by far the biggest change we can make to the game in three to four days of work. Imagine having to play an eco map where everyone builds hives and just losing 30 ms instead of 5 ms (where you have 100ms a tick!) of the sim to hives for the sake of hives being hives.
-
@jip Wait, if I recall the 2 entities there were the laser start point, and the end point, both of which had some heavy allocation going with them. But is the endpoint just an entity for the spark particles? Could we just get rid of those?
-
It is an end point for both the beam (EmitterBeamEntityToEntity) and the sparks (EmitterAttachToEntity). Therefore we can not (and should not) get rid of them, as the sparks are part of the aesthetics that we're used to!
And there's two entities that are both end points - on the suggestion of Marlo. Where one end point is used by the engineer and the other is used by the bots.
-
The new cybran build bots are now available in FAF Develop! This should significantly improve the performance of games where you use a lot of hives.
The aesthetics changed slightly (as you can see above) and this is still open for input. If you have suggestions - please post them here.
There is a short guide here on how to play on FAF Develop and report back if anything happens:
-
J Jip referenced this topic on
-
J Jip referenced this topic on
-
J Jip referenced this topic on
