Solucionado - Problemas compresión de mapas al pasar a 128K

For all things Churrera. ¿Estás haciendo un juego? ¿quieres proponer un cambio? ¿tienes alguna duda? ¡Cuéntanoslo!

Moderador: na_th_an

Avatar de Usuario
elborra
Mensajes: 209
Registrado: Dom, 12 Ene 2014, 14:37

Solucionado - Problemas compresión de mapas al pasar a 128K

Mensajepor elborra » Dom, 09 Mar 2014, 16:37

EDITO: Solucionado - El problema era que tenía mal configurado el cargador (loader.bas)

Buenas, acabo de darme cuenta que al cambiar al modo 128K un par de pantallas se descomprimen corruptas llegando en ocasiones a resetear el spectrum.

Al ser siempre en las 3 mismas pantallas descartaría problemas de descompresión en sí y tampoco del buffer. De hecho lo que he probado a sido la siguiente linea a compress.h al final de la función descomprimir_map

Código: Seleccionar todo

ret
.map1 BINARY "mapa_comprimido.bin  //<---"
.map BINARY "mapa_comprimido.bin"
para desplazar el binario del mapa comprimido dentro del binario del juego principal y el problema ya no sucede.

Así que lo que parece es que algo sobreescribe parte del mapa (o de los streams) durante la compilación (es esto posible siquiera?) o en tiempo de ejecución ¿no? ¿Qué puede estar ocurriendo? Las pantallas son la 45, 46 y 47 (NO son las últimas del mapa, y las siguientes en adelante también se ven correctamente). Además como digo el único cambio al pasar del modo 48k a 128k ha sido para un test (libre de otros posibles fallos) donde he activado #define MODE_128K (y los respectivos cambios minimos).

el mapa_comprimido ocupa 1821 bytes (por si sirviera de algo)
Última edición por elborra el Lun, 10 Mar 2014, 18:39, editado 2 veces en total.
Avatar de Usuario
na_th_an
Mensajes: 26412
Registrado: Vie, 09 Ene 2009, 12:18

Re: Problemas con compresión de mapas al pasar a 128K

Mensajepor na_th_an » Dom, 09 Mar 2014, 18:11

Es muy probable que sea la pila que se mete en el buffer de descompresión. Hay que tener en cuenta que hay que mover la pila a un sitio seguro. Originalmente tiene su propio lugar en la parte alta de la RAM, pero en modo 128K esta RAM es la que cambia al paginar, por lo que hay que moverla más abajo. En el caso de la Churrera, la pila se coloca justo por debajo del binario, o sea, empieza en 24199 y crece hacia abajo. Es posible que haya alguna colisión de datos.

Aún no he tenido tiempo de estudiar la modificación de Antonio para comprimir mapas y no te puedo ser de más ayuda :(
Como diría Rorshach: "Urm..."
Avatar de Usuario
elborra
Mensajes: 209
Registrado: Dom, 12 Ene 2014, 14:37

Re: Problemas con compresión de mapas al pasar a 128K

Mensajepor elborra » Dom, 09 Mar 2014, 18:54

Umm, si la pila crece hacia abajo y empieza justo antes del binario no deberia de afectar a una estructura creada dentro del código, ¿no?.

En mi caso el mapa comrimido empieza en la posicion 642 (decimal) del binario principal (el que sería churromain.bin)

Seguiré probando a cambiar cosas al medio tun tun XD a ver que resultados obtengo
Avatar de Usuario
na_th_an
Mensajes: 26412
Registrado: Vie, 09 Ene 2009, 12:18

Re: Problemas con compresión de mapas al pasar a 128K

Mensajepor na_th_an » Dom, 09 Mar 2014, 20:11

elborra escribió:Umm, si la pila crece hacia abajo y empieza justo antes del binario no deberia de afectar a una estructura creada dentro del código, ¿no?.

En mi caso el mapa comrimido empieza en la posicion 642 (decimal) del binario principal (el que sería churromain.bin)

Seguiré probando a cambiar cosas al medio tun tun XD a ver que resultados obtengo


No tiene por qué. Puedes crear una estructura donde quieras, y me suena que la rutina descompresora usaba un buffer en la parte más baja de la memoria.
Como diría Rorshach: "Urm..."
Avatar de Usuario
na_th_an
Mensajes: 26412
Registrado: Vie, 09 Ene 2009, 12:18

Re: Problemas con compresión de mapas al pasar a 128K

Mensajepor na_th_an » Dom, 09 Mar 2014, 20:13

Mirando el código veo esto:

Código: Seleccionar todo

#define DMAP_BUFFER   0x5b01


Es la situación de un buffer, supongo que de descompresión.

0x5b01 es 23297. No sé cuál será el tamaño del buffer, pero si es lo suficientemente grande colisionará con la pila. Aunque podría ser otra cosa. Si he entendido bien como funciona la compresión, el buffer debe permanecer entre descompresión y descompresión ya que necesitas datos anteriores para extraer datos nuevos. Si la pila se lo carga, o se carga parte de él, los datos del buffer necesarios para descomprimir la pantalla X puede que estén corruptos.
Como diría Rorshach: "Urm..."
Avatar de Usuario
na_th_an
Mensajes: 26412
Registrado: Vie, 09 Ene 2009, 12:18

Re: Problemas con compresión de mapas al pasar a 128K

Mensajepor na_th_an » Dom, 09 Mar 2014, 20:18

Se me ocurre algo: la rutina que pagina cosas escribía el número de la página en ese área. ¿La cambiaste para que no lo hiciera? Aparte de eso, no recuerdo nada más.
Como diría Rorshach: "Urm..."
Avatar de Usuario
elborra
Mensajes: 209
Registrado: Dom, 12 Ene 2014, 14:37

Re: Problemas con compresión de mapas al pasar a 128K

Mensajepor elborra » Dom, 09 Mar 2014, 20:53

na_th_an escribió:Se me ocurre algo: la rutina que pagina cosas escribía el número de la página en ese área. ¿La cambiaste para que no lo hiciera? Aparte de eso, no recuerdo nada más.

Si, si que lo hice :? . El tema es que sólo ocurre en esas 3 pantallas (no sucede ni con las anteriores ni las posteriores). Si dependiera exclusivamente de la pila sucedería aleatoriamente. Moviendo el binario de posición (con parches) las pantallas con error se desplazaban.

El buffer es del tamaño de una pantalla, es decir 150 bytes (o 117 en mi caso)

Por mi parte estoy tratando de hacer algo parecido a compressed_levels, reservando una variable de tamaño máximo vacia tipo mapa[] (el mapa nunca sería de más bytes), recomprimir el mapa con apack y pasarlo por librarian.exe. En definitiva luego recuperaria el mapa con get_resource con destino en mapa. Por último sería hacer que la rutina de anronio buscara en esa dirección. He hecho los cambios que creia necesarios, pero el resultado no ha sido el deseado (de hecho no me carga siquiera el juego XD)
Avatar de Usuario
na_th_an
Mensajes: 26412
Registrado: Vie, 09 Ene 2009, 12:18

Re: Problemas con compresión de mapas al pasar a 128K

Mensajepor na_th_an » Dom, 09 Mar 2014, 22:09

Échale un vistazo a goku mal y léete whatsnew.txt. Luego pregúntame las dudas ;) Lo digo porque a lo mejor te sirve... No es exactamente lo que tú tienes, pero puedes mirar cómo se hace para sacar los datos de la RAM extra y ponerlos en las estructuras de RAM convencional.
Como diría Rorshach: "Urm..."
Avatar de Usuario
elborra
Mensajes: 209
Registrado: Dom, 12 Ene 2014, 14:37

Re: Problemas con compresión de mapas al pasar a 128K

Mensajepor elborra » Dom, 09 Mar 2014, 23:22

na_th_an escribió:Échale un vistazo a goku mal y léete whatsnew.txt. Luego pregúntame las dudas ;) Lo digo porque a lo mejor te sirve... No es exactamente lo que tú tienes, pero puedes mirar cómo se hace para sacar los datos de la RAM extra y ponerlos en las estructuras de RAM convencional.

Ya estoy usando la ram extra para varios menesteres (usando como bien dices el ejemplo de goku mal), pata tittle,marco,ending, los conjuntos de tiles que forman los tileset y para sets de sprites y ahora estaba intentando pasar el mapa; que es cuando me dí cuenta del problema de las pantallas, volví hacia atrás (sin ponerlo en ram extra) pero pasa lo mismo, volví más atrás por verificar (a modo 48K) y ya funcionaban correctamente.

Es una gozada el espacio de ram extra :D
antoniovillena
Mensajes: 494
Registrado: Jue, 24 Oct 2013, 15:52

Re: Problemas con compresión de mapas al pasar a 128K

Mensajepor antoniovillena » Dom, 09 Mar 2014, 23:27

Puedes guardar snapshots (.z80 ó .sna) donde se vean esas 3 pantallas corruptas y subirlos por aquí. A lo mejor así damos con el error.

Volver a “La Churrera”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado