summaryrefslogtreecommitdiff
path: root/pathfind.c
diff options
context:
space:
mode:
authormatthijs <matthijs@openttd.org>2005-12-20 00:50:16 +0000
committermatthijs <matthijs@openttd.org>2005-12-20 00:50:16 +0000
commit8f873d4ece827d8f95f8ded0f49b47dbe5942506 (patch)
tree4ebb4a1157127f96b6b0b99947f2020e7c54069e /pathfind.c
parentbb90e51ac50e1b3adae5a5c93e9b84a6ff7ae0df (diff)
downloadopenttd-8f873d4ece827d8f95f8ded0f49b47dbe5942506.tar.xz
(svn r3321) - Fix: A wrong use of the map m5 bits, where a previously calculated "bits" variable should have been used. This resulted in the pathfinder imagining junctions, which negatively affects performance somewhat (Darkvater).
- Fix: [ 1346377 ] Limiting the "depth" of the search tree fixes this assert. Though the above fix seems to fix this bug too, it will only make it less likely to occur. The problem here was the StackedItem::depth field overflowing, which made the pathfinder think it was at the first tile again. Adding an explicit overflow check should fix this.
Diffstat (limited to 'pathfind.c')
-rw-r--r--pathfind.c4
1 files changed, 3 insertions, 1 deletions
diff --git a/pathfind.c b/pathfind.c
index a359a75a4..2895a8026 100644
--- a/pathfind.c
+++ b/pathfind.c
@@ -764,7 +764,7 @@ start_at:
// The tile has no reachable tracks, or
// does the tile contain more than one track?
- if (bits == 0 || KILL_FIRST_BIT(GB(_m[tile].m5, 0, 6)) != 0)
+ if (bits == 0 || KILL_FIRST_BIT(bits) != 0)
break;
// If we reach here, the tile has exactly one track, and this
@@ -859,6 +859,8 @@ start_at:
estimation = DistanceMoo(tile, tpf->dest);
si.depth++;
+ if (si.depth == 0)
+ continue; /* We overflowed our depth. No more searching in this direction. */
si.tile = tile;
do {
si.track = _new_track[FIND_FIRST_BIT(bits)][direction];