Question

I’m a real speed freak if it gets to algorithms, and in the plugins I made for a game.

The speed is.. a bit.. not satisfying. Especially while driving around with a car and you do not follow your path, the path has to be recalculated.. and it takes some time, So the in-game GPS is stacking up many “wrong way” signals (and stacking up the signals means more calculations afterward, for each wrong way move) because I want a fast, live-gps system which updates constantly.

I changed the old algorithm (some simple dijkstra implementation) to boost::dijkstra’s to calculate a path from node A to node B

(total node list is around ~15k nodes with ~40k connections, for curious people here is the map: http://gz.pxf24.pl/downloads/prv2.jpg (12 MB), edges in the red lines are the nodes),

but it didn’t really increase in speed. (At least not noticeably, maybe 50 ms).

The information that is stored in the Node array is:

The ID of the Node,
The position of the node,
All the connections to the node (and which way it is connected to the other nodes, TO, FROM, or BOTH)
Distance to the connected nodes.

I’m curious if anybody knows some faster alternatives in C/C++?
Any suggestions (+ code examples?) are appreciated!

---

If anyone is interested in the project, here it is (source+binaries):

https://gpb.googlecode.com/files/RouteConnector_177.zip

In this video you can see what the gps-system is like:

http://www.youtu.be/xsIhArstyU8

as you can see the red route is updating slowly (well, for us – gamers – it is slow).

( ByTheWay: the gaps between the red lines have been fixed a long time ago :p )

Answer 1

Since this is a GPS, it must have a fixed destination. Instead of computing the path from your current node to the destination each time you change the current node, you can instead find the shortest paths from your destination to all the nodes: just run Dijkstra once starting from the destination. This will take about as long as an update takes right now.

Then, in each node, keep prev = the node previous to this on the shortest path to this node (from your destination). You update this as you compute the shortest paths. Or you can use a prev[] array outside of the nodes – basically whatever method you are using to reconstruct the path now should still work.

When moving your car, your path is given by currentNode.prev -> currentNode.prev.prev -> ....

This will solve the update lag and keep your path optimal, but you’ll still have a slight lag when entering your destination.

You should consider this approach even if you plan on using A* or other heuristics that do not always give the optimal answer, at least if you still get lag with those approaches.

For example, if you have this graph:

1 - 2 cost 3
1 - 3 cost 4
2 - 4 cost 1
3 - 4 cost 2
3 - 5 cost 5

The prev array would look like this (computed when you compute the distances d[]):

       1 2 3 4 5
prev = 1 1 1 2 3

Meaning:

shortest path FROM TO 
                 1  2 = prev[2], 2 = 1, 3
                 1  3 = prev[3], 3 = 1, 3
                 1  4 = prev[ prev[4] ], prev[4], 4 = 1, 2, 4 (fill in right to left)
                 1  5 = prev[ prev[5] ], prev[5], 5 = 1, 3, 5 
                 etc.