fgenesis / jps

Jump Point Search, public domain, single .h -- OBSOLETE! See tinypile repo for a better version.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Allow way to disable diagonal moves

tkram01 opened this issue · comments

It would be nice to be able to restrict moves to only up/down/left/right

I too would like to see this feature.

Any updates on this? I am quite interested in disable diagonal movement. I haven't got time enough to go through all the code yet, but I cold do so if you give me some basic lines.

Thank you!

Ah yes, sorry, i forgot to answer. I had a look at this some time ago and couldn't find a way to easily disable diagonals without breaking the algorithm; it kinda depends on diagonals to find jump points.
That said, as a workaround you could just postprocess calculated paths and replace diagonal moves by horizontal and vertical moves. Note that you need to take care not to introduce map collisions that way (ie. accidentally walk through walls).

I might add this as an option but i'm super busy these days... If anyone is willing to make a PR, please do.

That's what I was thinking, as I saw it used euclidean distances to calculate diagonals.

Sure, I'll make a PR with some postprocessing while building the path in case dx != 0 && dy != 0. As you said, I'll simply separate it into two steps and check whereas it is blocked or not, and in case it is i'll just add the other way around.

Should I add a test? If so, are you using any library?

I don't use "tests" as in unit tests. The test code attached is mainly for benchmarking and should blow up/assert fail when something isn't right. That said, with no diagonals it'll probably bail because the expected path lenghts were calculated with diagonals, iirc (i didn't make this data set). Not sure right now, but you'll find out :)

EDIT: Please don't pull in any libs, even for "tests". The whole point of this lib is to be dependency-free, and i regret that it needs the STL. Didn't get around (yet) to kick out the STL parts to make it completely self-contained.

EDIT2: The A* only variant (look for the define) can work without diagonals, so that could be used as a verification criterion. A* is optimal, and so is the JPS optimization. If it's worse than A*, something is wrong.

I've just added basic postprocessing, I don't have time for those tests now (I didn't see the edits until now).

Any particular reason why you'd like to move away from STL? Performance? If so the structure used could be also templated and it would be up to the user.