New answers tagged

0

This is one of many ways out there (This is what i think and probably not the best). This way is probably a little expensive to do. But here we go. Try to split the rendering step into 3 parts (Your spritesheet count) and for each part try to call the draw call as few as possible (batching) using the same texture/spritesheet. If you have a trouble on the ...


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 ...


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. ...


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 ...


0

What you have here is not a multidimensional array. What you have is a vector which references a bunch of vectors which reference a bunch of vectors which reference a bunch of objects. The problem with these many layers of indirection is 1. that your CPU needs to jump through all these memory references each time it looks for a tile and 2. that these memory ...



Top 50 recent answers are included