You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In master branch of Spring EnemyCreated() and EnemyDestoryed() events are fixed so we can switch into even driven mechanism.
there is no vector reinitialization each update where can be up to 500 items
we can remove or extend restriction of 500 untis to be considered
we can provide another threatmap layer for static units, so we can use their precalculated values; also such maps vary seldom
we can implement buffer technology to calculate threat per fixed unit chunks, until all units processed. then this buffer becomes active threatmap layer. so we can predict CPU consumption will never raise above some value.
Your ideas are welcome.
The text was updated successfully, but these errors were encountered:
Well I guess the main question is: "Does the threatmap update() come up high in the profiler?" If so then this will be a good investment, if not I don't see the direct need.
As i remember your graph, threatmap is eating more and more CPU closer to middle-end game. Generally there are three logic blocks eating CPU: repathing, tasks & threatmap.
In master branch of Spring EnemyCreated() and EnemyDestoryed() events are fixed so we can switch into even driven mechanism.
Your ideas are welcome.
The text was updated successfully, but these errors were encountered: