fgenesis / tinypile Goto Github PK

I've been using your library for pathfinding in a 2D simulation for quite some time. I'm working on implementing the v2 version but encountered a silly issue where no path is found due to obstructed start position.

This makes sense because consider that a unit starts off at position 5,5. When the algorithm tries to find a path, the position 5,5 would be occupied and instantly return NO_PATH found

This could potentially be remedied by a skip paramter?
By commenting out the following lines, the code works as expected (or atleast the start position part of the if statement)

Line 1303-1305

            //if(!grid(start.x, start.y) || !grid(end.x, end.y))
            //    return JPS_NO_PATH;

Hello!
First of all, thank you for the awesome code piece! :-)

But I would like to pinpoint an issue with JPS code:
there is a memory leak because you dont call destructor for elements inside PodVec,
but you use it for complex type with PodVec Buckets; (PodVec of PodVec's)
A simple fix is to add destructor to NodeMap:
"
~NodeMap() {
dealloc();
}
"
Proper fix would include calling destructor for PodVec elements.

Best,
Pavel

forget some thing

Hi, I'm excited to see that you created JPS v2 which is even faster than previous version. Actually I used the skip argument as my grid is very dense. Would like to have it back. Let me know if that's possibile.

Hey! Great JPL library!

I'm using it and it's great so far, but I'm missing the option to remove diagonal movement (for my use-case, this can lead to wall jumping)

Can you give me pointers to what would need to be changed and how you see the runtime param?

Thanks!

Hi,

I'm sure I'm doing something wrong here, but I'm stumped as to what

In my game, I replaced the normal A* pathfinder with your JPS version, and half the time the paths generated are perfect, but the other half of the time they're crazy. I started adding debugging and checks everywhere I could think of, and I noticed that operator() gets called with x and y being UINT_MAX (or -1 as a signed integer)

Is this expected behavior?

(Note the "< 9" part is because this was originally used in a variable cost pathfinding solution, but I just put in "< 9" for use with yours)

`inline bool teMapModule::operator()(unsigned int x, unsigned int y) const
{
bool canwalk = ((x < 512) && (y < 512) && (x >= 0) && (y >= 0));

if (canwalk)
{
	canwalk = pathingMap[y*512 + x] < 9;
}
return canwalk;

}

bool teMapModule::findJPSPath(int startingX, int startingY, int goalX, int goalY, std::vector<xzCoordsStruct>& resultingPath)
{

JPS_Path_Results.clear();
JPS::Position start{startingX,startingY};
JPS::Position goal{goalX,goalY};  
bool pathFound = JPS_Searcher->findPath(JPS_Path_Results, start,goal, 1); 

if(pathFound)
{
	for (JPS::PathVector::iterator it = JPS_Path_Results.begin(); it != JPS_Path_Results.end(); ++it)
	{
		resultingPath.push_back({ it->x ,it->y });
	}
}
return pathFound;

}`

Can you see any obvious errors or have any idea why I'm getting crazy paths half the time?

Thanks for any suggestions you might have!

thank you very much. This is the best implementation I have seen.

When the scene has few obstacles (and cannot be reached directly), the execution efficiency will become worse.
I found that when I limit steps in Jump, performance will get better.
Can this be done？

It would be great if we could get the closest path to the destination, even if the direct path doesn't exist, as this is what often desired. For example in rts games if you click inside some area which is not possible to enter, but your units go to the closest point you would like to go.

It would be cool to have copies of both jps.h & minihttp.h (as single-header lib) in this repo as well :D
Looking forward to your next, upcoming libs :D

//     { -1, -1 },  { 0, -1 }, { 1, -1 } //0 1 2  ideal?
//     { -1,  0 },             { 1,  0 } //3   4
//     { -1,  1 },  { 0,  1 }, { 1,  1 } //5 6 7

//     {  0, -1 },  { 1, -1 }, { 1,  0 } //0 1 2   but this is real
//     { -1, -1 },             { 1,  1 } //7 8 3
//     {- 1,  0 },  {-1,  1 }, { 0,  1 } //6 5 4

What should I do?
How can I change it for work ??

inline void _fixIdx(SizeT i) { _percolateDown(i); _percolateUp(i); }

_percolateDown already calls _percolateUp, so the standalone call seems redundant.