Me he dado cuenta de un cambio brusco en el comportamiento de mi código desde que actualicé a la RC20 (osea hace unas 2 horas, SIN el fix para las .dcl)
Los enemigos esféricos mueren, pero invocan inmediatamente a otro arriba del que mataron, lo mismo con los esféricos grandes.
Las naves que salen al azar a "sembrar" enemigos esféricos, al momento de morir crean otra nave, en las mismas coordenadas de donde salió la que murió con el mismo tipo de giro (izq o derecha).
Además ya no puedo sacar el consola debug, me tira un win32 exception y chan crash.
Estoy con cara de WTF??!! :o
He pillado algo en mi codigo que no debería haber ido tal como estaba. Lo he corregido y ya los enemigos esféricos no se "auto-invocan". Sin embargo, sucede a veces con las formaciones, ver video más abajo.
Lo curioso es que antes no salía este comportamiento errático, el cambio del core me afectó.
A revisar sus proyectos.
Eso si, sigo sin poder sacar la consola de debug... y es raro, pues en el menu si puedo, pero durante el juego nop.
Entre ambos hay una pequeña diferencia: el restore_type
En menu:
restore_type = PARTIAL_RESTORE;
En juego:
restore_type = NO_RESTORE;
dump_type para ambos: partial_dump
--EDIT--
1)Añado que el comportamiento del mod_rand tambien me parece que cambió, es como si la muestra no fuese tan homogénea, quiero decir, salen muchos más disparos de los enemigos (y enemigos) que antes :S
2)Añado link a un video del bug: infinitos enemigos (http://www.youtube.com/watch?v=h4Yew3qNRzc)
los cambios realizados no tienen que ver con lo que mencionas, solo afectan si usas dcl...
pregunta, recompilaste el dcb nuevamente?
el mod_debug es cierto, tengo que actualizar a la nueva version de dcb.
ya esta corregido el mod_debug... quizas eso afecte todo el resto, no lo se...
gracias y karma!
si puedes generar y probar version hazlo, yo ahora no puedo hacer ninguna prueba.
debo aclarar que el bug en el mod_debug, aplica a los nuevos dcb compilados, los viejos mantienen su soporte correcto...
ahora en el svn esta el fix, durante el dia subo los binarios.
subiendo el fix... el fix solo afecta al mod_debug, era la linea donde obtiene el numero de archivo y file de donde obtener la linea de debug.
como tengo que usar el nuevo sistema de descargas de versiones, tengo que generar una nueva release completa, asi que va subiendo release completa...
avisame que tal va.
Quote from: SplinterGU on January 05, 2011, 12:47:36 PM
pregunta, recompilaste el dcb nuevamente?
Sip, en un rato pruebo de nuevo con los nuevos binarios y te comento.
¿Viste el video? Es un gran wtf!
Yap, al parecer el mod_debug ahora funciona correctamente.
Me siguen saliendo infinitos enemigos...
El comportamiento es el mismo: matas enemigos de los que giran alrededor de la pantalla y vuelven a salir exactamente en la misma posición infinitamente
Lo miro y lo remiro y no sé que puede estar mal :S
Antes funcionaba bien :(
Te subo el mismo código, compilado uno con la RC19(r189) y el otro con la RC20(r200).
Ahi verás que el mismo código tiene comportamientos distintos, errático totalmente en la RC20 con los enemigos que giran en los bordes de la pantalla.
Link:
Deadly Eye: RC19(r189) vs RC20(r200) (http://www.mediafire.com/?01duk7xzcacod4j)
PD: Confirmo que el debug ahora funciona correctamente, pero solo eso :P
lo chequeo... decime en que linea decis salen enemigos y enemigos...
acabo de probarlo, no me pasa eso que salen infinitos enemigos.
te digo mas, tal cual asi se comporta en caanoo...
si me das mas detalles puedo ver el tema mejor.
Mira, en formaciones.prg estan los procesos que crean enemigos y formaciones.
Los que giran alrededor de los bordes (looperos) comienzan su creación en la linea 61 en el proceso crearEnemigos(), donde llamo a la función que calcula su posición inicial y cuantas formaciones se van crear. Luego se crea otro proceso que es el que finalmente crea los enemigos (crearFormacionEnemigos()).
La muerte de los enemigos estan en enemigos.prg, desde la línea 523 en adelante. Yo alcanzo a ver que el enemigo muere (explota), pero aparece de nuevo desde el mismo lugar desde donde habia salido inicialmente. ¿probaste solo los dcb o usaste el .exe? Usando el .exe (bgdi renombrado) logro reproducir el comportamiento normal (RC19) y el extraño (RC20). Ten en cuenta que todas las librerías corresponden a su respectiva RC. No he probado testear los 2 dcb con el mismo runtime.
juas! Tercer equipo donde lo pruebo y vuelvo a reproducir el error. Esta vez fue en el laptop, corriendo solo los dcb con la ultima version que ha subido josebita a su ppa: rc20 svn20110104 con módulos rc19 svn20101229
No sé que cambio hacer, ya que en una funciona bien y en otra no :S :S
yo he probado con el ultimo runtime... pero no veo que las naves salgan donde murieron... si veo muchas naves, no hay duda de eso...
y tambien cuando te hice el test en caanoo lo veia exactamente igual...
caramba... en serio que lo pruebo y no me pasa... los enemigos mueren y no vuelven a aparecer donde murieron... y ahora probe con los exe de los packs que enviaste... eso si, los probe con wine.
jajaja, vi el video, te juro que no me pasa.
Tienes la semilla en los rands asignada ? (esta sólo se debe asignar una vez al principio).
Quote from: FreeYourMind on January 05, 2011, 11:16:44 PM
Tienes la semilla en los rands asignada ? (esta sólo se debe asignar una vez al principio).
iba a mencionar algo al respecto, quizas el problema sea que los RAND dan valores diferentes, es mas, nunca se debe asumir valores de los rand, estos no siempre pueden dar igual, menos entre plataformas diferentes.
por otro lado, yo diria que en un juego de naves, no deberias usar RAND para determinar cuando salen eventos/enemigos, sino usar tablas preasignadas, para que siempre surjan los mismos enemigos en los mismos lugares.
a mi me suena que el problema es de los RAND.
y en mis pruebas no pasa eso que mostras en el video.
si, la semilla esta asignada hace mucho en la primera línea del main con rand_seed(time())
Normalmente en los juegos de naves sucede lo que dices, siempre salen los enemigos en el mismo lado, y yo no quería que fuese así: terminas aprendiendote por donde salen los malos y despues se vuelve aburrido jugar de nuevo (al menos a mi me pasa). Tengo solo algunos eventos por tiempo fijos: la salida de las esferas atacando en espiral, 3 rangos de tiempo donde salen solo esferas pequeñas o salen de los sembradores de esferas junto a los que se te acercan a dispararte; y la salida del jefe. El resto es todo cada cierto tiempo, pero al azar, para que al volver a jugar sea distinto y no te puedas memorizar todo :P
¿Free puedes probar en windows por favor? Este bug me tiene loco, ya que no lo puedo solucionar, vuelve el juego injugable y lo peor parece que es personal y me tiene mala solo a mi jajajajajaja ¬¬U
quizas te convendria poner un limitador, si ya existe otro ( o N ) de ese enemigo corriendo no correr otro, y un temporizador que indique tiempo de espera entre vez y vez que salga ese enemigo o incluso para que salga de una esquina determinada.
a mi realmente no me pasa, lamento no poder reproducir el error.
prueba tambien poniendo un rand_seed con un valor fijo y ver si te sigue pasando, prueba varios valores rand_seed.... a ver si es tema de la semilla.
lo raro es que dices que con un runtime pasa y con otro no, a mi no me paso con ninguno de los 2.
Ahora he probado dandole doble click a los dcb en windows:
lo mismo, el hecho con la rc19 perfecto, el con la rc20 hace cosas extrañas.
Quizás hice algo mal al actualizar pero no creo...
Tengo una carpeta en el disco duro, en concreto
E:\Juegos\DesarrolloJuegos\BennuGD
Esta carpeta la tengo en el path, osea en las variables de entorno, ahi tenía los ejecutables y librerias de la RC19, tal como venían en el rar.
Me descargué la RC20, borré el contenido de la carpeta en mi disco, y copié todos los archivos que vienen en el .rar de esta rc.
En consola me seguía reconociendo bgdi y bgdc, es decir, la variable de entorno sigue funcionando bien.
¿prueba solamente lanzando el dcb, sin recurrir a las librerías de la carpeta?
Te insisto, porque ya son 3 máquinas que dan el mismo problema (las 3 amd de distintas épocas, athlon xp 2000+ con overclock, amd athlon 64 x2 5600+ clocks de fábrica, y un athlon 64 x2 tk-57, laptop), y como me tengo fé que no soy tan bruto con los pc, Una de mis teorías es que cuando liberaste los binarios alguna librería no actualizaste o se mezclaron y me quedó la cagá en el juego.
La otra es que al nuevo core no le gusten los amd :S
yo te creo que tenes un problema, de hecho el video lo muestra... lo que no logro es que me pase, quizas sea algo de windows, tendre que probar en windows, pero vos no habias dicho que habias probado en linux?
por otro lado, no hay cambios que puedan afectar, quizas los cambios de los arrays o accesos a los mismo, o tambien puede ser algun tema con punteros que he corregido quizas, no se si usas punteros.
estaria bueno poder aislar el problema, si pones un rand_seed fijo, que reproduzca el tema, quizas yo lo pueda reproducir.
no se me ocurre que puede pasar.
Si, probé en windows xp y linux ubuntu 10.04 (damn, apagué el laptop, no me acuerdo del kernel).
He cambiado la semilla a números fijos y sigue igual :(
He probado en el intel atom con win7 de mi hermana, y lo mismo... y obviamente en ese equipo no esta el runtime ni las variables de entorno, se basa solo en las librerías incluidas en el rar que armé con ambas versiones. Al menos descarto que los proces amd me estén jugando una mala pasada.
He cambiado los casteos de tipos para el puntaje y el daño, fijandome muy bien en los paréntesis, y nada.
Ahora voy a probar unos says en la muerte de los enemigos "looperos" para ver si realmente mueren (al menos cumplen con mostrar el puntaje y añadirselo al jugador, condición que solo se da al morir producto de disparos)
no sera una combinacion de cosas? o sea, disparo triple, desde esa posicion? no se, yo cuando vienen las naves asi, no tengo disparo triple.
Nop, tambien pasa cuando empiezas con el disparo más indigno, en realidad pasa con todo: misiles, laser, las estrellas y disparos EXCEPTO cuando chocas con la nave contra ellos, choques contra el escudo o cuando se activa la explosión del escudo.
Es muy raro.
El say en el OnExit me revela que no siempre el proceso es destruido, y cuando lo hace no los cuenta en el contador global de enemigos (una struct). Este contador solo se actualiza cuando eliminas enemigos con disparos/laser/estrellas/misiles, no cuentan los choques, el escudo o la explosión del escudo.
ES EXTREMADAMENTE RARO.
Probé con los contadores de muertos de los otros tipos de enemigos, y esos si los cuenta bien.
AAAAAAJAJA!! para peor, a VECES sale que mataste un enemigo loopero en la consola, y nunca son los primeros que salen, siempre son los proceso fantasmas que salen de nuevo los que el say revela su muerte... pero de todos modos no los cuenta en la struct...
Se viene el 2012 @_@
los procesos estan siempre en running?
Quote from: SplinterGU on January 06, 2011, 04:16:06 AM
los procesos estan siempre en running?
nunca en frezee o sleep u otro?
tienen sig_ign ?
Solo les tiro freeze cuando sale el contador de tiempo para continuar. Y los descongelo cuando continuas...
Y no tienen sig_ign (que por cierto, no se que es :$)
Es jodidamente extraño, ya que el proceso enemigo (process malo()) es único para todos los enemigos excepto el jefe, cambian sus lógicas de movimiento y atributos iniciales, pero las condiciones de colision/recibir daño/muerte es la misma para todos... no entiendo por que falla solo 1 caso :S
--edit--
Olvidé mencionar que no uso punteros creados por mi... ni siquiera para mostrar datos, ahora uso todo con write_var
por favor, intenta deshabilitar todos los enemigos y objetos y solo deja los escuadrones y ahi probamos nuevamente.
solo nave y escuadrones con problemas... a ver que pasa.
Ok, me voy a demorar unos minutos... En cuanto lo tenga lo subo
en windows me paso lo que te pasa a vos...
comente la linea que dice invulnerable = false; y ahora puedo probar en windows bien...
me suena que si mueren antes de que peguen el primer giro, aparecen in-eternum.
:o
¿En el proceso nave() comentaste eso?
A un primo que le pedí que probara y tambien le pasa.
Comenté todos los enemigos, nubes y gran nube; solo se crean las formaciones con problemas (las que llamo looperos)
Eso si, deje todo lo demas (items, indicadores en pantalla, etc)
¿sirve asi? ¿lo subo?
Filo, me voy a acostar, asi que lo subo :P
link:
http://www.mediafire.com/?n24o1ks20by27qo
Esta compilado en modo test (fijate en el compilar_test.bat), te permite cambiar de arma con el tabulador, cambiar el poder del arma con las teclas del 1 al 4, llenarte de misiles con el 0 y ser inmortal con la espaciadora. Además se puede sacar la consola debug.
ya lo estaba haciendo yo, luego te aviso si encuentro algo...
saludos.
¡Gracias!
A todo esto, mi primo también me confirmó que en su equipo la que esta compilada con el RC19 va bien, no asi la RC20.
¡¡No estoy solooo!! jajajaja... me tiene realmente loco el bug u.u
Ahora si me marcho :P
no me doy cuenta del bug...
mira si en el proceso malo, al inicio pongo
if ( tipoMalo != MALO_LOOPERO ) return; end
aparecen los loopero y nunca falla.
ahora si comento esa linea pasa el problema...
y solo pasa en windows.
Quote from: Noivern on January 05, 2011, 07:05:26 PM
Te subo el mismo código, compilado uno con la RC19(r189) y el otro con la RC20(r200).
Ahi verás que el mismo código tiene comportamientos distintos, errático totalmente en la RC20 con los enemigos que giran en los bordes de la pantalla.
Link:
Deadly Eye: RC19(r189) vs RC20(r200) (http://www.mediafire.com/?01duk7xzcacod4j)
PD: Confirmo que el debug ahora funciona correctamente, pero solo eso :P
Lo he probado y no consigo ver diferencias, es cierto que los enemigos salen de forma distinta o en puntos distintos, pero me imagino que será por el random, pero eso podria ocurrir en la misma version ejecutada 2 veces seguida.
He puesto las 2 versiones ejecutandose en paralelo una al lado de la otra, y en el how to play todo funciona igualito, ya difiere despues en los enemigos pero será por lo comentado, las velocidades en todo me parecen identicas, y tanto en una como en otra los enemigos que van en cola, así lo hacen, y tampoco veo que se dupliquen sin fin. Tambien es cierto que con tantos enemigos es dificil visualizar algun error que exista, me imagino que para ti es mucho más fácil que para nosotros, ya que conoces todos los cantos de la casa :)
ahora tambien me pasa en linux, ahora me doy cuenta...
pero la verdad no se si es un bug de bennugd o del juego...
@Free
mira si te sucede esto -> infinitos enemigos (http://www.youtube.com/watch?v=h4Yew3qNRzc), no es normal.
-------
@Splinter
Utilizo mucho vars de tipo byte y shorts, además tengo que hacer castings en algunos calculos, ¿puede ser que esto "maree" al motor ahora?
El tipoEnemigo originalmente era un byte, ahorita no recuerdo si lo cambie a int por probar cosas.
Y hasta hace poco se mareaba más, por ejemplo en la línea 585 del enemigos.prg donde pone:
[code language="bennu"]
while (disparoRecibido = get_id(type disparo))
if (!disparoRecibido.deboMorir && (fget_dist(disparoRecibido.x, disparoRecibido.y, x, y) <= (radioColisionDisparo + radioColisionNave - 4)) )
if ( (short)((float)dañoRecibido * multiplicadorDaño[nivelDaño]) >= energia)
break;
end
//logica
end
end
[/code]
Tenía puesto esto, con lo que los enemigos esfericos (grandes y pequeños) y las naves azules gordas tambien salían infinitamente:
[code language="bennu"]
while (disparoRecibido = get_id(type disparo))
if ( (fget_dist(disparoRecibido.x, disparoRecibido.y, x, y) <= (radioColisionDisparo + radioColisionNave - 4)) )
if ( (short)((float)dañoRecibido * multiplicadorDaño[nivelDaño]) >= energia || disparoRecibido.deboMorir)
break;
end
//logica
end
end
[/code]
La idea del disparoRecibido.deboMorir esque nunca un disparo que haya chocado con un enemigo le haga daño a otro distinto. Solo los misiles, el laser y el bombazo le pueden hacer daño a multiples enemigos.
Prueba copiando el segundo fragmento de código y ahi si queda la cagá con ganas xD
Claro que lógicamente para lo que quería hacer es incorrecto, pues deja de tomar en cuenta las colisiones con el resto de los disparos en ese frame en cuanto pille uno marcado para morir. De todos modos, esto no debería reanimar a los muertos como sucedia D:
no veo quien setea dañoRecibido a los procesos Malo.
parece que hay algun problema en el motor... pero por mas que vuelvo los cambios atras no funciona... seguro que te funciona con la 189?
por otro lado, gracias a esto encontre un bug en algo de lo ultimo que meti, pero que no afecta a tu proceso porque no pasa por ahi, pero bueno, lo encontre.
Sep, en la r189 va como la seda, confirmado en 5 equipos.
El daño recibido por los malos se los asignan ellos mismos en los while como los que puse arriba. El valor de ese daño esta en los procesos disparo/splitshot/laser/misil como variable short pública. Lo hice así y no global para que fuesen levemente variables, tipo un golpe en un rpg o rts a lo warcraft 3. Luego ese daño es procesado un poco más abajo en el mismo proceso malo(), donde hago los cambios de paleta a rojo y se le resta la energia.
Por lo menos has pillado otro bug, si no hay mal que por bien no venga :D, a pensar positivo.
A mi no se me repiten los enemigos esos!!!! No encuentro diferencias.
ya encontre el bug! :D
esta en el compilador...
en el SWITCH
if (puntajeDado > 0)
if(naveObjetivo == naveId)
mostrarHealDañoPuntaje(puntajeDado, 1, fntid_osdscore, x, y);
elsif (naveObjetivo == nave2id)
mostrarHealDañoPuntaje(puntajeDado, 2, fntid_osdscore, x, y);
end
switch (tipoMalo)
case MALO_KAMIKAZE:
switch (rand(1,10
del proceso enemigo no se estaban seteando los saltos, es que corregi un if que se autoanulaba, pero parece que no debi haberlo corregido sino debi eliminarlo.
gracias!!!!
importante FIX, debo subir nueva version!
Uuuh excelente, gracias a ti man, deberian darte el nobel!! xD
Pues yo tengo un bug raro que todavia no he comentado, voy a esperar a ver si con la nueva version ya no ocurre y tiene origen en lo mismo, si no pues ya te comentaré el problema.
un nobel lo dudo... fueron errores muy estupidos, unos por no tener tiempo de probar, por eso pedia ayuda en los test, pero bueno, cuando no se puede, no se puede... y otros bugs por idiota realmente... encima estaban ahi en el codigo claritos y casi anunciandose "SOY UN BUG!"
:)
Saludos y gracias a ti por el reporte y el tiempo consumido.
wa!
Acabo de probar la r201... y sigue igual el windows :( :(
seguro?
a ver si copie mal...
pues, no, ahora no pasa...
mira que tenes que recompilar, como dije en la noticia, el bug afecta al compilador y al runtime.
Si, he recompilado, tan bruto no soy :P
Substituiste tambien el compilador ?
¡Todo!
Pesqué mi carpeta donde tengo el runtime de bennu, borré TODO, y luego descomprimí el r201 en esa misma carpeta.
yo hice lo mismo y a mi me va.
pasame el dcb que generas...
El dcb del bughunter, adjunto
este es el original?
te comento que con la version original que mandaste de los 2 fuentes, la volvi a recompilar y va de maravillas.
No, en ese se supone que salen solo los looperos
pues solo los looperos no salen...
si, tu dcb no esta generado con la ultima version...
a ver... decime que sale por la consola cuando corres bgdc y que cuando corres bgdi
debe decir...
BGDC 1.0.0 (Jan 5 2011 11:01:01)
BGDI 1.0.0 (Jan 5 2011 11:01:15)
ummm... esas fechas no me parecen correctas...
olvidate, las versiones que subi parece que no se actualizaron, o hubo algun error... ahora las resubo...
o.o!
Lo subo de nuevo, he renombrado el .prg principal para que me cree un dcb "deadly_bughunter.dcb"
Salida de consola:
(http://img257.imageshack.us/img257/8417/salidaconsola.th.png) (http://img257.imageshack.us/i/salidaconsola.png/)
--edit--
JA! Alcance a leer solo el mensaje donde me preguntabas por las fechas
Quoteummm... esas fechas no me parecen correctas...
Tienes razón, eso es ayer, el día de la r200...
por ironias de la vida, solo las 2 versiones de windows subieron mal, o hubo un problema con el renombrado de las mismas en el servidor.
Dale con el látigo a PiXeL xD
diablos!
por mas que suba las nuevas versiones, en el servidor siguen estando las viejas!!!!
shit!!!!
ajajaja este ha sido un megahipersuperultra combo de bugs, server incluido xD
supongo que es cache del server, no se, estoy subiendo con otro nombre los archivos... ya que me di cuenta que estaban saliendo mal, con doble bgd-bgd-
ahora si... ya estaba a punto de irme a llorar abrazado a mi almohada...
podes probarlo?
Puf! A mi tambien me has afectado ;D
lo se... y no te das una idea cuanto lo lamento... vaya a saber toda la gente que ya bajo la version... :(
bajando...
Ahora si!!!!
Ahora mueren los malditos y cuenta sus muertes!!!!!
:D
Como detalle en consola me sigue saliendo build del 5 de enero de 2011 a las 11:01
Ahora pruebo recompilando el juego, que probe la version bughunter :P
Me he jugado una partidita, y todo va como debe ir =)
Dentro de un rato resubo la version para wintendo, la de linux... soy un vago y esperaré a que josebita actualice su ppa :P
Karma++ por la paciencia y disponibilidad Splinter ;D
bughunter es un dcb o un prg? me refiero, recompilaste esa prueba?
¡Ambos!
Renombre el .prg principal a ese nombre, para que sea menos probable equivocarse.
Si, recompile tanto la prueba como el juego completo y como mencioné hace unos minutos ahora si mueren los malditos, y no salen infinitamente =)
fantastico!
Me tome la patudez de poner en los avances que hay que volver a bajar la última version :P
Quote from: Noivern on January 07, 2011, 12:22:13 AM
Me tome la patudez de poner en los avances que hay que volver a bajar la última version :P
muchas gracias, lo vi... a mi me daba fiaca ponerlo... gracias.
Karma a los cazadores de bugs: uno por encontrarlo y otro por solucionarlo ¿para cuando la versión en cines? esto hay que verlo con palomitas ;D
ajjajaja ya se estaba volviendo tan infinito como la serie "Lost" el hilo xD
¡Ehy! ¡Yo también quiero dar karmas sin calma! ;D
¡KARRRRRRMA!