BLASTARDO (o Cutridium II si Cutridium I hubiera nacido)

Hola de nuevo.
Sin animo de ser pesado (que lo soy), dejarme crear este hilo, similar a uno en ZDP, donde empezo esta cosa rara.
Pero antes de nada, agradecer a SYX el apoyo resolviendo dudas y problemas.
Y a Mode2 por haber sido "mis manos y mis ojos" probando las primeras versiones en su CPC!
Animado por una mini-quedada con los Vintagenarios valencianos, y aprovechando que mi visita al paro da de si mas de lo esperado, decidi retomar a principios de Febrero "game.asm", proyecto descontinuado hace... 25 años.

Como mi cabecita no da para mucho, lo primero fue desliar el cacao mental de ensambladores: z80-68000 y 8086 se unificaron en un unico lenguaje, la mar de chulo, que por desgracia no existe (no busqueis el opcode de multiplicacion en el z80... sere gili!)
Tras adoptar mentalidad "Z80 Inside", toco desliar la memoria de pantalla (mas de lo mismo... aqui ni hay bitplanes ni "un byte un pixel", ni Maquiavelo la hubiera diseñado mejor).

El juego en si es muy primitivo, estoy en pruebas del codigo, con un mapeado sencillo y tres bichos que disparen, me vale de momento.
Hoy por hoy es mas divertida la pantalla menu-presentacion que el juego en si (las bolitas con un poco de arte las puedes botar, botar a dos manos, golpear de cabeza, levantarlas de suelo... intentare meterlas en el juego real cuando libere tiempo)
La cosa que ahora ya tengo mi embrion, con su scroll del "mapa de juego", rutina(s) de sprites, animaciones, pseudo fisica y pseudo inteligencia... y gracias a Arkos y su tracker, hasta musiquilla y to.

Solo puedo asegurar que correra a 50fps y habra version cinta para el 464.
Pues eso, que como estoy mas feliz que una perdiz inicio este hilo, y pido a los amantes del "low level CPC" que no se corten en postear lo que les de la gana aqui.

ULTIMA VERSION EN MI FIRMA



EL "BUG":
Cuando haces scroll hardware con Amstrad, cosas muy AGRADABLES-DESAGRADABLES suceden.
La peor: en cualquier lugar de la pantalla, las direcciones se "resetean".
La rutina que gestiona este "wrap" es EXASPERANTEMENTE LENTA para poder mantener los 50fps si un sprite, solo uno, cayera en medio de el.
El programa detecta si estamos ANTES o DESPUES del wrap, en el segundo caso corrige los punteros. Pero no llamo a la rutina lenta si estamos EN MEDIO del wrap. Por eso, aparecen "manchas" cuando movemos el Invader por la parte baja de la pantalla tras hacer un ratito de scroll. La rutina que actualiza el fondo SI TIENE EN CUENTA EL WRAP (puede dar por supuestas unas condiciones que agilizan la deteccion del cambio de memoria sin apenas coste).
Pero, si el problema esta ahi, quiero 50fps y la rutina sprite "estoy en medio del wrap" no permite 50fps, que hacer?? LO "TAPARE" CON EL DISEÑO DEL MAPA.
Por ahora, paciencia con los manchones!

Gracias a todos.

[litos.net]

Pues tiene muy buena pinta. La idea es buena y divertida. Si conservase esa velocidad en la versión final... estaría guay.
No lo dejes.

Acabo de probarlo y tiene una pinta estupenda. Ánimo y adelante.

Hola de nuevo.
Sin animo de ser pesado (que lo soy), dejarme crear este hilo, similar a uno en ZDP, donde empezo esta cosa rara.

Anda ya, se agradecen hilos así de interesantes, además hacen falta más "pesaos" para que mis tonterías puedan pasar más desapercibidas

Pero antes de nada, agradecer a SYX el apoyo resolviendo dudas y problemas.

No hay de que, siempre es un placer poder ayudar a todo el que lo necesite... además, salimos ganando con un futuro juego, que encima hace un buen uso de la máquina, que más se puede pedir

Como mi cabecita no da para mucho, lo primero fue desliar el cacao mental de ensambladores: z80-68000 y 8086 se unificaron en un unico lenguaje, la mar de chulo, que por desgracia no existe (no busqueis el opcode de multiplicacion en el z80... sere gili!)
Tras adoptar mentalidad "Z80 Inside", toco desliar la memoria de pantalla (mas de lo mismo... aqui ni hay bitplanes ni "un byte un pixel", ni Maquiavelo la hubiera diseñado mejor).

Añade el ARM a esa ecuación y entenderás porque estoy tan hecho polvo

Solo puedo asegurar que correra a 50fps y habra version cinta para el 464.

Ya leí en el otro hilo las premisas, por lo que ya tengo una mejor idea de lo que pretendes

Pues eso, que como estoy mas feliz que una perdiz inicio este hilo, y pido a los amantes del "low level CPC" que no se corten en postear lo que les de la gana aqui.

Tú eres quien lo ha dicho, eh!!!!, que conste en acta

Con respecto al "bug" de los sprites, la solución es esa, mirar con antelación y hacer uso de la rutina "lenta" para esos casos y por supuesto parte de la gracia está en "restringir" el diseño a las limitaciones del hardware... si pudieses permitirte el lujo de un doble buffer, podrías hacer la "tonterida" de ir alternándolos cuando se produce el "reinicio" de las direcciones en uno de ellos y así evitarías tener que hacer uso de la rutina lenta.

Una cosa que he visto, es que sueles abusar mucho de los registros indices, ten en cuenta que IX e IY son instrucciones muy glotonas de cpu y ram, intenta reducir su uso a la mínima expresión, siempre es más conveniente tirar del banco de registros secundario cuando se te agoten los registros principales. Por ejemplo, me he encontrado este código:

Código: Seleccionar todo

    LD   IX,$44B5
    LD   (IX + $1B),$F3
    LD   (IX + $1D),$01
    LD   (IX + $1A),$FC
    LD   IX,$44E8
    LD   (IX + $1B),$F2
    LD   (IX + $1D),$01
    LD   (IX + $1A),$FD
    LD   IX,$451B
    LD   (IX + $1B),$F1
    LD   (IX + $1D),$01
    LD   (IX + $1A),$FE
    LD   IX,$454E
    LD   (IX + $1B),$F0
    LD   (IX + $1D),$01
    LD   (IX + $1A),$00
    LD   IX,$4581
    LD   (IX + $1B),$F1
    LD   (IX + $1D),$01
    LD   (IX + $1A),$02
    LD   IX,$45B4
    LD   (IX + $1B),$F2
    LD   (IX + $1D),$01
    LD   (IX + $1A),$03
    LD   IX,$45E7
    LD   (IX + $1B),$F3
    LD   (IX + $1D),$01
    LD   (IX + $1A),$04

Total 28 * 4 = 112 bytes

Esta claro que es una inicialización, vamos que no es nada crítico, pero fíjate lo que ocurre si tratamos de minimizar el uso de IX:

Código: Seleccionar todo

    LD   IX,$44B5
    LD   HL,tabla_de_inicializacion
    LD   DE,$33         ; Incremento para pasar entre estructuras
    LD   B,7
bucle_de_inicializacion
    LD   A,(HL)
    INC  HL
    LD   (IX + $1B),A
    LD   A,(HL)
    INC  HL
    LD   (IX + $1D),A
    LD   A,(HL)
    INC  HL
    LD   (IX + $1A),A
    ADD  IX,DE
    DJNZ bucle_de_inicializacion

tabla_de_inicializacion
    DEFB $F3,$01,$FC
    DEFB $F2,$01,$FD
    DEFB $F1,$01,$FE
    DEFB $F0,$01,$00
    DEFB $F1,$01,$02
    DEFB $F2,$01,$03
    DEFB $F3,$01,$04

Total 54 bytes

Acabamos de reducirlo a menos de la mitad y sigue siendo igual de entendible. Pero todavía podemos rizar más el rizo y eliminar el uso de IX completamente:

Código: Seleccionar todo

    LD   DE,$44B5 + $1A
    LD   HL,tabla_de_inicializacion
    LD   BC,$33     ; Incremento para pasar entre estructuras
    LD   A,7
bucle_de_inicializacion
    LDI             ; Transferimos a $1A
    LDI             ; Transferimos a $1B
    INC  DE
    LDI             ; Transferimos a $1D
    EX   DE,HL
    ADD  HL,BC
    EX   DE,HL
    DEC  A
    JR   NZ,bucle_de_inicializacion

tabla_de_inicializacion
    DEFB $01,$F3,$FC
    DEFB $01,$F2,$FD
    DEFB $01,$F1,$FE
    DEFB $01,$F0,$00
    DEFB $01,$F1,$02
    DEFB $01,$F2,$03
    DEFB $01,$F3,$04

Total 45 bytes


Puede parecer una tontada, un "exceso" de optimización, pero acabamos de recuperar 67 bytes que te pueden servir perfectamente para desenrollar alguna de las rutinas de impresión ó añadir un sprite más...

Así que STOP a los IXs xDDDD ... bueno es un poco radical, tú sabes, siempre se pueden usar como contadores de 8 bits en los bucles

PD: Cuidado con la manipulación del registro 3 del CRTC, pues en CPCs enganchados a TVs puedes encontrarte que la imagen pierde el color ó consigues una bonita lista de copper con colores nunca vistos en el CPC , la gente que ha probado las betas del Uwol pueden dar fé de ello

Sobre los registros indice, tienes toda la razon: cuando empece, mi mente era un "ensamblador cruzado", lo dicho, programaba para un "Amiga CPC386"
Ya los estoy eliminando "de dentro a afuera": primero de las rutinas mas costosas, luego de las iteraciones que llaman a esas rutinas y asi voy subiendo.

El doble buffer, como ya lo utilizo (pantalla visible-pantalla en proceso de dibujado) poco mas uso le puedo dar (no me gustan los doble buffer que impliquen dibujar en la pantalla visible, tarde o temprano ese corte-desfase de frames se ve, por mucho cuidado que quieras tener con el orden de dibujado de sprites para sincronizarlo con el avance del beam)

Y gracias por puntualizar lo del CRTC, aprovecho para avisar a todos: mi intencion es crear un juego para mi amado CPC464 (CPC6128 mientras esta con las tripas abiertas para aprovechar las ventajas del .DSK).
Por eso: CUALQUIER COSA QUE NO FUNCIONE EN LA MAQUINA REAL CON MONITOR(es) ORIGINAL(es), INDICARMELO POR FAVOR, SERA ELIMINADA (no tengo el Amstrad cerca, esta en Asturias y vivo en Tarragona. No puedo probar nada en el... dependo de vosotros!)

Si suceden cosas raras (por ejemplo el uso de moduladores TV, contaba con ello) SE INTENTARA MEJORAR, PERO COMO OPCION DE CONFIGURACION.
Como indica Syx, modifico un registro que depende del monitor al que estemos conectados, y que habria que ajustar para el uso de otros monitores-moduladores. Ahora esta pensado para lan pantallas verde-color del Amstrad. Si alguien tiene problemas, en su momento dare la opcion de ajustar el parametro.

Da mucho animo vuestro interes. Vamos a ello!

¡ANIMO!

Me imagino que ya lo tienes previsto para cuando tengas integrada toda la lógica del juego, pero lo comento de todas maneras, añadir al marcador un "escaner" para saber donde están esos "viciosos" sperrium que están pidiendo a gritos ser aniquilados

BUFFFFF... no creo que cuelgue versiones nuevas en unos dias. Estoy revolviendo todas las tripas del codigo para simplificarlas. Al ver los limites reales que me impone el Amstrad, DEBERIA renunciar a las listas para gestionar los Bobs, y DEBERIA renunciar al encadenamiento de subestructuras:

En mi mente "spanglish", el Bob es uno de los personajes: contiene la informacion de posicion y tamaño -para deteccion de colisiones mas que para dibujado-,velocidad, que rutina le hace "pensar", que animacion cambia su aspecto etc.
El Bob no quiere saber nada de offsets, scans y demas temas de bajo nivel, solo le importa donde esta, con que interactua, que hacer...
Ademas, contiene dos punteros a dos sprites, uno por buffer:
Los sprites son estructuras que contienen el tamaño fisico de dibujado, la posicion en la memoria de pantalla, la de los datos graficos que lo definen etc. Y punteros a las rutinas que lo tienen que dibujar,restaurar etc (no todos son iguales)

Asi:
-los Bobs piensan "donde estoy en el mapa y que hago ahora" Me han pegado un tiro? Puedo disparar? Hay suelo bajo mis pies? En que direccion debo disparar para darle al Invader? La propia estructura de cada Bob sabe que rutina debe llamar para resolver sus dudas.
-los Sprites piensan "donde estoy en memoria y como han de moverse mis pixels" Debo restaurar el fondo? Necesito guardarlo antes de dibujarme? Me he salido de pantalla? Sabe a que rutina llamar para visualizarse o borrarse.

Todo esto te permite "definirlos y que se busquen la vida", sobre todo cuando los enlazas con listas. Pero es mas lento que estructuras "monobloque" tratadas con tablas.
DEBERIA, pero no lo hare. Me gusta el enfarragoso metodo que usa ahora, a pesar de que para tan pocos sprites, es estupido. Pero cuando defines como se comporta UNA bola, enlazas un monton de bolas en una lista y solo dices "hacer lo que debais", te das cuenta de que con tablas y estructuras simples el codigo seria mas rapido, pero mucho mas aburrido y menos flexible.

Y por que cuento todo esto? Para convencerme a mi mismo de que no es un ERROR GARRAFAL seguir con un diseño interno que no se adecua al Amstrad para nada! Sere necio!

He estado probando tu version actual del Blastardo (gran idea esa de ir matando spectrums XD!) en el 6128, la verdad que tiene una pinta estupenda con overscan y gran fluidez. Enorabuena por tu gran trabajo y a seguir así.

No imaginas como se agradece saber que el engendro esta corriendo en maquinas reales!
En el fondo esa es la meta, verlo en Amstrad, no en WinApe.

Aprovecho: si alguno tiene tiempo pa unas foticas a un CPC con el cargado, me haceis el tio mas feliz del mundo!

Buenos días, pues mira FatAgnus ahí dejo unas fotillas hechas con el móvil aunque no son de la mejor calidad, el parpadeo de la pantalla es engorroso a la hora de que salgan bien las fotos .

Pasé el dsk a cdt para ver como iba en el 464 y dío igualmente buen resultado. Ahí van.

GRACIAS TROCOLOCO!
Me has alegrao el Domingo!
Me moria por ver esa imagen... los bits corriendo por las venas de un z80 real.

Por lo que veo deberia desplazar la imagen un poco a la izquierda y un puñado hacia la parte superior para centrar la imagen.
No lo corregire ahora, prefiero acabar los cambios que estoy metiendole, me permiten crear un mapeado de juego mucho mas complejo, no solo tres bichejos.
Hoy-mañana habra version, espero con cambios agradables (adios definitivo a los bajones de velocidad y muuuucha mas diversion)

Eso si, no modificare mas por ahora el codigo para ganar ciclos, el cambio es brutal (10-25 % de mejora en las rutinas que si toque), pero el codigo se vuelve demasiado criptico y dependiente de las acciones anteriores para implementar con comodidad los cambios "logicos-estructurales" (incluso tuve que retomar una rutina a su version mas lenta plagada de "ix" e "iy" por todos los lados,era incapaz de depurar la rapida tras introducir las novedades)

No hay de que hombre, a mandar. Me alegro que te haya servido de ayuda

El resultado es muy vistoso y se refleja mejor el resultado en un cpc real en mi opinion. Los emuladores dan un resultado demasiado "perfecto" de lo que es la pantalla y engaña un poco. La pantalla principal sí parece bien centrada, la del juego sí que le haría falta desplazarla un poco pero tampoco demasiado.

Hombre lo de los cambios de velocidad nosé como serán con más sprites pero visto lo visto iba estupendamente, de todas tu eres el que sabe los entresijos del funcionamiento. Yo sinceramente soy un profano en lo que es programar en ensamblador pero viendo estos hilos a uno le entran ganas de aprender. Y bueno hombre deseando de ver los nuevos progresos que llegues a cabo .

Pues si te entro el gusanillo de programar para Amstrad, no lo dejes escapar.
Ahora tenemos toda la informacion necesaria en la web... imaginate en 1985, el "Codigo Maquina para Principiantes con Amstrad" me lo tuve que comprar por encargo! Informacion del CRTC y del Gate Array? fuera del alcance de un crio de doce años!
Y creeme, es una delicia programar para estas maquinas si las viviste de joven, luchar con-contra ellas, con-contra las maravillosas limitaciones que tenian, es fantastico.

ANIMATE!

P.D. Cambios menores el la version de la firma, sobre todo para incluir agradecimientos a MADMAX (ya que le mangue la musica, reconocerlo), a Trocoloco (por su esfuerzo de alfatester), a mi familia... y para dedicarselo a mi padre (si me ves, me lees o me oyes, pues que te quiero. D.E.P.)

imaginate en 1985, el "Codigo Maquina para Principiantes con Amstrad" me lo tuve que comprar por encargo! Informacion del CRTC y del Gate Array? fuera del alcance de un crio de doce años!

Ese libro ya no se por dónde puede quedar, pero las fotocopias amarillentas del Apéndice A (llenas de notas, of course ) las tengo aquí delante, junto a las tablas de ciclos de las instrucciones

Pero vamos que entonces era toda una aventura encontrar libros, de hecho, hasta encontrar una fotocopiadora lo era, así que al principio del todo me saqué el carnet de la biblioteca provincial en Cádiz, porque era el único lugar donde encontrar libros de programación "avanzada", y allí me iba las mañanas de los sábados con un cuaderno de cuadritos a "copiar", ¡peazo castigo!

Y creeme, es una delicia programar para estas maquinas si las viviste de joven, luchar con-contra ellas, con-contra las maravillosas limitaciones que tenian, es fantastico.

De todas formas, cuidado, porque es algo totalmente adictivo, tanto como divertido y de ello puede dar fe Mode2 que se lo está pasando de miedo

Hombre no ha sido nada pero gracias por la dedicatoria, es un gran detalle de tu parte . La verdad que claro que disfruté del amstrad de chinorri, sobre todo jugando claro pero también haciendo programillas y los típicos listados que venían con el manual de basic que traía. Pero siempre quedó esa cosilla del asm.

Le estoy echando un vistazo a lo que es el manual de la web, de Miguelsky, pero me gustaría que me recomendárais algo para un pardillo como yo, que pa eso sois unos máquinas del tema.

La verdad que mola porque mientras mayor es su limitación más ingenio hay que sacar y más mérito tiene. Y si le pillo el tranquillo seguro que me pico!