Optimizing Drawing #22
Replies: 4 comments 1 reply
-
Once prototyping is done and there is a definitive selection of buildings objects and actors I was planning on combining all te sprites into one big texture file for each category. For now I want te leave it as is since it allows for rapid development. At te moment i am working on object, building and actor templates. This will allow the addition of new content by just editing one file. And adding the button for creation. |
Beta Was this translation helpful? Give feedback.
-
Round two of running the profiler. It seems that switching between threads is the hottest function followed by pathfinding. Just an FYI: |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
I made a branch without the async didn't notice performance degradation in fact there was less stuttering. What I notice that sorting the list of cells (to get the one with the lowest estimated cost to goal) is taking a lot CPU time. (it sorts std::list<Cells*> listToCheck;) So going of of this it might make sense to try and see if a vector makes more sense. Since it is only a list of pointers the 'data' portion of the list is small so going off those benchmarks sorting a vector which contains only pointers should be much faster |
Beta Was this translation helpful? Give feedback.
-
Considerable work has been made on the bottlenecks of screen redrawing by minimizing draw() calls, but if it becomes a problem we can minimize draw calls via batching. This would require:
I've done this before and am willing to do this if needed, but I don't think there's enough draw() calls yet for this amount of work to be worthwhile.
Beta Was this translation helpful? Give feedback.
All reactions