Skip to content
This repository has been archived by the owner on Mar 1, 2019. It is now read-only.

Allow way to disable diagonal moves #2

Open
tkram01 opened this issue Aug 2, 2016 · 6 comments
Open

Allow way to disable diagonal moves #2

tkram01 opened this issue Aug 2, 2016 · 6 comments
Assignees

Comments

@tkram01
Copy link

tkram01 commented Aug 2, 2016

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

@fgenesis fgenesis self-assigned this Aug 31, 2016
@RallyTronics
Copy link

I too would like to see this feature.

@gpascualg
Copy link

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!

@fgenesis
Copy link
Owner

fgenesis commented May 19, 2017

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.

@gpascualg
Copy link

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?

@fgenesis
Copy link
Owner

fgenesis commented May 19, 2017

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.

@gpascualg
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants