Problema al morir

[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.

[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.

[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?

[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?

[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

[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

[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

[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

[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 .

[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 .