Hola a todos! Ya he leido varios posts del path_find y su uso, hasta de algunos errores comunes que pueden aparecer, el asunto es que a mi se me congela el juego y me tira un error de windows "bgdi ha detectado un problema y debe cerrarse", puede ser ocasionado por memoria, porque a nivel de sintaxis esta bien, el asunto tambien es que corrobore la cosa usando primero un mapa de caminos de 1bit y otro de 8 bits y con los dos me paso lo mismo (zona transitable color 0 -negro- y obstaculos color 255,255,255 -blanco- ). Este es el pedazo de codigo donde esta implementada la funcion:
(Dentro del proceso "enemigo_dispara" en la linea 323)
If ((get_dist(id_prota) < 200 and angle + 45000 <= ang_hasta_prota) or (get_dist(id_prota) < 200 and angle - 45000 <= ang_hasta_prota)) // ahora si OK!! lo ve!!
Repeat
If (usado == 0)
Lo_ve=Que_ve(x,y);
usado=1;
End
If (Lo_ve == true)
velocidad=0;
angle=get_angle(id_prota);
If (get_dist(id_prota) < 300)
If (disparado == false)
disp_enem(x,y,angle);
disparado=true;
End
End
If (disparado == true)
tiempo+=1;
End
If (tiempo == 30)
disparado=false;
tiempo=0;
End
While (get_dist(id_prota) > 200) <<<<<<<<<<<<<<<<<<<<<<<<<< BUCLE DEL ERROR
velocidad=velocidad_original;
hay_camino=path_find(fichero1,48,x,y,id_prota.x,id_prota.y,0);
If (hay_camino == 1)
WHILE (path_getxy(&a, &b))
x =a * 2; // le puse 2 pq el mapa de caminos esta a la mitad del mapa donde camina el prota
y =b * 2;
frame;
END
//xadvance(get_angle(id_prota),velocidad);
//advance(velocidad);
End
Frame;
End
If (collision(type disparo) or collision(type golpe))
exp+=10;
return;
End
End
Frame; // este frame va porq como entra en un bucle del bucle pierde al frame de afuera
Until (get_dist(id_prota) > 400)
End
Este es el codigo de error:
AppName: bgdi.exe AppVer: 1.0.0.1 ModName: mod_path.dll
ModVer: 0.0.0.0 Offset: 000011ee
Adjunto el programa completo para que vean como funciona. Saludos y gracias! :)
Edito: no me da el tamaño de attachment para subir el fpg, pesa 6 mb
Esto sucede porque le pides a la funcion que vaya a un lugar que no se puede debido a que el punto destino está sobre el color blanco, al menos amí me sucedía por esta razón.
Aquí tengo un ejemplo de uso
http://forum.bennugd.org/index.php?topic=392.0
puedes evitar el problema verificando el color antes de llamar la funcion path_find, ejemplo:
if (map_get_pixel(fichero,gráfico,x1/escala,y1/escala)==0)
pd: El error no sucede si no se puede acceder pero el destino está en el color negro
Gracias Prg por responder!
Agregue lo que me dijiste a la condicion:
While (get_dist(id_prota) > 200)
velocidad=velocidad_original;
hay_camino=path_find(fichero1,48,x/2,y/2,id_prota.x/2,id_prota.y/2,0);
If (hay_camino == 1 and MAP_GET_PIXEL(fichero1,48,x/2,y/2) == 0) // MAP_GET_PIXEL AGREGADO
WHILE (path_getxy(&path_x, &path_y))
x =path_x * 2; // le puse 2 pq el mapa de caminos esta a la mitad del mapa donde camina el prota
y =path_y * 2;
frame;
END
End
Frame;
End
Pero sigue pasando lo mismo, es mas, he comprobado que el destino este en el color negro (color=0)...Asi que no se que puede ser...
Por cierto, ya habia utilizado anteriormente la funcion que hiciste vos, me parecio genial! pero no andaba y queria irme a lo basico para entender este path_find...saludos!
Quote from: Outlaw on September 29, 2010, 03:19:32 AM
Gracias Prg por responder!
Agregue lo que me dijiste a la condicion:
While (get_dist(id_prota) > 200)
velocidad=velocidad_original;
hay_camino=path_find(fichero1,48,x/2,y/2,id_prota.x/2,id_prota.y/2,0);
If (hay_camino == 1 and MAP_GET_PIXEL(fichero1,48,x/2,y/2) == 0) // MAP_GET_PIXEL AGREGADO
WHILE (path_getxy(&path_x, &path_y))
x =path_x * 2; // le puse 2 pq el mapa de caminos esta a la mitad del mapa donde camina el prota
y =path_y * 2;
frame;
END
End
Frame;
End
Pero sigue pasando lo mismo, es mas, he comprobado que el destino este en el color negro (color=0)...Asi que no se que puede ser...
Por cierto, ya habia utilizado anteriormente la funcion que hiciste vos, me parecio genial! pero no andaba y queria irme a lo basico para entender este path_find...saludos!
ahm. lo que pasa es que el mapgetpixel va acá:
[code language="bennu"]
While (get_dist(id_prota) > 200)
velocidad=velocidad_original;
if (MAP_GET_PIXEL(fichero1,48,x/2,y/2) == 0 and MAP_GET_PIXEL(fichero1,48,id_prota.x/2,id_prota.y/2) == 0)
hay_camino=path_find(fichero1,48,x/2,y/2,id_prota.x/2,id_prota.y/2,0);
If (hay_camino == 1) // MAP_GET_PIXEL AGREGADO
WHILE (path_getxy(&path_x, &path_y))
x =path_x * 2; // le puse 2 pq el mapa de caminos esta a la mitad del mapa donde camina el prota
y =path_y * 2;
frame;
END
End
end
Frame;
End
[/code]
Prg gracias por tu paciencia! Ya se que paresco tonto pero bue! jajaja! El tema es que hice todo como e dijiste vos, comprendiendo todo. Cosa curiosa que pasa es que cuando cambio el color 0, a color_librepaso=rgb(0,0,0) se tilda, no tira error sino que me devuelve al escritorio...y ademas estoy casi seguro que no entra en el bucle While(get_dist(id_prota) > 200) fijate que le puse esto adentro para comprobar (esto de comprobarlo con el color en 0 no con la var color_librepaso):
If (hay_camino == 1)
Write(fuente1,400,400,4,"¡¡funciona!!"); <<<-----------
WHILE (path_getxy(&path_x, &path_y))
x =path_x * 2; // le puse 2 pq el mapa de caminos esta a la mitad del mapa donde camina el prota
y =path_y * 2;
Frame;
END
End
Quote from: Outlaw on September 30, 2010, 12:56:00 AM
Prg gracias por tu paciencia! Ya se que paresco tonto pero bue! jajaja! El tema es que hice todo como e dijiste vos, comprendiendo todo. Cosa curiosa que pasa es que cuando cambio el color 0, a color_librepaso=rgb(0,0,0) se tilda, no tira error sino que me devuelve al escritorio...y ademas estoy casi seguro que no entra en el bucle While(get_dist(id_prota) > 200) fijate que le puse esto adentro para comprobar (esto de comprobarlo con el color en 0 no con la var color_librepaso):
If (hay_camino == 1)
Write(fuente1,400,400,4,"¡¡funciona!!"); <<<-----------
WHILE (path_getxy(&path_x, &path_y))
x =path_x * 2; // le puse 2 pq el mapa de caminos esta a la mitad del mapa donde camina el prota
y =path_y * 2;
Frame;
END
End
no te preocupes:)
el color 0 y rgb(0,0,0) son distintos. cero significa que no hay color, rgb(0,0,0) retorna el color con rojo=0, verde=0 y azul=0 pero con alpha de 255 y se usa para colocar colores invisibles pero que colisiona. si quieres 0 usa rgba(0,0,0,0), pero te recomiendo mejor un
[code language="bennu"]#define sncam 0
if (MAP_GET_PIXEL(fichero1,48,x/2,y/2) == sncam and MAP_GET_PIXEL(fichero1,48,id_prota.x/2,id_prota.y/2) == sncam )
[/code]
sncam...nunca lo habia visto... :P...gracias! aunque sigue sin seguir al prota, pero bueno, seguire investigando! ;)
mmm... quizas puede ser el tamaño del mapa... prg, probaste el ejemplo?
de que tamaño es el mapa que usas? lo podes adjuntar?
todavia no he visto el codigo que adjuntaste, ahora lo chequeo.
saludos.
Compañeros, aca lo subi a rapidshare: http://rapidshare.com/files/422341317/ElMitoV020.rar
Esta el .prg, el .fpg y las dos .fnt
Mil gracias por su ayuda!
maldito rapidshare y maldito speedy... tengo problemas de conexion, fallan las conexiones tcp (no la conexion adsl) y se cago gusto cuando tenia que hacer el download, asi que perdi la descarga, ahora tengo que esperar 15 minutos.
podrias pasarmelo por mail o subirlo a megaupload?
Splinter quiere pipas :)
Yo ya lo tengo ;)
Que raro yo nunca tuve problemas Splinter! ::) dame tu mail por mp y te lo mando!
mi mail no es problema...
splintergu@bennugd.org
decia por megaupload porque tengo una cuenta premium y no tengo esperas, asi que reintentar no me preocupa.
Aca va en megaupload: http://www.megaupload.com/?d=LN78K1HP
falta el busca.prg
lo comente y funciona...
ahora voy a releer porque no se me cae la aplicacion.
bien, tenes varios errores...
1) no tenes que usar rgb(0,0,0) para el color, sino simplemente 0, con esto podes corregirlo
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");
2) en el momento del path_find estas mezclando advance con path_find con angle, tenes que usar un solo metodo, si usas path_find no uses advance ni angle con respecto al personaje sino que tenes que hacer get_angle con respecto al resultado del path_getxy.
para una idea de por donde tenes que apuntar, aca modifique tu codigo para que veas como deberias encarar la cosa, esto no es la solucion, solo para mostrarte como funciona el path_find
Process Enemigo_dispara(graph,velocidad,x,y,x2,y2,x3,y3,x4,y4,x5,y5)
Private
disparado;
x_original,y_original;
velocidad_original;
waypoint;
x1,y1;
ang_hasta_prota;
usado=0;
Lo_ve;
byte hay_camino;
int path_x,path_y;
Begin
ctype=c_scroll; // a la variable ctype le doy el valor para que este dentro del scroll
x_original=x;
y_original=y;
velocidad_original=velocidad;
waypoint=1;
Loop
/*
ang_hasta_prota=Get_angle(id_prota);
Switch(waypoint)
Case 1:
angle=Fget_angle(x,y,x2,y2);
If (Fget_dist(x,y,x2,y2) < velocidad)
x=x2;
y=y2;
Else
Advance(velocidad);
End
If (x == x2 and y == y2) waypoint++; End
End
Case 2:
angle=Fget_angle(x,y,x3,y3);
If (Fget_dist(x,y,x3,y3) < velocidad)
x=x3;
y=y3;
Else
Advance(velocidad);
End
If (x == x3 and y == y3) waypoint++; End
End
Case 3:
angle=Fget_angle(x,y,x4,y4);
If (Fget_dist(x,y,x4,y4) < velocidad)
x=x4;
y=y4;
Else
Advance(velocidad);
End
If (x == x4 and y == y4) waypoint++; End
End
Case 4:
angle=Fget_angle(x,y,x5,y5);
If (Fget_dist(x,y,x5,y5) < velocidad)
x=x5;
y=y5;
Else
Advance(velocidad);
End
If (x == x5 and y == y5) waypoint++; End
End
Case 5:
angle=Fget_angle(x,y,x_original,y_original);
If (Fget_dist(x,y,x_original,y_original) < velocidad)
x=x_original;
y=y_original;
Else
Advance(velocidad);
End
If (x == x_original and y == y_original) waypoint=1; End
End
End
// 400 // 400
If ((get_dist(id_prota) < 10 and angle + 45000 <= ang_hasta_prota) or (get_dist(id_prota) < 10 and angle - 45000 <= ang_hasta_prota)) // ahora si OK!! lo ve!!
Repeat
If (usado == 0)
Lo_ve=Que_ve(x,y);
usado=1;
End
If (Lo_ve == true)
velocidad=0;
angle=get_angle(id_prota);
If (get_dist(id_prota) < 300)
If (disparado == false)
disp_enem(x,y,angle);
disparado=true;
End
End
If (disparado == true)
tiempo+=1;
End
If (tiempo == 30)
disparado=false;
tiempo=0;
End
*/
If (get_dist(id_prota) > 1)
velocidad=velocidad_original;
hay_camino=path_find(fichero1,48,x/2,y/2,id_prota.x/2,id_prota.y/2,0);
If (hay_camino == 1)
// If (MAP_GET_PIXEL(fichero1,48,x/2,y/2) and MAP_GET_PIXEL(fichero1,48,id_prota.x/2,id_prota.y/2))
WHILE (path_getxy(&path_x, &path_y))
x =path_x * 2; // le puse 2 pq el mapa de caminos esta a la mitad del mapa donde camina el prota
y =path_y * 2;
//xadvance(fget_angle(x=path_x*2,y=path_y*2,id_prota.x,id_prota.y),velocidad);
Frame;
END
// End
End
Frame;
End
If (collision(type disparo) or collision(type golpe))
exp+=10;
return;
End
/*
End
Frame; // este frame va porq como entra en un bucle del bucle pierde al frame de afuera
Until (get_dist(id_prota) > 400)
End
*/
If (collision(type disparo) or collision(type golpe))
exp+=10;
return;
End
Frame;
End // end if
End
lo había bajado, pero no vi el gráfico así que no le metí mano.
lo del rgb ya se lo había dicho al compañero, supongo que se le pasó.
Quotelo color 0 y rgb(0,0,0) son distintos. cero significa que no hay color, rgb(0,0,0) retorna el color con rojo=0, verde=0 y azul=0 pero con alpha de 255 y se usa para colocar colores invisibles pero que colisiona. si quieres 0 usa rgba(0,0,0,0), pero te recomiendo mejor un
[code language="bennu"]#define sncam 0
if (MAP_GET_PIXEL(fichero1,48,x/2,y/2) == sncam and MAP_GET_PIXEL(fichero1,48,id_prota.x/2,id_prota.y/2) == sncam )
[/code]
Quote from: Outlaw on September 30, 2010, 02:35:22 AM
sncam...nunca lo habia visto... :P...gracias! aunque sigue sin seguir al prota, pero bueno, seguire investigando! ;)
perdón por no explicar. sncam es una constante que defino como cero, porque como te dice splinter no debes usar rgb(0,0,0)
Quote from: SplinterGU on September 30, 2010, 09:46:13 PM
falta el busca.prg
A que "busca.prg" te referis Splinter?
Más allá de eso, mil gracias en serio por tomarte tu tiempo para ayudarme!
Prg, gracias tambien!
Edito: después de mucho probar y probar sigue sacandome del programa y vuelvo al notepad++, no se que sera, tal vez es mi maquina? es todo un misterio...en teoria deberia funcionar!
Quote from: Outlaw on October 01, 2010, 12:20:17 AM
Quote from: SplinterGU on September 30, 2010, 09:46:13 PM
falta el busca.prg
A que "busca.prg" te referis Splinter?
Más allá de eso, mil gracias en serio por tomarte tu tiempo para ayudarme!
Prg, gracias tambien!
Edito: después de mucho probar y probar sigue sacandome del programa y vuelvo al notepad++, no se que sera, tal vez es mi maquina? es todo un misterio...en teoria deberia funcionar!
ok. no te traumes. ::)
pasame el codigo y todos los archivos graficos y los revisaré minuciosamente para ver qué puede ser. :)
¿ya probaste lo que te dijo splinter?
Ok, te paso el .prg, supongo que el resto de las partes (fpg, fnt) lo tenes del link que deje...Fijate que curioso en el proceso enemigo_dispara, que es por el cual viene la consulta, dejo solo el bucle del path_find y el prg ni siquiera se inicia, es decir, algo grave me esta pasando con ese path_find...es muy raro no?
a mi se me salio un par de veces, pero no se cuando pasa, y me parece que no tiene que ver con el path_find, las veces que se me salio no dio ningun error, pareciera como que es la logica de tu programa, quizas energia del personaje, no se, no revise el codigo, asi que si no tenes nada de eso puede ser algun error, lo raro es que no tenga ningun mensaje.
Voy a seguir revisando el codigo... :P
el mapa de caminos me da valores muy raros, posiblemente sea ese el problema. lo revisaré pero podré hacerlo hasta dentro de 26 horas. de todas formas, lo que encuentre te lo comento. saludos.
bien, solucionado.
el problema es el mapa de caminos. el color donde se transita es 0, no negro -16777216. la forma más sencilla de lograr el cero es usando gráficos de 8 bits, así que la solución es lo que te había comentado con anterioridad de map_get_pixel y un mapa de caminos correcto.
adjunto fpg de 8 bits con el mapa y código solucionado.
Prg la verdad debo decirte muchisimas gracias!! estaba que no podia encontrar el problema, el asunto es que yo no habia entendido que el mapa de caminos lo tenia que guardar en un fpg distinto de 8 bits, separado del resto! cuando pasaba los mapas de camino a 8 bits y luego los volvia a poner en el pfg de 32 me preguntaba quie pasaba, y era que obviamente convierte todos los mapas con la profundidad que tenia, 32 bits! Van karmas bien merecidos!!! :) :) :) (gracias por tu ayuda aunque suene repetitivo)
Quote from: Prg on October 03, 2010, 03:42:51 AM
bien, solucionado.
el problema es el mapa de caminos. el color donde se transita es 0, no negro -16777216. la forma más sencilla de lograr el cero es usando gráficos de 8 bits, así que la solución es lo que te había comentado con anterioridad de map_get_pixel y un mapa de caminos correcto.
adjunto fpg de 8 bits con el mapa y código solucionado.
se nota que ni leyeron mis respuestas, me mate usando tiempo al pedo... gracias!!!!
http://forum.bennugd.org/index.php?topic=1674.msg29289#msg29289
Quote from: SplinterGU on September 30, 2010, 10:32:28 PM
bien, tenes varios errores...
1) no tenes que usar rgb(0,0,0) para el color, sino simplemente 0, con esto podes corregirlo
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");
2) en el momento del path_find estas mezclando advance con path_find con angle, tenes que usar un solo metodo, si usas path_find no uses advance ni angle con respecto al personaje sino que tenes que hacer get_angle con respecto al resultado del path_getxy.
para una idea de por donde tenes que apuntar, aca modifique tu codigo para que veas como deberias encarar la cosa, esto no es la solucion, solo para mostrarte como funciona el path_find
Process Enemigo_dispara(graph,velocidad,x,y,x2,y2,x3,y3,x4,y4,x5,y5)
Private
disparado;
x_original,y_original;
velocidad_original;
waypoint;
x1,y1;
ang_hasta_prota;
usado=0;
Lo_ve;
byte hay_camino;
int path_x,path_y;
Begin
ctype=c_scroll; // a la variable ctype le doy el valor para que este dentro del scroll
x_original=x;
y_original=y;
velocidad_original=velocidad;
waypoint=1;
Loop
/*
ang_hasta_prota=Get_angle(id_prota);
Switch(waypoint)
Case 1:
angle=Fget_angle(x,y,x2,y2);
If (Fget_dist(x,y,x2,y2) < velocidad)
x=x2;
y=y2;
Else
Advance(velocidad);
End
If (x == x2 and y == y2) waypoint++; End
End
Case 2:
angle=Fget_angle(x,y,x3,y3);
If (Fget_dist(x,y,x3,y3) < velocidad)
x=x3;
y=y3;
Else
Advance(velocidad);
End
If (x == x3 and y == y3) waypoint++; End
End
Case 3:
angle=Fget_angle(x,y,x4,y4);
If (Fget_dist(x,y,x4,y4) < velocidad)
x=x4;
y=y4;
Else
Advance(velocidad);
End
If (x == x4 and y == y4) waypoint++; End
End
Case 4:
angle=Fget_angle(x,y,x5,y5);
If (Fget_dist(x,y,x5,y5) < velocidad)
x=x5;
y=y5;
Else
Advance(velocidad);
End
If (x == x5 and y == y5) waypoint++; End
End
Case 5:
angle=Fget_angle(x,y,x_original,y_original);
If (Fget_dist(x,y,x_original,y_original) < velocidad)
x=x_original;
y=y_original;
Else
Advance(velocidad);
End
If (x == x_original and y == y_original) waypoint=1; End
End
End
// 400 // 400
If ((get_dist(id_prota) < 10 and angle + 45000 <= ang_hasta_prota) or (get_dist(id_prota) < 10 and angle - 45000 <= ang_hasta_prota)) // ahora si OK!! lo ve!!
Repeat
If (usado == 0)
Lo_ve=Que_ve(x,y);
usado=1;
End
If (Lo_ve == true)
velocidad=0;
angle=get_angle(id_prota);
If (get_dist(id_prota) < 300)
If (disparado == false)
disp_enem(x,y,angle);
disparado=true;
End
End
If (disparado == true)
tiempo+=1;
End
If (tiempo == 30)
disparado=false;
tiempo=0;
End
*/
If (get_dist(id_prota) > 1)
velocidad=velocidad_original;
hay_camino=path_find(fichero1,48,x/2,y/2,id_prota.x/2,id_prota.y/2,0);
If (hay_camino == 1)
// If (MAP_GET_PIXEL(fichero1,48,x/2,y/2) and MAP_GET_PIXEL(fichero1,48,id_prota.x/2,id_prota.y/2))
WHILE (path_getxy(&path_x, &path_y))
x =path_x * 2; // le puse 2 pq el mapa de caminos esta a la mitad del mapa donde camina el prota
y =path_y * 2;
//xadvance(fget_angle(x=path_x*2,y=path_y*2,id_prota.x,id_prota.y),velocidad);
Frame;
END
// End
End
Frame;
End
If (collision(type disparo) or collision(type golpe))
exp+=10;
return;
End
/*
End
Frame; // este frame va porq como entra en un bucle del bucle pierde al frame de afuera
Until (get_dist(id_prota) > 400)
End
*/
If (collision(type disparo) or collision(type golpe))
exp+=10;
return;
End
Frame;
End // end if
End
Gracias Splinter Tambien!!!!!!!!! La cosa es que de tu explicación, lo que era mas facil poner era que debia guardar el mapa de caminos en un fpg diferente con formato de 8 bits, en cambio vos me pusiste una funcion para que pintara el grafico de un color a otro, es decir convertirlo, cosa que yo no entendia su utilidad del todo. Va karma para vos tambien por tu ayuda, y no te enojes es solo que prg hizo una explicacion (la ante ultima que dio) para dummies y ahi recien entendi...el tema es que las diferencias entre un div-like y otro son bastantes, en este caso del path_find son profundas, cuesta cambiar la manera de pensar entre uno y otro, y disculpen que sea tan duro para entender!
ahorita que hablas de la funcion de cambio de colores, jeje, no la había visto. disculpa slpinter. (http://us.123rf.com/400wm/400/400/geotrac/geotrac0508/geotrac050800099/226691-funny-face-muchacho-rascarse-la-cabeza.jpg)
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.
todo bien... yo no me enojo, y si lo hago, me desenojo rapido.
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!
Quote from: Outlaw on October 04, 2010, 04:39:42 PM
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.
Quote from: SplinterGU on October 04, 2010, 03:57:07 PM
todo bien... yo no me enojo, y si lo hago, me desenojo rapido.
gracias ;)
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
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.
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.
Quote from: SplinterGU on October 04, 2010, 09:41:50 PM
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.
ja, debe ser por la comparacion, que no es por = sino por < o > no recuerdo.
:(, 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 :)
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
// 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.
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?
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).
Quote from: DCelso on October 04, 2010, 10:08:18 PM
:(, 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.
Quote from: DCelso on October 04, 2010, 10:19:45 PM
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
// 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.
Quote from: Outlaw on October 05, 2010, 12:38:02 AM
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.
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.
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 ;) )
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.
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.
Quote from: Drumpi on October 05, 2010, 02:23:55 AM
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?
Quote from: SplinterGU on October 05, 2010, 02:15:03 AM
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)
(http://www.gamasutra.com/features/20010314/pinter_01.jpg)
Lo que busco yo es que haga C o D, es decir curvas, para suavisar el movimiento en 8 direcciones.
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.
: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
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.
Quote from: Outlaw on October 05, 2010, 05:39:27 AM
: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.
: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.
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.
:'(, sorry por no verlo.
Quote from: SplinterGU on October 05, 2010, 03:03:44 AM
Quote from: Drumpi on October 05, 2010, 02:23:55 AM
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