Brad Allred

the profiler shows we are spending quite a bit of time in `Actor::NewPath` and half of that time is spent in `Map::NormalizeDeltas`.

Things still hitch, but those optimizations gave me ~10% improvement (hitches are 10% shorter). We could squeeze another ~14% if we could eliminate ConvertCoordToTile from the pathfinding by having a...

I'm not sure it is related, but this looks like a bug to me: https://github.com/gemrb/gemrb/blob/ab71947f35bdea7e4c862bace1b9779ac6847a58/gemrb/core/Map.cpp#L2575-L2594 the `Point` passed into `GetBlockedInRadius` is already a "navmap" coordinate, but these multiplies are treating...

the `* 16` and `* 12`: ``` PathMapFlags retBotRight = GetBlocked(Point(p.x + i * 16, p.y + j * 12)); PathMapFlags retTopRight = GetBlocked(Point(p.x + i * 16, p.y -...

Ah, so the multiples are converting `i` into normal space to add to a normal space coord. gotcha.

ok, things seem much better to me. We can go a bit further without changing the algorithm in a couple of areas too.

It looks like our "bumping" implementation forces the bumped actor to recalculate a path. I imagine this happens quite a bit in narrow corridors. I may be being naïve, but...

Repeated bumping and complete repathing is what appears to be happening currently. The difference is calculating a few nodes of a a new path and prepending it instead of completely...

a subclass would still allow you to pass the derived to functions asking for the "base". I think we need two distinct types.

I wasn't aware we needed any functionality out of the "tile point" other than comparisons. But yes, that would work fine.