Duda sobre el funcionamiento de path find

[SplinterGU]

no sirve, porque no podes calcular el tramo correcto, en base a que datos y caminos calculas el primer destino parcial? no tiene sentido, es ridiculo, porque para saber el primer destino parcial, necesitas saber el camino mas optimo al destino final, cosa que no podes hacer.

para mi, eso que dices no tiene sentido... o no te estoy entendiendo lo que dices.

[Abram]

Lo pego por aqui, dadle las gracias al gran Osk ^^

path_wall(VALOR)

Esta función, definida en el módulo "mod_path", modifica el valor de "pared" empleado por la función path_find().
Este valor de pared será un número que indica la posición mínima del color dentro de la paleta (perteneciente al
gráfico de 8 bits que representa el camino) a partir del cual un punto del gráfico es intraspasable. Es decir, si por
ejemplo el parámetro vale 5, todos los píxeles del gráfico del camino pintados con los colores que ocupan las
posiciones 0,1,2,3 y 4 de la paleta serán traspasables, y el resto no.
El orden de los colores traspasables influye en la facilidad de "traspase". En el ejemplo anterior, el color 1 es el más
fácil de traspasar porque no ofrece apenas resistencia para los móviles; en cambio, el color 4 será más dificultoso, y en
principio no será la opción escogida para crear un camino, a no ser que no haya otra opción. Es decir, la posición de
los colores en la paleta se interpreta como el "coste" de movimiento de un punto dado, hasta llegar a la posición
marcada por el parámetro, la cual marca la barrera infranqueable. Más concretamente: cada posición en la paleta
requiere el doble de pasos que la anterior, hasta llegar a la posición infranqueable (1ª posición, 1 paso necesario; 2ª
posición, 2 pasos necesarios,etc)
Evidentemente, esta función se ha de invocar siempre antes de path_find(), ya que ésta utiliza el valor previamente
definido por path_wall() para calcular el camino más adecuado. Si no se utiliza esta función, por defecto, el valor de
la "pared" que utilizará path_find() está a 1, lo que significa que sólo los puntos a 0 serán traspasables por el camino
a resolver. Por otro lado, si a la función se le pasara como parámetro un valor menor a 0, éste no será modificado.

[Danielo515]

no sirve, porque no podes calcular el tramo correcto, en base a que datos y caminos calculas el primer destino parcial? no tiene sentido, es ridiculo, porque para saber el primer destino parcial, necesitas saber el camino mas optimo al destino final, cosa que no podes hacer.

para mi, eso que dices no tiene sentido... o no te estoy entendiendo lo que dices.

A ver, esta técnica es fatal, una mierda como una casa, pero vale.

Si yo se que va a haber camino, pues voy acercando el origen, hasta que me retorne un camino válido, luego entonces pido un camino desde el primer origen hasta el origen que yo mismo "acerqué". Obviamente entre cada llamada tienes que guardar los puntos en algún array.

Ahora, ¿Que me dices de lo que te he preguntado antes sobre los mapas escalados? ¿Que hago con las cosas que trabajan a nivel de pixel? Me quedaría un mapa desproporcionado.

[Drumpi]

Los mapas de búsqueda de caminos siguen el mismo principio que los mapas de durezas, no os compliqueis la vida: el mapa puede ser la mitad de grande, por lo que cada punto del mapa de caminos representan 2x2 pixels del mapa normal. No avances el personaje en el mapa de caminos: muévelo en el mapa normal y usas el mapa de caminos para consultar las "durezas", dividiendo la posición entre 2, no se si me explico.

PD: casi ningún juego requiere precisión a nivel de pixel, por lo que puedes escalar a la mitad, a un tercio, a la cuarta parte...

[Danielo515]

Ya drumpi, como tu bien dices, para "consultar" vale. Pero, luego para ir recorriendo el camino.. . ¿basta con poner x=punto[0][0]*2 Y=punto[0][1]*2 y así ir recorriendolos?

En efecto en pocos juegos se requiere precisión a nivel de pixel, pero cuando los entornos son deformables, y tienes procesos que añaden un pixel aquí o un pixel allá, ¿que haces? pones un pixel en el mapa de durezas y dos en el real? mm, ahora que lo digo podría funcionar...
¿tu que opinas?

[SplinterGU]

es como ha explicado drumpi.

[Danielo515]

Pues debo haberlo hecho mal o no he entendido bien lo que me ha querido decir drumpi, porque he adaptado (como he podido) mi código a las consultas al mapa a dividirlas por 2 y su correspondiente realización en el mapa "a la vista" multiplicarlas por 2 y el resultado obtenido es, sencillamente, horrible, horripilante, no hacen más que traspasar paredes, eso sí, se mueven más rápido, pero la fidelidad a lo que se muestra dista mucho de ser satisfactoria.

¿Lo estaré haciendo mal?

[SplinterGU]

no se, pone el codigo y lo vemos.

aunque ahora no tengo tiempo.

[Danielo515]

Vale, ya he retocado todo, y ya no atraviesa las paredes, parece funcionar perfectamente, pero todo tiene un aspecto mucho más "tosco"

Las montañas de tierra que antes dibujaba a nivel de pixel, ahora son cuadradotas, debido a que cada pixel es el doble, los agujeros ya no son tan sueves, sino que tienen dientes de sierra y el movimiento que antes era muy fluido queda muy robótico.

Splinter, como puedo modificar la mod_path? o a ver si se nos ocurre alguna otra solución elegante... y eficiente.

[Danielo515]

EL codigo lo pongo en el hilo de mi proyecto, que no quiero saturar los servidores  ;D

[SplinterGU]

estoy viendo y no veo el limite en el codigo, voy a tener que probarlo y ver como es que esta limitando, si es que lo esta haciendo o hay algun otro error.

[Danielo515]

estoy viendo y no veo el limite en el codigo, voy a tener que probarlo y ver como es que esta limitando, si es que lo esta haciendo o hay algun otro error.

estoy seguro de que lo haras de la mejor de las maneras posibles.

Grande splinter,muy grande

[Drumpi]

Hombre, si te da posiciones en el path-find, lógicamente en el "mundo real" las tendrás que multiplicar por 2, y no debería darte movimientos demasiado robóticos comparados con un mapa de tamaño 1:1.
Es más, generalmente estos algoritmos se usan con tiles, y estos pueden ser de 8x8, 16x16, 32x32 e incluso más gordos. Puedes suavizar el movimiento moviéndote hacia la posición 3 puntos más adelante, haciendo media de los siguientes 3 puntos, o incluso usar near_angle.
Lo suyo es que busques los puntos que actúen como vértices, donde se cambie de dirección, y te dirijas hacia ellos, olvidándote de los intermedios (aunque puede dar problemas con pasillos estrechos).

[Danielo515]

Hombre drumpi, eso que dices tiene sentido, pero de momento "creo" que he encontrado una solución.

Esto no va de tiles, ni nada parecido, así que de momento prefiero mantener la precisión al pixel aunque tenga que hacer unos cuantos ajustes, pero tu idea no creas que cae en saco roto, la rescataré para otros  proyectos, aunque tu no lo sepas he aprendido bastante de ti.

Splinter, por cierto, aún ando intrigado con el límite real del path find. Creía  que lo había encontrado en 600, pero hoy el programa me petó porque encontró un camino de 826, y yo tenía un array contando con que nunca pasarían de 800.

Ah,  y una duda que estoy seguro que ya has resuelto más de una vez, pero en fin, Verdad que es imposible que dos procesos intenten acceder a la vez al mismo array? Lo digo porque creo que había alguna implementación de semáforos o jerarquías y cada proceso se ejecutaba por un orden y nunca dos procesos a la vez.

Un saludo!

[SplinterGU]

los procesos bennugd nunca se ejecutan 2 a la vez.

con respecto a usar un mapa 2x2 cada pixel, no significa que luego te tengas que mover de 2 en 2, puedes moverte de 1 en 1, solo tienes que calcular la recta entre cada 1 de esos pasos que son de 2x2, por ejemplo, si tengo un path find que comienza en 0,0 y la siguiente es 2,2 entonces puedo moverme de 0,0 a 1,1 y luego a 2,2.

o hacer primero un mapa de pixels 2x2 y luego calcular el path_find entre cada segmento, por ejemplo, desde 0,0 a 2,2 y aca con un mapa si de pixels, aunque no lo creo necesario.