Hola a todos:
Pues nada, una cuestión tonta de las mías.
El siguiente código es un minijuego de averiguar la clave, pero tengo problemas en level_1b.inc. Por alguna razón que no logro ver, el proceso l1_teclado ignora la colisión con el proceso l1t_cucaracha, cuando unas pocas lineas después sí que funciona con otros procesos usando el mismo sistema.
He leido el código durante 3 horas, he descansado y he vuelto a mirarlo, e incluso me he ido a cenar, he visto una peli y he vuelto a mirar sin resultado.
Seguro que es una tontería, pero no veo el fallo.
¿Sabes que se cambió el modo en el que collision funciona para poder recoger todos los ids de todos los procesos con los que se colisiona?
Con esto quiero decir: sólo te dará por bueno una colisión en cada frame. Luego te devolverá 0
¿Eso significa que ahora no se puede comprobar la colisión con dos tipos distintos de procesos? :(
De todas formas, lo raro es que me hace bien la SEGUNDA comprobación después del frame, no la PRIMERA, que es la de la cucaracha.
Quote from: PiXeL on June 13, 2010, 11:45:23 PM
¿Sabes que se cambió el modo en el que collision funciona para poder recoger todos los ids de todos los procesos con los que se colisiona?
Con esto quiero decir: sólo te dará por bueno una colisión en cada frame. Luego te devolverá 0
¿Estás seguro de eso? ¿Desde cuándo? ¿Por qué?
Mexplico. Suponiendo una única instancia de cada uno de estos dos procesos:
process uno();
begin
loop
if(collision(type dos)) /*este siempre funcionará*/ end
if(collision(type dos)) /*y este nunca funcionará*/ end
frame;
end
end
process dos();
begin loop frame; end end
Te entiendo, ¿Pero por qué ese cambio?
Anteriormente era muy sencillo usar WHILE ( collision ( type lo_que_sea ) ) y contabilizar el número exacto de procesos en colisión durante el mismo FRAME...
eso siempre fue asi, ese funcionamiento nunca se cambio... es solo cuestion de logica y coherencia, si estas barriendo una cosa, debes barrer esa cosa y luego barrer otra.
Quote from: Windgate on June 14, 2010, 02:16:48 AM
Te entiendo, ¿Pero por qué ese cambio?
Anteriormente era muy sencillo usar WHILE ( collision ( type lo_que_sea ) ) y contabilizar el número exacto de procesos en colisión durante el mismo FRAME...
antes y ahora, eso es lo que hay que hacer.
Quote from: PiXeL on June 14, 2010, 01:13:11 AM
Mexplico. Suponiendo una única instancia de cada uno de estos dos procesos:
process uno();
begin
loop
if(collision(type dos)) /*este siempre funcionará*/ end
if(collision(type dos)) /*y este nunca funcionará*/ end
frame;
end
end
process dos();
begin loop frame; end end
si hay 1 sola instancia es logico que pase eso, pero si pones otro collision mas si te reportara la colision... por que? simplemente porque cuando el colision termina y ya no encuentra mas, da 0, sino siempre estarias en un ciclo eterno y no se podria hacer un while collision... elemental mi querido PiXeL
Pues si la cosa no ha cambiado, sigo sin ver por qué no detecta colisión con la cucaracha y sí con las teclas. Me consta que se guarda bien la ID en la variable que chequeo, y me consta que se superpone, y todo está correcto... salvo en lo que he metido la pata, que no sé lo que es. Empiezo a pensar que tiene alguna relación el que cada proceso tenga una resolution distinta, cosa que no debería afectar, pero también probé poniéndole a la cucaracha una resolution=1.
no recuerdo que pasa si tiene resolucion diferente, no hay cambios en colision desde fenix o las beta iniciales de bennu...
le voy a echar un ojo a tu codigo...
Que conste que no he hecho "correciones raras" de las mías a la espera de confirmar mi error o fallo de Bennu, que luego me dices que no reporto ;D
je, esperame que lo miro en un rato...
si te refieres a esta porcion de codigo...
if (teclas[mouse_left][2]==1)
//temp=collision(l1t_cucaracha_id);
//say(itoa(temp));
if (collision(l1t_cucaracha_id))
say("hola");
else
a mi si que me funciona, me pone "hola"
ah, cierto, esto ya lo habiamos visto, ahora recuerdo, un proceso de 1x1 nunca va a colisionar, se necesita al menos un grafico de ancho 2.
Esto se merece un
¡¡PLOINK!!
En toda regla ^^U
¿Y eso? ¿es alguna limitación, algun bug o por decisión propia? Tiene miga la cosa, un mapa de 2x2 con un único pixel no-transparente hace lo mismo pero hay que saberlo.
Bueno, mañana sigo con este y el otro.
UPS, lo olvidé: GRACIAS SPLINTER :)
2x1, algun bug de precision conocido (que ya se hablo del tema) que aun no he dedicado suficiente tiempo para resolver.
de nada
Me sigue picando la curiosidad sobre el tema de la detección de múltiples colisiones con procesos del mismo tipo en el mismo FRAME.
¿Qué alternativa queda entonces al:
[code]WHILE ( collision ( type disparo ) )
vida = vida - 1;
END[/code]
La collision que tengo montada con Bennu 3D en 3Dit sigue esa filosofía de detección de colisiones con múltiples procesos del mismo tipo en el mismo FRAME, haciendo uso de get_id para comprobar si cada uno de ellos está en colisión o no...
¿Quizás una alternativa así sea la solución para Bennu 2D?
Siento tanta pregunta, pero me ha picado mucho la curiosidad con ese cambio, no estaba al corriente.
no me has leido nada...
EDIT:
1) No hay cambios
2) Para colisionar con disparo, laser y missile, por ejemplo, el codigo seria:
...
WHILE ( collision ( type disparo ) )
vida = vida - 1;
END
WHILE ( collision ( type laser ) )
vida = vida - 1;
END
WHILE ( collision ( type missile ) )
vida = vida - 1;
END
FRAME;
...
3) perdon si sueno un poco agresivo en mis respuestas, intento contestar rapido porque tengo siempre 1000 cosas para hacer y el tiempo no me alcanza, y repetir las cosas me pone un poco mas acelerado.
pido disculpas si a veces respondo mal o con un tono no muy elegante, pero lo hago sin darme cuenta, despues que me doy cuenta ya es tarde.
Nada tranki, es que PiXeL me había cambiado un poco el chip con ese asunto, y como a veces veo varios mensajes seguidos y no me pongo a leerlo todo todo... Ahora sí que está todo aclarado, asias ;D