What was causing the magic jump?
I wasn't checking to make certain that we were only expanding upon points found in our previous pass. ( IF Array(x, y) = pass THEN )
I'm pretty happy with the lessons I taught myself with this one, and here's one you might like to take advantage of with your pathfinding algorithms Bplus:
Let's take a normal 10x10 grid and work some pathfinding on it as we have on the past. Imagine the starting point is in the center, and we want to know how far it is to reach any other point.
PASS 1:
0000000000
0000000000
0000000000
0000000000
0000100000
0000000000
0000000000
0000000000
0000000000
0000000000
PASS 2:
0000000000
0000000000
0000000000
0000200000
0002120000
0000200000
0000000000
0000000000
0000000000
0000000000
PASS 3:
0000000000
0000000000
0000300000
0003230000
0032123000
0003230000
0000300000
0000000000
0000000000
0000000000
With each process, we've been checking the whole array and incrementing the surrounding points if they match our current pass...
My EUREKA moment, which really changes the performance levels of this type of work, came with the complexity of using PAINT with pathfinding on the whole screen. That's a TON of pixels to check each pass...
Instead, what I'm doing here is this leap of logic:
PASS 1
1
PASS 2
020
212
020
PASS 3
00300
03230
32123
03230
00300
Here, I set MinX to 1 less, MaxX to 1 more, MinY to 1 less, MaxY to 1 more each pass. I don't check the whole array each time around; I only check to the points which are relevant and possible on this given pass.
On Pass 3, why do I need to check point (0,0), if my hero is starting at point(10,10)??
Once I came to this little revelation in logic, I could ignore checking a large portion of my screen and times improved dramatically, and I see no reason why this same logic wouldn't apply to the way we've been doing pathfinding with 2D arrays either.
Only check the area you need to check; no more, no less.
******************
I think we can also eliminate checking a whole swath of points each pass, if we ONLY bother to check the outer rows like this, but I haven't implemented it yet:
For example, take a look at PASS 3:
PASS 3
00300
03230
32123
03230
00300
I don't see any reason why we couldn't exclude the following on our next pass:
00300
0
XXX0
3
XXX3
0
XXX0
00300
There should be some simple formula we could plug in to say IF X > this point AND X < that point and Y > this point and Y < that point THEN we don't need to check these values... Once that's sorted out and plugged in, the larger the pathfinding gets, the more of the results we can exclude from checking over and over and over again...
I imagine it'd make as large of a leap in performance as the first EUREKA moment of only checking MinX to MaxX and MinY to MaxY did. I just haven't sorted out the math needed for the exclusion yet, but my mind is visualizing the concept fairly nicely at least. ;)
EDIT:
(This might be as simple as a (PASS \ 2 -1 ) type exception. I need more coffee and a lot of testing with the concept before I'd swear to it, but I'm thinking it'll fit our pattern for segments we can safely exclude.)