Temas AGD

[pser1]

Hola,
la forma mas simple sería esta. Solo para textos que no rebasen la longitud de una línea, a ver si puedo hacer que se porte bien como con
letras normales ...
De momento solo el pantallazo
saludos

LETRAS GRANDES.jpg (55.64 KiB) Visto 176 veces

[pser1]

Hola,
esta versión soporta tanto letra normal como doble altura con la longitud que sea ...
No he necesitado la rutina especial para letras grandes del motor MC6847. En su lugar he adaptado la usada para letras normales
y también la rutina NEXTLINE de forma que ambas respetan el valor de la variable que controla la altura de las letras.
Los ficheros fuente .ASM son versiones de trabajo, con bastantes líneas comentadas para hacer diferentes pruebas ...
Desafortunadamente este juego (SPRINGBOT) tiene la zona de letras minúsculas sobrescrito con código para realizar sonidos especiales
saludos

AGDDISK-vB2.ZIP

(241.28 KiB) Descargado 7 veces

LETRAS GRANDES MULTILINEA.jpg (61.69 KiB) Visto 173 veces

[jimbobaby]

Hola,
esta versión soporta tanto letra normal como doble altura con la longitud que sea ...
No he necesitado la rutina especial para letras grandes del motor MC6847. En su lugar he adaptado la usada para letras normales
y también la rutina NEXTLINE de forma que ambas respetan el valor de la variable que controla la altura de las letras.
Los ficheros fuente .ASM son versiones de trabajo, con bastantes líneas comentadas para hacer diferentes pruebas ...
Desafortunadamente este juego (SPRINGBOT) tiene la zona de letras minúsculas sobrescrito con código para realizar sonidos especiales
saludos
AGDDISK-vB2.ZIPLETRAS GRANDES MULTILINEA.jpg

Mola!!

[pser1]

Hola,
visto que funciona correctamente tanto con letra normal como con letras de doble altura, voy a dejar como resuelto el tema de los mensajes
de texto. Puede que le eche una ojeada final al tema de color de fondo y tinta como llegué a permitir para el MC6847 en cuatro colores
usando una variable con un nombre como 'andeor' (de 16 bits) que servía para modificar ambos colores. No se si podría hacerse algo parecido
aquí con el rollito añadido de los bitplanes ...
Supongo que sería un buen momento para revisar y definir mejor la estructura de datos de los sprites y ya de paso implementar las rutinas
que tenemos en el motor para el MC6847. Esto permitiría mover al jugador, cosa que sería un gran paso!
saludos

AGDDISK-vB3.ZIP

(240.2 KiB) Descargado 6 veces

TextosAGDfinal.jpg (55.43 KiB) Visto 165 veces

[pser1]

para acabar con el tema de los textos en colores, he implementado un sistema que permite definir un color para Tinta y otro para Papel
El pantallazo adjunto muestra los dos textos en dos colores
saludos

AGDDISK-vB4.ZIP

(241.75 KiB) Descargado 7 veces

TINTAyPAPEL.jpg (56.06 KiB) Visto 162 veces

[jimbobaby]

para acabar con el tema de los textos en colores, he implementado un sistema que permite definir un color para Tinta y otro para Papel
El pantallazo adjunto muestra los dos textos en dos colores
saludos
AGDDISK-vB4.ZIPTINTAyPAPEL.jpg

Hola Pere

Es una tonteria (bueno, en realidad son dos ), pero probando la build B4, de puñetera casualidad me he encontrado con un bug que corrompe los sprites

Capture.JPG (69.52 KiB) Visto 157 veces

Basicamente me ocurre cuando le doy a la tecla de pausa. No siempre, claro, depende del momento exacto cuando se haga. Ya digo, lo he visto de chiripa. El programa no se cuelga ni nada, tan solo va "corrompiendo" los datos del sprite, pero sales de la pausa y los sprites se mueven normal, solo que se ven rarunos

Tirando para atras, he visto que el pete aparece en la build A2, y en la A1 no me pasaba. Comparando ambos, y haciendo pruebas, creo que es porque el handler de FIRQ lo cambiaste de push a/pop a a usar b sin guardar en la pila. Si hago el cambio de hacer push /pop de b, se arregla.

Ademas de eso, y solo como comentario, si pulsas break (ESC) en mitad de la carga, se cuelga . Pero vamos, que si lo piensas tiene toda la logica, claro

[pser1]

Hola Pere
Es una tonteria (bueno, en realidad son dos ), pero probando la build B4, de puñetera casualidad me he encontrado con un bug que corrompe los sprites
Capture.JPG
Basicamente me ocurre cuando le doy a la tecla de pausa. No siempre, claro, depende del momento exacto cuando se haga. Ya digo, lo he visto de chiripa. El programa no se cuelga ni nada, tan solo va "corrompiendo" los datos del sprite, pero sales de la pausa y los sprites se mueven normal, solo que se ven rarunos
Tirando para atras, he visto que el pete aparece en la build A2, y en la A1 no me pasaba. Comparando ambos, y haciendo pruebas, creo que es porque el handler de FIRQ lo cambiaste de push a/pop a a usar b sin guardar en la pila. Si hago el cambio de hacer push /pop de b, se arregla

Efectivamente, llevo viendo este bug desde hace bastantes versiones, pero al ser casi aleatorio me mosquea pero no del todo
Pensándolo bien, me he dado cuenta de que estamos usando FIRQ para 'evitar' que Break cuelgue el programa.
El problema es que un FIRQ es eso, un IRQ rápido que no guarda los registros en el stack. Si recuerdo bien solamente guarda cc,dp,pc
Como podemos pulsar Break en cualquier momento, si pillamos el programa en mitad del pintado/borrado de un sprite, dentro de la rutina
de tratamiento de los FIRQ se modifican registros que *pueden* ser vitales para cuando retorne el control al punto donde estaba dibujando
Así que he añadido un pshs a,b a la entrada con todos los registros, que se restauran a la salida. Además Dmsg ya salva la totalidad de registros
para evitar problemas. Espero que con esto se acabe el problema mencionado.

Ademas de eso, y solo como comentario, si pulsas break (ESC) en mitad de la carga, se cuelga . Pero vamos, que si lo piensas tiene toda la logica, claro

Cuando dices en mitad de la carga, ¿Te refieres a cualquier momento antes de mostrarse la pantalla de juego? Si es así pues estamos fritos ya que todavía no se ha sustituido la rutina ISR para FIRQ. Solución, manos quietas
saludos

[pser1]

Hola,
he hecho una prueba mas, creo haber visto en alguna parte caracteres pintados en dos colores, diferenciando la parte superior de la mitad inferior
No se gana demasiado, pero es factible con poco esfuerzo. Además poniendo los mismos valores en dos juegos de variables se pueden
mostrar caracteres en un solo color sobre el fonfo deseado ...
Adjunto AGDDISK-vB5 que además corrige el bug que detectó jimbobaby, arreglado con su solución. Muchas gracias
saludos

AGDDISK-vB5.ZIP

(242.63 KiB) Descargado 7 veces

Letras Bicolor.jpg (55.68 KiB) Visto 153 veces

[pser1]

por cierto, sobre el comentario de jimbobaby sobre la acción de la tecla Break (Escape)
En los motores AGD, la función de PAUSA se lleva a cabo detectando una tecla, sea fire2, fire3 o bien alguna de las teclas de opción (1-2-3-4)
Cuando hagamos esto, dentro del bucle principal, ya no incordiaremos el pintado de sprites, pero nos encontraremos con que Break
sigue activo y bloquearía el programa. Supongo que poniendo una ISR para FIRQ que solamente contenga un opcode 'rti' sería mas que
suficiente para evitar el cuelgue. Pero hay que sustituir la ISR estándar y al cargar el programa se harán muchas cosas antes de que
podamos poner nuestra ISR, por ejemplo
- cargar pantalla de presentación
- cargar panel de datos si lo hay. En SPRINGBOT hay uno
- cargar los datos con AGDLOAD y enviarlos a su destino
Finalmente cargar AGDCODE (motor mas programa) donde podremos bloquear a BREAK
saludos

[jimbobaby]

Efectivamente, llevo viendo este bug desde hace bastantes versiones, pero al ser casi aleatorio me mosquea pero no del todo

Pos diloooo, que estamos entre amigos

Cuando dices en mitad de la carga, ¿Te refieres a cualquier momento antes de mostrarse la pantalla de juego? Si es así pues estamos fritos ya que todavía no se ha sustituido la rutina ISR para FIRQ. Solución, manos quietas

Efectivamente, en mitad de la carga le di sin querer . Ahora que tenemos una rutina super molona de pintar textos podriamos pintar ese, un "loading, please manos quietas"



PD: lo del mensaje es broma eh, que te veo capaz

[pser1]

Pos diloooo, que estamos entre amigos

No quería amargaros el finde

Efectivamente, en mitad de la carga le di sin querer . Ahora que tenemos una rutina super molona de pintar textos podriamos pintar ese, un "loading, please manos quietas" PD: lo del mensaje es broma eh, que te veo capaz

No me provoques
En la carga, que se hace desde el programa Basic, ya suele pintarse algún mensaje utilizando el sistema ya que el motor todavía no está
disponible. Ya iremos viendo, igual con un poco de suerte nos sorprende malikto999 con alguna solución que ni se nos ha pasado por la cabeza
saludos

[jimbobaby]

En la carga, que se hace desde el programa Basic, ya suele pintarse algún mensaje utilizando el sistema ya que el motor todavía no está
disponible. Ya iremos viendo, igual con un poco de suerte nos sorprende malikto999 con alguna solución que ni se nos ha pasado por la cabeza

Bueno, he estado revisando un poco mas el tema (si, ya se que es una tonteria), y el momento donde falla es cuando apretas break mientras esta ejecutando agdload.asm. Con la punteria que estoy teniendo hoy ya podria irme a una tombola a ver que cae

O sea, mientras esta el basic haciendo la carga de ambos ficheros, si apretas break en el momento que no esta dentro de los loadm, te hace un.. break .
Mientras esta con los loadm, el break no hace nada.
Pero si apretas break en el espacio de tiempo en que se ejecuta agdload, ka-boom.

La "solucion" al "no problema" , es simplemente poner un orcc #$50 nada mas empezar agdload.asm (bueno, si es la segunda instruccion tampoco creo que pasase nada ). Y lo mismo en el agdcode, mover el orcc que hay ahora al principio para evitar la posibilidad.

Es una chorrada como un piano, lo se lo se...

[pser1]

Bueno, he estado revisando un poco mas el tema (si, ya se que es una tonteria), y el momento donde falla es cuando apretas break mientras esta ejecutando agdload.asm. Con la punteria que estoy teniendo hoy ya podria irme a una tombola a ver que cae
O sea, mientras esta el basic haciendo la carga de ambos ficheros, si apretas break en el momento que no esta dentro de los loadm, te hace un.. break .
Mientras esta con los loadm, el break no hace nada. Pero si apretas break en el espacio de tiempo en que se ejecuta agdload, ka-boom.
La "solucion" al "no problema" , es simplemente poner un orcc #$50 nada mas empezar agdload.asm (bueno, si es la segunda instruccion tampoco creo que pasase nada ). Y lo mismo en el agdcode, mover el orcc que hay ahora al principio para evitar la posibilidad.
Es una chorrada como un piano, lo se lo se...

Pues lo he implementado en la versión que adjunto aquí.
He estado haciendo algunas simplificaciones de código, especialmente en PChar para unificar algo de código en las cuatro posibilidades
que se pueden presentar.
Además pongo aquí el MAPA de memoria actual del AGDDISK, incluyendo también las páginas mapeadas tanto en AGDLOAD como en AGDCODE
Hasta aquí he llegado con la, llamémosle demo de SPRINGBOT, ahora tomaré los motores tanto de B/N (MC6847) como el de colores (V9958)
y los separaré en partes en función del cometido de las funciones
Configuración, BuclePrincipal, Pantallas/Patrones, Objetos, Sprites, Movimiento, Menu/Inventario, Efectos/Música, Shrapnel (Metralla)
como Laser,Explosiones y otros. Seguro que me he olvidado alguno, pero ya saldrá cuando los descomponga en partes ...
Habiendo visto que en ShounenMike se utiliza para la CPU principal la página $F0 como página directa, adoptaré el mismo valor ya que
corresponde a una zona que nunca se mapea a nada. Para el Subsistema tal vez podríamos usar $D4 como en el juego por acelerar los
accesos al área de I/O. Ya iremos viendo ... Ahora ya arranca la conversión del motor AGD, sin vuelta atrás
saludos

AGDDISK-vC1.ZIP

(243.28 KiB) Descargado 8 veces

_AGD-FM77AV2 MEMORY MAP.ZIP

(1.03 KiB) Descargado 8 veces

[jimbobaby]

Ahora ya arranca la conversión del motor AGD, sin vuelta atrás

Eso, hasta ahora era un precalentamiento para que el motor coja temperatura...

El mapa esta muy bien, muy claro y organizado, si señor. Me pongo el sombrero para podermelo quitar

[jltursan]

Pintaza que tiene todo esto

Si está por ahí el código del Springbot, me gustaría echarle un ojo para trabajar un poco el tema de los gráficos y tal. Desempolvaría también un conversor que hice hace siglos para generar un mapa "Tiled" a partir del original AGD, que siempre viene bien verlo con una herramienta moderna

[pser1]

Pintaza que tiene todo esto
Si está por ahí el código del Springbot, me gustaría echarle un ojo para trabajar un poco el tema de los gráficos y tal. Desempolvaría también un conversor que hice hace siglos para generar un mapa "Tiled" a partir del original AGD, que siempre viene bien verlo con una herramienta moderna

Hola, José Luis
adjunto aquí tanto el fuente AGD como los ficheros que resultan de la compilación con el motor B/N para MC6847 en un fichero zip
Y en otro lo mismo pero para el V9958 a 16 colores, ya iremos hablando!
saludos

Pd si he olvidado alguna cosa, dímelo y buscaré entre mis archivos!

SPRINGBOT-V9958.ZIP

(386.53 KiB) Descargado 8 veces

SPRINGBOT-MC6847.ZIP

(295.47 KiB) Descargado 8 veces