Cool, thanks for the reply. 
From what I understand, A* and Djikstra are variants on a similar algorithm, so maybe I'm not so far off. I completely understand that this engine is the result of TONS of hard work and that you may not want to divulge your methods or "trade secrets", but in the case that you don't mind, could you elaborate more on the general methodology behind your pathfinding routines? I am genuinely curious, because the only real examples I can find apply only to tile-based games, and this is much different from a game where a character can occupy any pixel on the screen. Are you using a line-of-sight type method? Or do you treat each pixel on the screen as a tile in a grid? Are you pre-calculating paths or movement nodes when the room loads or does it all happen at runtime?
My method seems to work okay so far, but involves strategically placing waypoints beforehand, and could perform slowly on rooms with more than a dozen nodes (which must be placed at the corners of obstacles). It was very slow until I started precalculating line-of-sight between existing nodes when the room loads... but since the character's current position and target position are usually not _exactly_ at the X/Y of a movement node, it has to calculate those at runtime. It should be fine in my application, but I know there is a better way....
I pulled up KQ6 the other day, and it SEEMED like there was a slight pause when I tried to complicate the pathfinding engine by putting a lot of obstacles between the player sprite and the destination... maybe I'm imagining things though.
Again, my utmost respect if you'd rather not talk about your methods. I will probably be hanging out here a lot, and am really impressed by the quality of content and community.
From what I understand, A* and Djikstra are variants on a similar algorithm, so maybe I'm not so far off. I completely understand that this engine is the result of TONS of hard work and that you may not want to divulge your methods or "trade secrets", but in the case that you don't mind, could you elaborate more on the general methodology behind your pathfinding routines? I am genuinely curious, because the only real examples I can find apply only to tile-based games, and this is much different from a game where a character can occupy any pixel on the screen. Are you using a line-of-sight type method? Or do you treat each pixel on the screen as a tile in a grid? Are you pre-calculating paths or movement nodes when the room loads or does it all happen at runtime?
My method seems to work okay so far, but involves strategically placing waypoints beforehand, and could perform slowly on rooms with more than a dozen nodes (which must be placed at the corners of obstacles). It was very slow until I started precalculating line-of-sight between existing nodes when the room loads... but since the character's current position and target position are usually not _exactly_ at the X/Y of a movement node, it has to calculate those at runtime. It should be fine in my application, but I know there is a better way....
I pulled up KQ6 the other day, and it SEEMED like there was a slight pause when I tried to complicate the pathfinding engine by putting a lot of obstacles between the player sprite and the destination... maybe I'm imagining things though.
Again, my utmost respect if you'd rather not talk about your methods.
I will probably be hanging out here a lot, and am really impressed by the quality of content and community.