Hot answers tagged

7

I see a few issues. you are doing a lot of linear scans over vectors (at least 2 for each neighbour for each node you examine). This will be pretty slow. You don't even need the closed set if you just have a bool isClosed in the Node. You should sort the openset or make the openSet a min heap of some description. This will make the search for the next ...


3

Since performance is the most important thing - I would rewrite this to use arrays rather than standard library containers. The problem with using data structures designed and developed by someone else is that if you don't understand how they're implemented you'll very easily end up performing millions of unnecessary operations - including memory allocation ...


2

As you yourself have stated, you still didn't have resorted yet to optimizations. So yes, there are many ways to speed that up. But since you were talking in general terms, I will stick with what I think is the best general guidance for improving path-finding performance: decrease the size of the problem. Or in other words, search less and search smaller. ...


1

Primitives get rendered in the order they're found in the vertex buffer or index buffer if you're using one. You can use the index buffer to sort your primitives to render multiple mesh at different z-orders without having to move the vertices around in a single draw call provided they all use the same render settings (shaders, textures, blending, etc). So ...


1

The problem was this: bool AStar::Contains(std::vector<Node*> _pVector, Node* _pNode) { return find(_pVector.begin(), _pVector.end(), _pNode) != _pVector.end(); } It made a copy of the vector every single time it was called, wich made it incredibly slow. Making it a pointer to the vector increased the time from about 30 Seconds to only about 6 ...


1

EDIT: Setting it on Release mode will make the pathfinding ALMOST instant This is probably the key piece of information. Although you don't say so, your problem is presumably that you're using the STL in a debug build in something being compiled within Visual Studio. Visual Studio's implementation of the STL is notoriously (and catastrophically) slow ...


1

300 nodes in 0.03 seconds means only 10,000 nodes per second, which seems rather slow. Before implementing more complicated approaches such as hierarchical partitioning, the first thing I'd do is to optimize the code. Run the profiler to find out which functions are using the most time. It is often surprising where the time goes, and it is a waste of your ...



Only top voted, non community-wiki answers of a minimum length are eligible