Se traba con Path_find

[Prg]

ahorita que hablas de la funcion de cambio de colores, jeje, no la había visto. disculpa slpinter.

[DCelso]

A ver, yo cuando usé path find, para hacer un ejemplo de uso, vi que el bitmap de entrada tiene que ser de 1 bit de color, es decir, ceros y unos donde cada 1 representa por donde se puede mover y el 0 por donde no se puede mover.

Leete este post
http://forum.bennugd.org/index.php?topic=667.msg9022#msg9022

y mira este ejemplo:
http://forum.bennugd.org/index.php?action=dlattach;topic=667.0;attach=375

En resumen necesitas dos imágenes una que es el fondo original con colores y otra que es en blanco y negro puro y duro de un bit de profundidad de color que es el mapa que pasarás a path_find. Te recomiendo que bajes el ejemplo, mires sus recursos y lo ejecutes y trastees para ver el resultado.

[SplinterGU]

todo bien... yo no me enojo, y si lo hago, me desenojo rapido.

[Outlaw]

DCelso, yo lo use con 8 bit al mapa de path_find y funciono bien, lei en uno de tus posts lo de ponerlo a 1 bit, asi que en un rato lo pruebo tambien. Lo que yo no sabia era que habia que guardarlos en un fpg diferente debido a la profundidad de su color. Gracias igual!

[Prg]

DCelso, yo lo use con 8 bit al mapa de path_find y funciono bien, lei en uno de tus posts lo de ponerlo a 1 bit, asi que en un rato lo pruebo tambien. Lo que yo no sabia era que habia que guardarlos en un fpg diferente debido a la profundidad de su color. Gracias igual!

no tienes que guardarlo en un fpg de 8 bits, solo tienes que asegurarte que el negro si sea 0, eso lo puedes hacer con el codigo de splinter,
[code language="bennu"]fichero1=Load_fpg("elmitoprueba.fpg");

for ( i = 0; i < 1080; i++ )
for ( ii = 0; ii < 810; ii++ )
    if ( map_get_pixel(fichero1, 48, i,ii ) == rgb(0,0,0) )
        map_put_pixel( fichero1, 48, i, ii, 0 );
    end
end
end
save_fpg(fichero1,"elmitoprueba.fpg");[/code]

pero si es más fácil y económico en memoria tenerlo en 8 bits. por supuesto, tenerlo a un bit es mucho más económico...

en el codigo de splinter si te fijas carga el mapa, lo corrije y luego lo vuelve a guardar en el fpg de 32 bits. yo lo hice en 8 bits por enviarte un fpg mas pequeño y porque me fue más fácil editar el gráfico en mi editor preferido. saludos.

todo bien... yo no me enojo, y si lo hago, me desenojo rapido.

gracias  ;)

[DCelso]

umn,  a ver, he probado path_find con fpgs de entrada de 8, 16 y 32 bits y no funciona nada bien, no entiendo como a tí PRG te va, a mí solo me va con un fpg de un bit con una imagen de un bit, además también está el problema de que si le pasas unas coordenadas xfin, yfin que sean de un color blanco tampoco va, así que tuve que corregir el path_find haciendo que siempre selecciones un xfin, yfin de color negro de la siguiente forma

Code Select Expand


function path_find_corrected (file, graph,xini,yini,xfin,yfin )
private
    float f_m;
    float f_b;
begin
    /* Fórmula de la recta entre dos puntos
           y = mx+b
           m es la pendiente
           b es el punto donde corta al eje de ordenadas
       Dados dos puntos se calcula según las siguientes fórmulas
    */
    f_m = (yfin - yini) / (xfin - xini);
    f_b = -f_m * xini +yini;
   
    /*Buscamos el punto más cercano al seleccionado al que podemos ir desde donde estamos.*/
    while (map_get_pixel(file,graph,xfin,yfin)!=0)
        if (xini < xfin)
            xfin--;
        else
            xfin++;
        end
        yfin = f_m * xfin + f_b;
    end
   
    return path_find(file,graph,xini,yini,xfin,yfin,1);
end


El truco de splinter de convertir el map antes de meterlo a path_find puede que funcione si conviertes la imagen a un map de 1 bit con new_map(x,y,1) e insertas ceros y unos.
Además, si no recuerdo mal, los fpg en memoria en bennu pueden tener maps de distintas densidades de color, pero el .fpg en archivo no, es una limitación, osea que si grabas un fpg de memoria de bennu con maps de distintas densidades de color puede que el fpg resultante no sea válido o almenos el que querías obtener.

[SplinterGU]

DCelso, el "truco" que puse lo probe en 16 bits...

path_find funciona con cualquier imagen de cualquier profundidad, hay que saber que los caminos deben ser 0, o setear con set_wall el color de la pared, y entonces colores menores al seteado son camino, mayores son pared.

[DCelso]

DCelso, el "truco" que puse lo probe en 16 bits...

path_find funciona con cualquier imagen de cualquier profundidad, hay que saber que los caminos deben ser 0, o setear con set_wall el color de la pared, y entonces colores menores al seteado son camino, mayores son pared.

Ostras, pues no entiendo nada, en mi ejemplo uso un bitmap de 1 bit de densidad donde el 1 representa camino y el 0 pared, me extraña que en densidades superiores funcione al revés :?.
Ya me pica la curiosidad, voy a hacer ejemplos en todas las densidades  :D.

[SplinterGU]

ja, debe ser por la comparacion, que no es por = sino por < o > no recuerdo.

[DCelso]

:(, sorry splinter, tienes razón en densidad un bit el 0 representa camino y el 1 pared. Me confundí con el color del pixel, resulta que tengo en la posición 0 de la paleta el blanco y en la posición 1 el negro y esto me llevó a la confusión :)

[DCelso]

Pues a mi solo me va con la imagen de un bit, adjunto ejemplo.
En él va el mismo mapa en los distintos formatos png que soporta el propio formato png. (el png de 24 bits, en teoría es mas o menos equivalente al modo 16 bits de bennu)
para cambiar de uno a otro basta con cambiar las // del principio

Code Select Expand


//    id_map_path = load_png ("map_path1bit.png");
//    id_map_path = load_png ("map_path1bitbis.png");
    id_map_path = load_png ("map_path8bits.png");
//    id_map_path = load_png ("map_path24bits.png");
//    id_map_path = load_png ("map_path32bits.png");

Resulta que con 8, 24, y 32 path_find casca y se queda calculando infinitamente.

[Outlaw]

Bueno, tal vez si alguien sabe programar en c, dado que yo a lo maximo que llegue en la universidad es a pascal  :P :P :P :P :P, podria tal vez aportar con un mod_path mejorado. Por cierto mis observaciones con respecto al path_find bennusiano es que el personaje se mueve en zig zag, es decir no queda muy realista, al contrario del que esta hecho en G***X que a mi parecer anda mas "lindo" pero que a nivel sintaxis es mas confuso. No estoy haciendo apologia de nada, solo comparo dos lenguajes div-like, y me gustaria ver en bennu algo mejor, si se pudiera, y si tengo que aprender c lo hare...es dificil?

[Drumpi]

Ya se lleva comentando AÑOS el cambiar el path_find (desde Fenix), porque busca caminos un poco "raros", pero no es una prioridad, hay otras cosas que requieren de más atención, y también se pueden usar algoritmos con código Bennu.
En principio existen muchos algoritmos disponibles, recuerdo haber oido cientos de veces el A*, y seguro que hay una implementación ya hecha en C/C++, y sería cuestión de hacer unas modificaciones mínimas para que se integrase en Bennu, al menos en teoría. Y seguramente haya mejores algoritmos, pero eso es cosa de los informáticos, yo soy teleco (lo mío es modificar el sonido, en cuanto sepa llevarlos al altavoz partiendo de un wav... :D).

[SplinterGU]

:(, sorry splinter, tienes razón en densidad un bit el 0 representa camino y el 1 pared. Me confundí con el color del pixel, resulta que tengo en la posición 0 de la paleta el blanco y en la posición 1 el negro y esto me llevó a la confusión :)

todo bien, la verdad que me dejo medio preocupado ese comportamiento diferente, que al final no fue.

Pues a mi solo me va con la imagen de un bit, adjunto ejemplo.
En él va el mismo mapa en los distintos formatos png que soporta el propio formato png. (el png de 24 bits, en teoría es mas o menos equivalente al modo 16 bits de bennu)
para cambiar de uno a otro basta con cambiar las // del principio

Code Select Expand


//    id_map_path = load_png ("map_path1bit.png");
//    id_map_path = load_png ("map_path1bitbis.png");
   id_map_path = load_png ("map_path8bits.png");
//    id_map_path = load_png ("map_path24bits.png");
//    id_map_path = load_png ("map_path32bits.png");

Resulta que con 8, 24, y 32 path_find casca y se queda calculando infinitamente.

24 bits no esta soportado por bennugd, aunque hay quien dice que funciona, yo estoy seguro que si funciona no funciona al 100%.

con respecto al path_find, ya veo, cometi un grave error, las funciones de path, solo trabajan con mapas de 8 bits, no dan error con otros mapas, pero no funcionan, ahi esta el problema de todos los comportamientos erraticos, y supongo que del zigzag que le mencione mas adelante a Outlaw.

Bueno, tal vez si alguien sabe programar en c, dado que yo a lo maximo que llegue en la universidad es a pascal  :P :P :P :P :P, podria tal vez aportar con un mod_path mejorado. Por cierto mis observaciones con respecto al path_find bennusiano es que el personaje se mueve en zig zag, es decir no queda muy realista, al contrario del que esta hecho en G***X que a mi parecer anda mas "lindo" pero que a nivel sintaxis es mas confuso. No estoy haciendo apologia de nada, solo comparo dos lenguajes div-like, y me gustaria ver en bennu algo mejor, si se pudiera, y si tengo que aprender c lo hare...es dificil?

el lenguaje es lo de menos, si te sentis capacitado para hacer un algoritmo de busqueda de caminos mejor y mas optimizado, hacelo en pseudocodigo o en el lenguaje que quieras, yo luego lo paso a C.

es raro lo que mencionas de que va en zigzag, a mi no me paso nunca eso.

[SplinterGU]

fixeado, ahora si el mapa no es de 8 bits falla la operacion path_find retornando 0.

entonces, resumiendo, los mapas de path_find nos permiten trabajar con 256 valores posibles, obviamente 0 o los valores menores al especificado por set_wall son los que representan el camino.