Página 1 de 3

Problema al morir

Publicado: Lun, 28 Sep 2015, 19:14
por karkayu
Buenas again!!!

Tengo un problemilla que me tiene bastante descolocado.
El juego funciona bien peeeero cuando el prota muere el juego no termina correctamente.La mayoría de los casos reinicia la maquina, pero otras veces aparece codigo en pantalla y se cuelga.
Eso es algo que ha sucedido tras añadir/cambiar algo porque, esta claro que antes no lo hacía.

Cosas que he probado:
- Como estuve tocando engine.h para solucionar lo del tiempo y el sonido al finalizar el juego, he cambiado ese archivo por otro 'virgen' (el que traía por defecto la churrera en el zip).
- He reducido el número de tiles por si fuera problema de memoria. Incluso los he vuelto a pasar a B/N.
- He puesto un archivo de scripts vacio por si fuera problema de los scripts (aunque no toco el archivo .spt desde hace tiempo)
- He dejado extern.h vacío

Pero todo sigue igual.

¿Alguna idea de que puede ser?

Solucionado: Es problema de memoria. El juego se pasa en casi 300bytes del limite permitido.

Re: Problema al morir

Publicado: Lun, 28 Sep 2015, 21:43
por karkayu
Curioso. He quitado la recarga de vida en el juego (tanto objetos en sí como la variable PLAYER_REFILL a 0) y parece que todo ha vuelto a la normalidad.

Re: Problema al morir

Publicado: Mar, 29 Sep 2015, 10:23
por na_th_an
(Reducir o simplificar los tiles no ahorra memoria, los tiles tienen un tamaño fijo de 2304 bytes, lo que ocupan 256 caracteres y 256 atributos).

Cualquier cuelgue por lo general implica algo saliéndose de madre y escribiendo donde no debe. ¿Cuánto ocupa tu binario? ¿Qué versión de la Churrera estás usando? ¿Cómo está configurada la memoria al principio del archivo .c?

Re: Problema al morir

Publicado: Mar, 29 Sep 2015, 14:26
por karkayu
$this->bbcode_second_pass_quote('na_th_an', '(')Reducir o simplificar los tiles no ahorra memoria, los tiles tienen un tamaño fijo de 2304 bytes, lo que ocupan 256 caracteres y 256 atributos).

Cualquier cuelgue por lo general implica algo saliéndose de madre y escribiendo donde no debe. ¿Cuánto ocupa tu binario? ¿Qué versión de la Churrera estás usando? ¿Cómo está configurada la memoria al principio del archivo .c?



Al tileset le hacia falta un buen repaso. Era algo que tenía que hacer tarde o temparno. Tenía tiles antiguos que no usaba y me molestaban.

- El archivo .tap actual (que funciona sin problemas tanto en emu como en maquina real) ocupa 42.8Kb
- Version 3.99.3c
- No he tocado nada en el archivo .c Está todo como viene por defecto. Tampoco he activado el modo 128K.

Como he comentado antes, sin la recarga de vida el juego rula bien. A las malas doy un poco más de vida al inicio y paso de las recargas.

Re: Problema al morir

Publicado: Mar, 29 Sep 2015, 14:38
por na_th_an
No sirve de nada saber cuánto ocupa el tap completo. Lo importante es saber cuanto ocupa el binario del juego, lo que se carga y se ejecuta. Es fácil mirarlo desde el emulador con el visor de bloques de la cinta: es el último bloque.

En teoría no debería sobrepasar los 36K "mucho". De todos modos viendo que la cinta ocupa 42.8K y que la pantalla de carga son aproximadamente 6.25K, yo diría que está "ahí ahí"... Si tu binario ocupa demasiado, hay solapamiento con la zona de memoria reservada para la pila. Esto causa todo tipo de cosas divertidas: o bien se te corrompen los sprites, o bien a la salida de una subrutina el control salta a sabe dios.

Ok, si usas la versión "c" la memoria dinámica que se reserva siempre es la máxima así que no es un problema de que no estés reservando la suficiente memoria para los sprites.

Cuando dices que quitas o pones las recargas ¿a qué te refieres en concreto? Si te refieres a activar o desactivar "USE_HOTSPOTS_TYPE_3" tiene sentido, porque si los activas el código es más largo.

Dependiendo de cuanto "te hayas pasado" (si este es el problema) podrías echar esto a andar con la versión "d" de desarrollo que te puse antes. Puedes ahorrar bastante memoria (bastante me refiero a un cuarto de K o algo así, pero suele ser suficiente), además de apretar un poco más la pila y dejar más espacio, por lo que a lo mejor te salva el culete :)

Re: Problema al morir

Publicado: Mar, 29 Sep 2015, 17:12
por karkayu
$this->bbcode_second_pass_quote('na_th_an', 'N')o sirve de nada saber cuánto ocupa el tap completo. Lo importante es saber cuanto ocupa el binario del juego, lo que se carga y se ejecuta. Es fácil mirarlo desde el emulador con el visor de bloques de la cinta: es el último bloque.

En teoría no debería sobrepasar los 36K "mucho". De todos modos viendo que la cinta ocupa 42.8K y que la pantalla de carga son aproximadamente 6.25K, yo diría que está "ahí ahí"... Si tu binario ocupa demasiado, hay solapamiento con la zona de memoria reservada para la pila. Esto causa todo tipo de cosas divertidas: o bien se te corrompen los sprites, o bien a la salida de una subrutina el control salta a sabe dios.

Ok, si usas la versión "c" la memoria dinámica que se reserva siempre es la máxima así que no es un problema de que no estés reservando la suficiente memoria para los sprites.

Cuando dices que quitas o pones las recargas ¿a qué te refieres en concreto? Si te refieres a activar o desactivar "USE_HOTSPOTS_TYPE_3" tiene sentido, porque si los activas el código es más largo.

Dependiendo de cuanto "te hayas pasado" (si este es el problema) podrías echar esto a andar con la versión "d" de desarrollo que te puse antes. Puedes ahorrar bastante memoria (bastante me refiero a un cuarto de K o algo así, pero suele ser suficiente), además de apretar un poco más la pila y dejar más espacio, por lo que a lo mejor te salva el culete :)



¿te puedes creer que no encuentro la opción de bloques de cinta que dices en el emulador? Uso el Fuse.

En cuanto a lo de las recargas me refiero a que tenia activado USE_HOTSPOTS_TYPE_3, colocados 'corazones' por diversas parte del mapa y la constante PLAYER_REFILL con un valor mayor a 0.
Como no me acordaba de USE_HOTSPOTS_TYPE_3 hasta que me lo has dicho, no la tenía desactivada. Pero es curioso porque si borro los 'corazoncitos' del mapa y coloco a cero la constante PLAYER_REFILL (sin desactivar USE_HOTSPOTS_TYPE_3), el juego rula bien.
Si desactivo USE_HOTSPOTS_TYPE_3 y PLAYER_REFILL, me da error de compilacion: "mainloop.h" L:636 Error:#42:Unknown symbol: PLAYER_REFILL
Si desactivo USE_HOTSPOTS_TYPE_3 y dejo PLAYER_REFILL, el juego vuelve a colgarse al morir (aunque no haya corazoncitos por el mapa).

Probaré a usar la versión "d" e intentaré averiguar lo de los bloques de cinta (más que nada para saber cuando me paso).

Gracias :)

Re: Problema al morir

Publicado: Mar, 29 Sep 2015, 18:22
por na_th_an
Ni idea, no uso fuse. En Spectaculator o Spin hay opciones de "tape browser" y cosas así. Estoy seguro de que Fuse debe tener algo parecido. Debe haber una forma de, por ejemplo, cargar un juego que no sea el primero en una cinta recopilatoria :)

Puede ser cualquier cosa. Yo lo achaco a un problema de memoria porque suele ser lo más habitual. Si tu binario es demasiado grande, hay cosas que se solapan. splib2 pone sus cosas al final de la memoria, y justo debajo la pila y el motor pone la memoria de los sprites al final del binario. Si el binario llega demasiado arriba puede corromper la pila o la pila puede corromper los sprites. Todo lo demás pueden ser efectos secundarios. Lo que te pasa quizá es sólo pseudo-azar, y en ese caso no es un comportamiento que nos indique donde puede estar el error - por eso lo mejor es primero descartar que no nos estemos colando.

También podría ser un bug en el código, oye, pero eso me resulta más raro porque ya hay muchos juegos que usan la 3.99.3c y aún no ha surgido nada parecido - pero siempre puede ser la primera vez.

Mi consejo a la hora de empezar un juego es que prioricemos. Es más importante un motor más complejo o un mapa más grande que una super pantalla de título o de final. Por eso nosotros solemos empezar los juegos con dichas pantallas en su mínima expresión. Una vez está todo el motor montado con lo que queremos, y el script completado y funcionando, vemos cuánto nos queda libre para las florituras. Entonces ponemos la pantalla de título, el final, la música más larga o más pantallas. Pero lo primero es lo primero.

Lo digo porque los últimos cinco o seis juegos que habéis empezado han tenido el mismo problema :D

Re: Problema al morir

Publicado: Mar, 29 Sep 2015, 18:54
por karkayu
$this->bbcode_second_pass_quote('na_th_an', 'N')i idea, no uso fuse. En Spectaculator o Spin hay opciones de "tape browser" y cosas así. Estoy seguro de que Fuse debe tener algo parecido. Debe haber una forma de, por ejemplo, cargar un juego que no sea el primero en una cinta recopilatoria :)

Puede ser cualquier cosa. Yo lo achaco a un problema de memoria porque suele ser lo más habitual. Si tu binario es demasiado grande, hay cosas que se solapan. splib2 pone sus cosas al final de la memoria, y justo debajo la pila y el motor pone la memoria de los sprites al final del binario. Si el binario llega demasiado arriba puede corromper la pila o la pila puede corromper los sprites. Todo lo demás pueden ser efectos secundarios. Lo que te pasa quizá es sólo pseudo-azar, y en ese caso no es un comportamiento que nos indique donde puede estar el error - por eso lo mejor es primero descartar que no nos estemos colando.

También podría ser un bug en el código, oye, pero eso me resulta más raro porque ya hay muchos juegos que usan la 3.99.3c y aún no ha surgido nada parecido - pero siempre puede ser la primera vez.

Mi consejo a la hora de empezar un juego es que prioricemos. Es más importante un motor más complejo o un mapa más grande que una super pantalla de título o de final. Por eso nosotros solemos empezar los juegos con dichas pantallas en su mínima expresión. Una vez está todo el motor montado con lo que queremos, y el script completado y funcionando, vemos cuánto nos queda libre para las florituras. Entonces ponemos la pantalla de título, el final, la música más larga o más pantallas. Pero lo primero es lo primero.

Lo digo porque los últimos cinco o seis juegos que habéis empezado han tenido el mismo problema :D



Se agradecen todos los consejos :)

En realidad el juego ya esta acabado. Lo que ocurre es que me han 'convencido' `para presentarlo ala ZXDEV 2015 y como lo veo muy 'soso' estoy intentando mejorar cosillas.


Voy a buscar otro emu que me permita ver lo de la memoria.

EDITO: He usado el SPIN y obtengo lo que se ve en el archivo adjunto. Va a se que me quedo sin memoria.

Re: Problema al morir

Publicado: Mié, 30 Sep 2015, 08:11
por na_th_an
Sí, te estás pasando casi 300 bytes. Creo que el límite, si mal no recuerdo, era 36655.

Es posible que lo podamos solucionar con la 3.99.3d, y es seguro que se arregla con MK2. Si te animas a portar tu juego a cualquiera de las dos, silba :D.

Re: Problema al morir

Publicado: Mié, 30 Sep 2015, 10:25
por karkayu
$this->bbcode_second_pass_quote('na_th_an', 'S')í, te estás pasando casi 300 bytes. Creo que el límite, si mal no recuerdo, era 36655.

Es posible que lo podamos solucionar con la 3.99.3d, y es seguro que se arregla con MK2. Si te animas a portar tu juego a cualquiera de las dos, silba :D.



He reducido un poco el archivo de scripts y se me ha quedado en 36834Bytes. La melodía inicial que le he puesto es larguilla y parece que eso me ha quitado bytes. Por ahí también puedo recortar.

Como digo el juego va (o al menos no veo que haga nada raro las veces que lo he probado) pero me gustaría meterle un par de extern.

Por otro lado, anoche hice el cambio a la version "d" de la churrera. Cambié/actualicé los archivos necesarios y compilé sin problemas. Creo recordar que apenas ahorraba 100-150 bytes. El problema es que el juego no pasa de la pantalla de titulo. Sale dicha pantalla (con la melodia correspondiente) pero no entra en el juego en sí (se cuelga) elija la opción que elija. Tendré que revisarlo a fondo esta tarde/noche.

¿Con el MK2 sigo los mismo pasos que con la Churrera o tengo que hacer algo 'especial' para portar el juego?

Gracias por la ayuda :)