Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Threatmap calculation optimization #46

Open
slogic opened this issue May 20, 2010 · 2 comments
Open

Threatmap calculation optimization #46

slogic opened this issue May 20, 2010 · 2 comments
Labels

Comments

@slogic
Copy link
Collaborator

slogic commented May 20, 2010

In master branch of Spring EnemyCreated() and EnemyDestoryed() events are fixed so we can switch into even driven mechanism.

  1. there is no vector reinitialization each update where can be up to 500 items
  2. we can remove or extend restriction of 500 untis to be considered
  3. we can provide another threatmap layer for static units, so we can use their precalculated values; also such maps vary seldom
  4. 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.

@Error323
Copy link
Owner

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.

@slogic
Copy link
Collaborator Author

slogic commented May 20, 2010

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants