Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualOlof Hedman

Posted 22 October 2012 - 08:22 AM

Before you start to multithread, make sure your algoritms are working properly and efficiently with extensive tests.

Then reduce the times it is run, why would it be needed to run at a fixed timestep?
Only times the path changes is if the goal changes or the terrain changes.

Then you can simplify the terrain to have less nodes to search.

DFS is not "supposed to be faster", only in very special cases.

You probably want A*, specially if you have an easy way to estimate distance left to goal, dijkstra's is useful if you can't.

#5Olof Hedman

Posted 22 October 2012 - 08:17 AM

Before you start to multithread, make sure your algoritms are working properly and efficiently with extensive tests.

Then reduce the times it is run, why would it be needed to run at a fixed timestep?
Only times the path changes is if the goal changes or the terrain changes.

Then you can simplify the terrain to have less nodes to search.

DFS is not "supposed to be faster", only in very special cases.
DFS more of a learning example of an extremely simple algorithm, that should very seldom be used for real problem solving.

You probably want A*, specially if you have an easy way to estimate distance left to goal, dijkstra's is useful if you can't.

#4Olof Hedman

Posted 22 October 2012 - 08:16 AM

Before you start to multithread, make sure your algoritms are working properly and efficiently with extensive tests.

Then reduce the times it is run, why would it be needed to run at a fixed timestep?
Only times the path changes is if the goal changes or the terrain changes.

Then you can simplify the terrain to have less nodes to search.

DFS is not "supposed to be faster", only in very special cases.
DFS more of a learning example of an extremely simple algorithm, that should very seldom be used for real problem solving.

You probably want A*, specially if you have an easy way to estimate distance left to goal, djikstra's is useful if you can't.

#3Olof Hedman

Posted 22 October 2012 - 08:14 AM

Before you start to multithread, make sure your algoritms are working properly with extensive tests.

Then reduce the times it is run, why would it be needed to run at a fixed timestep?
Only times the path changes is if the goal changes or the terrain changes.

Then you can simplify the terrain to have less nodes to search.

DFS is not "supposed to be faster", only in very special cases.
DFS more of a learning example of an extremely simple algorithm, that should very seldom be used for real problem solving.

You probably want A*, specially if you have an easy way to estimate distance left to goal, djikstra's is useful if you can't.

#2Olof Hedman

Posted 22 October 2012 - 08:08 AM

Before you start to multithread, make sure your algoritms are working properly with extensive tests.

Then reduce the times it is run, why would it be needed to run at a fixed timestep?
Only times the path changes is if the goal changes or the terrain changes.

Then you can simplify the terrain to have less nodes to search.

DFS is not "supposed to be faster", only in very special cases.

#1Olof Hedman

Posted 22 October 2012 - 08:07 AM

Before you start to multithread, make sure your algoritms are working properly with extensive tests.

Then reduce the times it is run, why would it be needed to run at a fixed timestep?
Only times the path changes is if the goal changes or the terrain changes.

Then you can simplify the terrain to have less nodes to search.

DFS is not "supposed to be faster", only in very special cases, I don't know where you got that from.

PARTNERS