my AStar implementation is sooo slow, maybe someone could look over it and give some hints? It works basically OK for small paths, but when I calculate a path on my Map from say 500,500 to 400,400 (with no obstacles in between) it takes like 12 seconds, which is far too long.Using a PriorityQueue is my latest test, but didn't greatly (at all?) improve performance, unfortunately.

One of the @ is the start positionThe target is far to the top left (out of the screen)Every tile that contains an 'X' is in the closed_list

I'm a little bit confused here, should the code even be checking the bottom right tiles of the screen? There's like 0 possibility that the path goes that way (unless there would be an obstacle, but there are none). Somehow the tiles on the right and bottom have to be ruled out? Heuristic problem? I'm not sure anymore

The speed issue is most likely caused by using a priority queue for the closed "list". This should just be a set of closed nodes that you check contains() on. You'll also find lots of posts around here that describe how to make your own set using arrays of booleans, since you're just exploring a grid. Though that's probably an unnecessary optimisation.

For the over-exploration, that's because you're estimating the distance left using the Euclidean distance but you don't allow diagonal moves. So it greatly underestimates it. Try using the closer estimate of:

The implementation of PriorityQueue is pretty lame and easily 100x slower than it could be if it were optimised for your case. pjt33 of these parts donated me a BinaryHeap class which was far, far faster when used in the open list; and the closed list should be a boolean grid (preferably made with packed integers so they're bits, not booleans).

and the closed list should be a boolean grid (preferably made with packed integers so they're bits, not booleans).

I wouldn't recommend using booleans for the closed "lists". With booleans you have to clear the whole map to false after each pathfinding job. Instead I use an int for each tile together with a job ID. When you want to close a tile, you set it to the job ID. To check if a tile is closed, do

tile[...] == jobID;

. The benefit of this is that you won't even have to clear it later. Instead, just increase job ID by 1. With an int, you can do 4 billion jobs before having to clear it (before your job ID wrap around all the way to 0 again).

That's fine if you've only got a few entities wandering around on a small map but if, like me for example, you've got maybe 2,000 of them running around on a 256x256 grid, that'd consume 500mb of RAM just for closed lists alone if they're all pathfinding. Using a bit-grid consumes 1/32th of the RAM (15mb for the mathematically challenged).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org