Se traba con Path_find

[Outlaw]

Bien ahi por el fix! karma++

En cuanto al mod_path.dll me gustaria saber que algoritmo usa, pq sino es como andar a ciegas eh! ajjaja! De ahi en adelante se puede ver que opciones son mejores o no.

En cuanto al zig zag del personaje me referia al movimiento en diagonal que hace, es decir en 8 direcciones (de ahi que me viene las ganas que lo haga en mas sentidos porque quedaria mejor para ciertos juegos, como por ej el mio  ;) )

[SplinterGU]

prueba con un mapa de 8 bits y dime si hacen esos zigzag, si puedes poner una imagen dibujado a mano el trayecto que dices que hace, te lo agradeceria para entenderlo.

lo que si te puedo asegurar es que la path_find busca el camino mas optimo y corto, si para eso tiene que hacer zigzag entonces los hara.

no tengo idea del algoritmo de la mod_path, pero el codigo no es gigante, puedes ver el fuente siguiendo los enlaces al svn en mi firma.

[Drumpi]

Me uno al karma por el fix (supongo que con el cambio no habrás desechado los mapas de 1 bit ;D).
Yo recuerdo haber usado el ejemplo de Fenix sobre PathFind, y tenía una curiosa tendencia a seguir los ejes de coordenadas: en un mapa en zig zag de pasillos anchos, tendía a pegarse a las paredes más próximas al punto de destino, en lugar de dibujar diagonales de esquina a esquina.
Es un buen banco de pruebas.

[SplinterGU]

Me uno al karma por el fix (supongo que con el cambio no habrás desechado los mapas de 1 bit ;D).
Yo recuerdo haber usado el ejemplo de Fenix sobre PathFind, y tenía una curiosa tendencia a seguir los ejes de coordenadas: en un mapa en zig zag de pasillos anchos, tendía a pegarse a las paredes más próximas al punto de destino, en lugar de dibujar diagonales de esquina a esquina.
Es un buen banco de pruebas.

jajajaja... cuando mencione el fix, dije que solo funcionan los mapas de 8 bits (ahora y siempre fue asi), y que el fix constaba en chequear que el mapa que se pasa en path_find sea de 8bits.

nunca funciono 1bpp, por lo menos, no como 1bpp, sino que se interpreta como 8bpp, usando cada 8 pixels de 1bit compone 1pixel de 8, por eso tampoco funcionaba bien sobre los tamaños de pixels.

y ahora tu das un karma y dices "supongo que con el cambio no habrás desechado los mapas de 1 bit"...

juaz! nunca funcionaron los de 1bpp correctamente.

imagino que lo habras dicho en broma, cierto?

[Outlaw]

lo que si te puedo asegurar es que la path_find busca el camino mas optimo y corto, si para eso tiene que hacer zigzag entonces los hara.

Esto es lo que hace (grafico A)



Lo que busco yo es que haga C o D, es decir curvas, para suavisar el movimiento en 8 direcciones.

[SplinterGU]

si cada cuadrado es 1 pixel, entonces nunca podras hacer lo que queres, hasta ahora las cosas no se mueven de a 1/2 pixel.

por otro lado, veo diferentes los mapas de caminos, en el C y D tenes paredes que en los otros no, por favor, proba con lo mismo.

por otro lado, para que no haga diagonales tenes que setear el parametro correspondiente en la funcion path_find... pero curvas no hara nunca, si podra hacer movimientos solo arriba/abajo, izq/derecha.

[Outlaw]

 :P jajaja debi explicarlo: cada cuadrado es un casillero, y a decir verdad lo saque de el material que puse en el post offtopic "toward a more realistic pathfind", y es solo un deseo que me gustaria ver plasmado algun dia en bennu... :o

[SplinterGU]

el ultimo parametro de path_find son las opciones...

PF_NODIAG es "no diagonales"
PF_REVERSE es "retorno en orden inverso"

ambos son flags de bits, asi que deberias usarlos con | (or a nivel bits)

por ejemplo

PF_NODIAG | PF_REVERSE

saludos.

[SplinterGU]

:P jajaja debi explicarlo: cada cuadrado es un casillero, y a decir verdad lo saque de el material que puse en el post offtopic "toward a more realistic pathfind", y es solo un deseo que me gustaria ver plasmado algun dia en bennu... :o

bueno, yo te comento que bennugd lo hace como en C, como el D nunca, porque busca el camino mas optimo, igual yo te digo, que si yo tengo que recorrer el camino a pie no voy a usar el camino D a menos quiera caminar mas, y para hacer eso, vos podes hacer diferentes niveles de dureza en el mapa de caminos, valores mas altos cuando quieras caminos mas rebuscados o realistas y no tan optimos, y entonces usas el set_wall para limitar a ese valor, con lo que los agujeros que ahora estan en el C, se convertirian en pared.

por favor, hacete esos ejemplos y ese analisis (si tenes ganas, por supuesto) y luego si vemos que es mejor lo implementamos en bennugd.

se necesita, mismo test, en bennu y en el codigo ese, y hacer la grafica de camino obtenido y de tiempo consumido en resolver el camino.

desde ya, muchisimas gracias.

[DCelso]

:D, curiosísimo, pues mira que im ejemplo solo van los mapas de un bit :D.
puedes probar mi ejemplo usando el mapa de 8 bits con el bennu con el fix que tienes?
Porque con el bennu que hay ahora casca de lo lindo queda en un bucle infinito, y si dices que lo único que has hecho es un if para ver si la imagen es de 8 bits supongo que seguirá cascacando de lo lindo el ejemplo.

[SplinterGU]

DCelso, amigo....

no hay ningun fix de logica, solo chequea que el mapa sea de 8 bits, lo podes usar vos.

no digas que casca cuando en realidad esta procesando por mucho tiempo, pero en tu ejemplo no casca por la funcion path_find, casca por la funcion fake path_find que pusiste y porque los mapas para el path no estan hechos bien, el valor 0 (no el rgb 0,0,0) es el camino, vos no lo tenes asi, y por ende falla.

compila tu codigo con -g y correlo con -d y vas a ver claramente donde se queda procesando...

y luego proba esto que adjunto.

[DCelso]

:'(, sorry por no verlo.

[Drumpi]

Me uno al karma por el fix (supongo que con el cambio no habrás desechado los mapas de 1 bit ;D).
Yo recuerdo haber usado el ejemplo de Fenix sobre PathFind, y tenía una curiosa tendencia a seguir los ejes de coordenadas: en un mapa en zig zag de pasillos anchos, tendía a pegarse a las paredes más próximas al punto de destino, en lugar de dibujar diagonales de esquina a esquina.
Es un buen banco de pruebas.

jajajaja... cuando mencione el fix, dije que solo funcionan los mapas de 8 bits (ahora y siempre fue asi), y que el fix constaba en chequear que el mapa que se pasa en path_find sea de 8bits.

nunca funciono 1bpp, por lo menos, no como 1bpp, sino que se interpreta como 8bpp, usando cada 8 pixels de 1bit compone 1pixel de 8, por eso tampoco funcionaba bien sobre los tamaños de pixels.

y ahora tu das un karma y dices "supongo que con el cambio no habrás desechado los mapas de 1 bit"...

juaz! nunca funcionaron los de 1bpp correctamente.

imagino que lo habras dicho en broma, cierto?

Más arriba decían que los mapas de 1 bit funcionaban y que los de 8 no muy bien (no me lo invento, lo dijo DCelso).

Pero vamos, que ayer se me olvidó darte el karma... y estaba pensando en no dártelo, ya que no lo querías, pero como te debo algunos, cualquier excusa me vale ;D