Hola, resolviendo una duda de Free, me he encontrado con un error en la función advance.
Resulta que el ejemplo que viene a continuación debe lanzar 10 disparos pero en vez de lanzar 10 lanza un número distinto dependiendo del valor pasado a advance, es algo raro, pero a las pruebas me remito.
import "mod_key"
import "mod_proc"
import "mod_map"
import "mod_video"
import "mod_grproc"
global
int graf_disp;
Begin
set_mode(320,240,32);
graf_disp=load_png("recursos/bolafuego.png");
dragon();
Repeat
frame;
Until(key(_ESC))
End
Process dragon()
Begin
x=160;
y=200;
graph = load_png("recursos/dragon1.png");
while(!key(_esc))
if (key(_d))
disparo(x - 3, y, 95000);
disparo(x + 3, y, 85000);
disparo(x - 3, y, 100000);
disparo(x + 3, y, 80000);
disparo(x - 3, y, 105000);
disparo(x + 3, y, 75000);
disparo(x - 3, y, 110000);
disparo(x + 3, y, 70000);
disparo(x - 3, y, 115000);
disparo(x + 3, y, 65000);
while(key(_d)) frame; end
end
frame;
End
unload_map(0,graph);
End
Process disparo(x,y,angle)
private
id_colision;
Begin
size=25;
graph=graf_disp;
Repeat
advance(7);
Frame(500);
Until(y<0);
End
He probado
advance(1) -> se ve una imagen pero no se mueve
advance(2) -> salen 2 disparos
advance(7) -> salen 6
advance(8) -> salen 8
advance(10) -> O mas de 10, salen los 10 disparos.
Si pones entre las llamadas a los 10 disparos un frame (200) ya no pasa este efecto.
Así que el problema está en ejecutar mas de una vez advance en el mismo frame, creo.
¿Alguien sabe el motivo?
Yo no tengo problemas, lanza solo los que creo, pero uso frame; no he probado con distintos valores de frame;
Pero volviendo al tema anterior del otro post ya que tb tiene que ver con advance.
En primer lugar decirte que lo del xor te funciona en Bennu porque no has puesto enemigos :) si colisionas con uno te va petar por lo que dije, tienes que cambiar el IF en Bennu.
En segundo, hablando del advance(), yo en tu demo me parece que tambien tienes el mismo problema para los angulos
disparo(x - 3, y, 95000);
disparo(x + 3, y, 85000);
que no se mueven en el eje x, no puedes probar con graficos que sean meros pixels para que lo cumpruebes ??
En mi ejemplo los tiros son pequeños, y noto el problema, pero con tus graficos tan grandes a la velocidad que pones no me entero :)
Sobre tu pregunta del frame, mirando tu ejemplo, la linea:
while(key(_d)) frame; end
a mi me sobra, yo no pongo frame cuando llamo los disparos,
y tampoco pongo
frame(800);
entre disparos.
Así que no me da el error ese.
Probando tu ejemplo sin estas 2 cosas:
Se puede apreciar mejor que tambien tienes problemas con los 2 angulos esos, y que no salen de encima del tiro del medio, o sea, no se mueven en el eje X.
por lo que veo no es un bug...
que pasa si en vez de size 25, pones size 100 o no pones nada?
Free, este es otro ejemplo, no lo confundas ( no esta el frame 800 que dices), confundiste a splinter.
El error lo he acotado,Splinter si pruebas el ejemplo adjunto verás que da igual el tamaño del sprite, aqui (en este ejemplo) el problema radica en que no se ven los 10 disparos que lanzo con advance inferior a 10.
En cambio con advances superiores va perfecto.
No entiendo porque lo haces asi:
-------------------------------
Repeat
advance(7);
Frame(500); En 5 segundos avanzo 7 pixels.
Until(y<0);
Yo pondria mejor:
-----------------
Repeat
advance(1);
Frame; En 1 segundo avanzo 1 pixel, osea que en 5 segundos avanzare 5 pixels, si es poco para ti pues "advance(2)"
Until(y<0);
Siempre que he jugado con FRAME he tenido que repasar el codigo mil veces por errores "errores mios no contemplados" ya que ocurrian cosas extrañas que no llegava a entender..
Al final opte por dejar a FRAME tranquilo y crear los retardos por otro lado.
Cierto es que esto me pasava en div2 y Gemix, pero vaya, supongo que tal vez pueda ser tu caso.
Si no es asi disculpa por el royo que acabo de escrivir.
Piensa que si pones Frame(500) durante 5 segundos el grafico no se va a mover y posiblemente llames a los disparos correctamente, lo que estan unos encima de otros y no los vas a ver..
Quote from: DCelso on October 01, 2009, 06:47:17 PM
Free, este es otro ejemplo, no lo confundas ( no esta el frame 800 que dices), confundiste a splinter.
El error lo he acotado,Splinter si pruebas el ejemplo adjunto verás que da igual el tamaño del sprite, aqui (en este ejemplo) el problema radica en que no se ven los 10 disparos que lanzo con advance inferior a 10.
En cambio con advances superiores va perfecto.
no estan o estan encimados?
eso puede ser por la presicion como ya dije, si usas advance, conviene usar resolution...
como sea, no tiene nada que ver con frame...
al hacer frame o no, estas cambiando la forma y orden en que se ejecutan los procesos... pero el advance no tiene nada que ver...
Ya veo, tiene su lógica, puede que advance (1) devuelva la misma x e y por eso el proceso parece que no se mueve. Voy a probar.
Tienes razón DCelso, me entere justo despues de postear, ya que estaba editando el otro ejemplo.
Aqui también tenias razón splinter, en este caso era problema de solapamiento, se lanzan los 10 disparos pero solo se ven 6 porque unos coinciden exactamente con otros debido a la poca resolución.
Puse al disparo un alpha =100 y vi el problema
He aprovechado los conocimientos recientemente adquiridos de resolución para separa un poco las direcciones y ver mejor los solapamientos, que en este caso debido a aplicar resolucion ningún disparo coincide exactamente con otro como pasaba en el caso anterior.
import "mod_key"
import "mod_proc"
import "mod_map"
import "mod_video"
import "mod_grproc"
global
int graf_disp;
Begin
set_mode(320,240,32);
graf_disp=load_png("recursos/bolafuego.png");
dragon();
Repeat
frame;
Until(key(_ESC))
End
Process dragon()
Begin
x=160;
y=200;
//graph = load_png("recursos/dragon1.png");
while(!key(_esc))
if (key(_s))
disparo(x - 3, y, 95000);
disparo(x + 3, y, 85000);
disparo(x - 3, y, 100000);
disparo(x + 3, y, 80000);
disparo(x - 3, y, 105000);
disparo(x + 3, y, 75000);
disparo(x - 3, y, 110000);
disparo(x + 3, y, 70000);
disparo(x - 3, y, 115000);
disparo(x + 3, y, 65000);
while(key(_s)) frame; end
end
frame;
End
unload_map(0,graph);
End
Process disparo(x,y,angle)
private
id_colision;
Begin
alpha = 100;
resolution =10;
x*=resolution;
y*=resolution;
graph=graf_disp;
Repeat
advance(8*resolution);
Frame(100);
Until((y<0) or key(_esc));
End
Muchas gracias por el ejemplo, me has resuelto el problema, ahora estas 2 lineas tambien funcionan como en Fenix.
Que haria sin vosotros ;)
No os doy el karma porque solo tengo uno ;)
ni que fueras a perderlo :D, tu solo ves los que te han dado no los que tienes para dar :D
OFFTOPIC: En este foro el Karma fluye con mayor o menor intensidad en algunas temporadas... ¿Hay estadísiticas de Karmas lanzados por los usuarios? Estoy seguro de que en ciertas flechas en Karma fluye más fácilmente...
Curioso problema el de advance... Si ya lo has solucionado me alegro, en cualquier caso lo primero que se me ha pasado por la cabeza es que el advance(1) genera los catetos asociados a la hipotenusa 1 en x y en y resultando valores 0,707 que se truncan a 0...
Es lo primero que he pensado :P
No lo sabia.
Tengo malas noticias.
2 problemas usando esto:
1 - El switch no me enseña la explosion_del_tiro(x, y); al colidir con el enemigo, supongo que es por los valores de x,y:
Switch(graf_disp); // gráfico de disparo
Case 1:
id_colision.vida-=5; // vida es una variable comun en cada proceso enemigo
If(id_colision.vida > 0) explosion_del_tiro(x, y); End
Break;
End
...
He puesto:
explosio(x/resolution,y/resolution,95,80); o explosio(x*resolution,y*resolution,95,80);
no se lo que poner ;) no funciona, no se que valores tendran x, y,
no deberian ser los mismos que se ven en pantalla durante la colision ?
...
2 - Esta me asusta más:
Usando resolution los tiros no hacen una piramide perfecta en la parte de arriba (corte en horizontal perfecto arriba del tiro), hacen un arco (es chulo el arco pero vamos que no es el mismo comportamiento, parece que las lineas con angulo mayor obtienen menor valor de y).
Bueno la
1- parece que me equivoque en algo, he cambiado las explosiones con:
explosio(x/resolution,y/resolution); y ya localizan el lugar exacto.
sobre el punto 2, estoy pensando en poner mas una variable de entrada en la funcion disparo, para utilizar sólo el resolution en las 2 lineas con menor angulo, y ajustar su valor, para poder crear la piramide perfecta :-\
¿No te resolvería muchos de esos problemas tener unos write() / write_var() con las x,y,graph,etc de cada proceso sobre ellos?
Cuando las cosas se ponen feas y hay valores que no parecen correctos es lo que suelo hacer.
Hhheeheh, ya harto de debugear estoy cuando uso visual studio, aqui prefiero programar a la antigua, probar y mirar todo a ojo ;)
Hombre, con Bennu es más bonito porque los bichitos se mueven y muestran su información, a mi me guzta ::)
FreeYourMind: es normal que no vayan los tiros en perfecta formación horizontal, por pura cuestión geométrica. Forman un arco porque esos puntos están a la misma distancia del centro de donde sales, al usar advance es como si recorrieras el radio de un círculo.
Repasa el tema de ángulos e hipotenusas en triángulos rectángulos. Advance hace que recorras una distancia en un ángulo, y será la hipotenusa del triángulo, los ejes X e Y forman los dos catetos, y obviamente sabemos que los catetos miden menos que la hipotenusa.
Para hacer lo que quieres, no uses advance: mueve el disparo lo que necesites verticalmente a cada frame, y luego desplaza horizontalmente según cada disparo (por ejemplo, el primero x-- a cada frame, el segundo nada, y el tercero x++). Si necesitas que se desplacen menos, ya te hemos explicado (dos veces) el funcionamiento de resolution ;)
Suerte.
drumpi, ya lo solucionaron con el resolution... como ya habiamos dicho...
Te entiendo perfectamente, pero date cuenta que sin usar el resolution el advance() ya no forma un arco, forma una piramide (salvo por las 2 lineas laterales a la linea central, que necesitan el resolution por tener angulo muy pequeño).
Es el comportamiento igual al que tenia en Fenix o Div.
Ya se que Bennu si tiene cambios es porque es mas lógico, y debe tener estos cambios.
Pero creo que se deberia ajustar en la propria funcion advance() sin tener que poner resolution para angulos pequeños, ten en cuenta que estes div like languages son para programar de forma facil, y estas tareas de calculos y ajustes para angulos pequeños deberian ser transparentes para el usuario, en este caso creo que deberia portarse como en Fenix, y internamente hacer estas cosas, no fuera de la función.
Entiendo que lo correcto es que forme un arco y no una piramide, pero hacer que forme una piramide de la forma que dices es engorrosa, porque utilizo el mismo procedimiento para todos los disparos, ya comente una forma más rápida de hacerlo, que seria pasarle otro parametro de entrada a la funcion disparo, seria una flag, con true utilizaria el resolution solo en los dos tiros de angulo pequeño y pondria el valor del advance apropriado, en los otros lo pondria normal sin resolution, o sea, estos ultimos serian una piramide, y los otros 2 hilos ajustando el valor del advance haria que se movieran a la misma velocidad en el eje Y que el resto de hilos, teniendo una piramide similar a la de Fenix :)
Pero si te digo la verdad creo que voy a dejarlo así con el arco, tambien es muy raro que consigas el tiro máximo durante el juego, ;D
Yo sólo digo una cosa (y me voy a dormir): Bennu se comporta igual que Fenix e igual que div respecto a angles, resolutions y advances, te lo digo porque llevo mucho, pero mucho tiempo dedicado en DIV a hacer un FZero (que abandoné por no encontrar el equilibrio entre velocidad y giro).
La única diferencia entre ambos es el modo7, porque en DIV sí usaba los decimales de advance para colocar la nave en dicho espacio, porque en el modo7 los pixels eran más grandes que los de pantalla.
[Furby mode] Mi... dormido... otra veeez....
quizas no me explique, el advance de fenix (no me consta el de DIV) funcionaba porque incrementaba aun cuando no debia hacerlo, y eso esta mal, muy mal... no es cuestion solo de mas logico, es cuestion de que era un bug...
el resolution es de div, y fue puesto por esta misma razon, no es un invento de bennu... el resolution actua dentro de la funcion advance, no fuera... las x,y,z son enteros... y la razon del resolution, es porque fenix, div, no soportan flotantes
entonces, no puede comportarse como algo con bug, la idea es que el bug se solucione...
pensemos un poco, claramente... si partiendo de un punto en comun hacemos advances de objetos a diferentes angulos, eso nunca deberia crear una piramide... deberia ser un arco, es como ir agrandando un circulo... por eso, ahi te das cuenta que hay un bug en los productos viejos...
a todo esto, que juego estas portando?
Quote from: Drumpi on October 02, 2009, 01:48:33 AM
Yo sólo digo una cosa (y me voy a dormir): Bennu se comporta igual que Fenix e igual que div respecto a angles, resolutions y advances, te lo digo porque llevo mucho, pero mucho tiempo dedicado en DIV a hacer un FZero (que abandoné por no encontrar el equilibrio entre velocidad y giro).
La única diferencia entre ambos es el modo7, porque en DIV sí usaba los decimales de advance para colocar la nave en dicho espacio, porque en el modo7 los pixels eran más grandes que los de pantalla.
[Furby mode] Mi... dormido... otra veeez....
Pero si llevamos todo el dia demostrando que no lo es, joer macho ??? te has leido los posts ? Es tan sencillo como ejecutar el codigo que tenia antiguo de div o Fenix en Bennu y ver que los angulos pequeños del ejemplo no se mueven en el eje X, si incluso tu me dijiste el motivo, por los redondeos !!! Creo que ya estabas soñando cuando respondiste ahora , hehehhe. Venga encerramos el tema, que ya me salen advances hasta por las orejas :)
http://www.gecasoft.no.sapo.pt/
Geca Blaster 2, un juego que cumple 10 años (coincidencia celebra aniversário con el port a Wiz), antiguo y desactualizado pero es al que tengo mayor cariño.
Quote from: FreeYourMind on October 02, 2009, 02:08:23 AMPero si llevamos todo el dia demostrando que no lo es, joer macho ??? te has leido los posts ? Es tan sencillo como ejecutar el codigo que tenia antiguo de div o Fenix en Bennu y ver que los angulos pequeños del ejemplo no se mueven en el eje X, si incluso tu me dijiste el motivo, por los redondeos !!! Creo que ya estabas soñando cuando respondiste ahora , hehehhe. Venga encerramos el tema, que ya me salen advances hasta por las orejas :)
Algo se me debe estar escapando, pero bueno, yo sólo cuento mi experiencia, con una nave que o metía mucha resolucion, o mucho avance, o la nave no se movía en el ángulo que miraba. Si hay algún error de cálculo no lo se, porque no iba con la calculadora. Puede que hubiera algún bug, no voy a discutirlo.
Dormido no se si estaba, pero lúcido si, es la única forma de capturar un bug :D
Me he tirado hasta las 4 de la mañana intentando resolver un problema de Zs y al parecer no es culpa mía, sino de Fenix. Lo probaré en Bennu a ver si también pasa.
Oh dios mío, lo hiciste en Fenix...
Yo me pasé a Bennu finalmente tras varios problemas con Fenix que al probar en Bennu dejaban de suceder.
Quote from: FreeYourMind on October 01, 2009, 07:56:39 PM
Muchas gracias por el ejemplo, me has resuelto el problema, ahora estas 2 lineas tambien funcionan como en Fenix.
Que haria sin vosotros ;)
No os doy el karma porque solo tengo uno ;)
puedes dar karmas, no se descuentan de los que tienes...
Ya me fije lo que era, es solo darle a la mano que apunta hacia abajo ;D
Por cierto, donde se puede ver quien te los ha dado ?
nuuu... hacia arriba!
Buaa, tengo un karma menos, ¿He sido yo tu conejillo de indias? o es que vi mal ayer mis karmas.
::)
Quote from: Windgate on October 02, 2009, 03:08:29 PM
Oh dios mío, lo hiciste en Fenix...
Yo me pasé a Bennu finalmente tras varios problemas con Fenix que al probar en Bennu dejaban de suceder.
Si, soy malvado, soy fenixero, mwaahaahahaahaaaa.
No, hombre, es que, aparte de que me cuesta actualizarme, es por la costumbre, suelo programar con el FEdit y tengo la ayuda de Fenix (offline). Pero la principal razón es el destino del código: hacer juegos en mi GP2X. Bennu ya me funciona en mi negrita, pero no en las demás, por lo que aun hay un lastre que tira de mi hacia abajo ;D
Eso que se ha dicho sobre ofrecer ayuda "desde el entorno" para el lenguaje... ¿Hay alguna forma de tenerlo para Bennu desde el Notepad++ o similar?
Me refiero a poder seleccionar un nombre de función y que te informe sobre parámetros, DLL en el que se encuentra, etc.
Una vez más, yo me siento muy a gusto con Bennu tal cual está, sólo sugiero cosas "en vez en cuando" de cara a nuevas generaciones.
Ni idea, casi seguro que se puede, casi todos los editores lo llevan ahora bien hay que pelearse para buscar como se configura, pero yo recomiendo usar el plugin de firefox o de opera para buscar en la wiki de bennu, así de paso si encuentras algún error en ella lo corriges o lo notificas para que alguien lo haga :D.
Yo uso constantemente el de ópera además es rápido ya que o bien puedes hacerlo por el combobox pensado para el buscador o directamente poniendo en la url bgd "cosa a buscar en wiki.bennu.org".
mira, en pspad es añadir tu archivo hlp o chm con las palabras reservadas, puedes usar el de flamebird, y ya puedes tocar alt f1 para ver su descripción
http://www.pspad.com/es/helpfiles.htm
Quote from: Drumpi on October 02, 2009, 11:37:13 PM
Quote from: Windgate on October 02, 2009, 03:08:29 PM
Oh dios mío, lo hiciste en Fenix...
Yo me pasé a Bennu finalmente tras varios problemas con Fenix que al probar en Bennu dejaban de suceder.
Si, soy malvado, soy fenixero, mwaahaahahaahaaaa.
No, hombre, es que, aparte de que me cuesta actualizarme, es por la costumbre, suelo programar con el FEdit y tengo la ayuda de Fenix (offline). Pero la principal razón es el destino del código: hacer juegos en mi GP2X. Bennu ya me funciona en mi negrita, pero no en las demás, por lo que aun hay un lastre que tira de mi hacia abajo ;D
eso no importa, si hay una version para tal firm ya esta para ese firm... luego hay que compilar para otro firm... a menos que se pueda hacer una universal, pero viendo lo que te pasa, lo dudo...
Quote from: DCelso on October 02, 2009, 11:14:46 PM
Buaa, tengo un karma menos, ¿He sido yo tu conejillo de indias? o es que vi mal ayer mis karmas.
::)
viste mal, no tenes ningun karma negativo.
Quote from: SplinterGU on October 03, 2009, 02:38:38 AM
Quote from: Drumpi on October 02, 2009, 11:37:13 PM
Quote from: Windgate on October 02, 2009, 03:08:29 PM
Oh dios mío, lo hiciste en Fenix...
Yo me pasé a Bennu finalmente tras varios problemas con Fenix que al probar en Bennu dejaban de suceder.
Si, soy malvado, soy fenixero, mwaahaahahaahaaaa.
No, hombre, es que, aparte de que me cuesta actualizarme, es por la costumbre, suelo programar con el FEdit y tengo la ayuda de Fenix (offline). Pero la principal razón es el destino del código: hacer juegos en mi GP2X. Bennu ya me funciona en mi negrita, pero no en las demás, por lo que aun hay un lastre que tira de mi hacia abajo ;D
eso no importa, si hay una version para tal firm ya esta para ese firm... luego hay que compilar para otro firm... a menos que se pueda hacer una universal, pero viendo lo que te pasa, lo dudo...
Poder se puede hacer universal, basta con compilar usando el SDK oficial. Un día tenemos que hablar, porque he visto que en el SDK de windows hay carpetas muy similares a las que tengo de las toolchains de open2x, a lo mejor se pueden copiar y recompilar con ellas...
Juer, que lio os armais con los karmas ;D