Zx Spectrum: rutina en ensamblador para manejar SPRITES

[Ivanzx]

explorer, he pillado el Gandalf Deluxe que ponías, pero resulta que se resetea nada más que lo cargo en el emulador. ¿Seguro que es para Spectrum normal? ¿No será para inventos varios como la ULA+?

Torpedooorl! El Gandalf Deluxe si es para Spectrums normales, pero tienes que cargarlo en 128K, si no no furula

De juegos hechos con el AGD, prueba estos dos, que para mí son los mejores hechos con tal herramienta:

Q-Box
https://spectrumcomputing.co.uk/index.p ... 6&id=32179

Ooze
https://spectrumcomputing.co.uk/index.p ... 6&id=30377

[Bubu]

Jaaaarl, ya me lo dijeron, así hice, y así carburó

Oyes, ¿tú sabes si el AGD es nativo o cruzado?
Por cierto, el Q-Box es una obra de arte, lo he jugado este año mucho muchísimo, me encanta y me engancha. El Ooze no lo recuerdo, le voy a dar un tiento, danke!

[Ivanzx]

Jaaaarl, ya me lo dijeron, así hice, y así carburó

Oyes, ¿tú sabes si el AGD es nativo o cruzado?
Por cierto, el Q-Box es una obra de arte, lo he jugado este año mucho muchísimo, me encanta y me engancha. El Ooze no lo recuerdo, le voy a dar un tiento, danke!

Pues me temo que no tengo ni idea de qué significa si es nativo o cruzado
Eso sí, gracias a Allan Turvey se está llegando a cotas nunca antes pensadas para AGD (está agregando muchas funcionalidades y extras).

[jltursan]

Jaaaarl, ya me lo dijeron, así hice, y así carburó

Oyes, ¿tú sabes si el AGD es nativo o cruzado?
Por cierto, el Q-Box es una obra de arte, lo he jugado este año mucho muchísimo, me encanta y me engancha. El Ooze no lo recuerdo, le voy a dar un tiento, danke!

Pues si te entiendo bien, ambos.

Es nativo, "Arcade Games Designer (Spectrum, CPC, Timex/Next)" y cruzado, "Multi-Platform Arcade Game Designer 0.7.1 (Windows 64-bit)". Todos aquí:

http://www.spanglefish.com/egghead/index.asp?pageid=397755

¿Era eso a lo que te referías?

[Bubu]

Efestivamente, jltursan, con lo de nativo / cruzado me refería a si la herramienta se ejecuta en el Spectrum o en un PC. Si es en un Spectrum, no me interesa pues desarrollar y diseñar en un Spectrum es la muerte a pellizcos
Lo suyo es desarrollar en el PC, generar ahí el juego, y éste ya jugarlo en el Spectrum.

[Bubu]

Bueno, llevo un par de semanas buscando y rebuscando, bajando y rebajando, estudiando y re-estudiando, y he llegado a la conclusión de que voy a intentar hacerme yo un motorcito de sprites. No es que lo que hay por ahí sea malo, qué va, todo lo contrario, es muuuy bueno, pero o bien no entiendo cómo lo hace, o no sé cómo adastarlo para un proyesto nuevo.

Así las cosas, ¿alguien de por estos lares sabe (aunque sea en teoría) cómo se hace un "sprite engine"? Me gustaría hacer algo que permitiera mover sprites a color de MxN sobre un fondo, en principio que no colisionen sprites entre sí.
Voy a intentar exponer las ideas teóricas, a ver si estáis de acuerdo o le veis algún poblema:

Datos
====
- A1: Existiría una zona con todos los sprites pre-rotados lateralmente
- A2: El desplazamiento vertical no hace falta pre-rotarlo, sino que es calculable
- A3: Cada sprite tendría una tabla de estado, en la que se almacenaría su posición actual, su frame actual, su ancho y alto, su velocidad, etc
- A4: Por motivos de rapidez, es conveniente tener una copia completa del fondo de pantalla en una zona de la RAM, a la que se le denomina "buffer". Este buffer tendría el mismo alto y ancho que la zona de pantalla por la que se pueden mover los sprites. Si se pueden mover por tota la pantalla (6144 bytes) pues el buffer tendría tamién 6144 bytes (tela marinera).

Rutina de I.A. (inteligencia artifisiá)
=========
- B1: Existiría una rutina que se encargaría de ir astualizando esa tabla de los estados de los sprites
- B2: Si esa rutina detecta que hay que repintar el sprite (por cambio de posición, de frame, etc) entóns llama a la rutina de pintado
- B3: Si no, no hace nada más

Rutina de pintado
===========
- C1: A esta rutina la llama la rutina de I.A. sólo si ésta considera que hay que mover o pintar algún sprite.
- C2: Esta rutina debe ejecutarse mientras la ULA esté pintando los bordes. Si no, se vería un parpadeo.
- C3: Aquí hay diversas tésnicas, como p.ej. con o sin máscaras. Yo voy a optar en un principio (para simplificar) por no usar máscaras
- C4: Antes que dibujar el sprite, tenemos que borrar el sprite astual restableciendo el fondo primero. Para ello tiramos del buffer. Aquí he visto diversas tésnicas para que esto vaya como las balas, como el "PUSHeado" en pila, ya lo comentaremos.
- C5: Una vez hemos restablecido el trozo de fondo, se procede a pintar en pantalla el sprite según la tabla de estados. Aquí se puede usar un OR (para que el fondo se siga viendo, pero el sprite no puede tener zonas "blancas"), un AND (para que el sprite pueda tener zonas "blancas", pero el fondo desaparece), o un XOR (una mezcla de ambos métodos)



Yo creo que eso es todo, amigos. ¿Pensáis que este es el método que más o menos usa todo buen pogramador para manipular sprites, o estoy errando en algo? Le he ponido códigos a cada frase por si alguien quiere hacer referencia a alguna, sólo tié que indicar el código.

[Bubu]

Voy a suponer que todo lo anterior es corresto, y me pongo al lío.

Primero voy a crear una rutinilla que me dibuje un fondo, p.ej. líneas diagonales:

Código: Seleccionar todo

ORG $8000


start:
      di
      ld a, INK_BLACK
      out (254), a
      ld a, BRIGHT_ON + PAPER_BLACK + INK_WHITE
      call cls
      
      ld b, 0
      ld hl, VRAM_ADDR + 0x0000   ; primer tercio
      call fondo
      ld hl, VRAM_ADDR + 0x0800   ; segundo tercio
      call fondo
      ld hl, VRAM_ADDR + 0x1000   ; tercer tercio
      call fondo
      
      jarl:   jr jarl
      
            fondo:
      push hl
      ld (hl), %00000001
      inc h
      ld (hl), %00000010
      inc h
      ld (hl), %00000100
      inc h
      ld (hl), %00001000
      inc h
      ld (hl), %00010000
      inc h
      ld (hl), %00100000
      inc h
      ld (hl), %01000000
      inc h
      ld (hl), %10000000
      inc h
      pop hl
      inc l
      djnz fondo
      ret


Esto me genera el siguiente fondo:




A continuación voy a plantar encima un sprite de 32x32 píxeles. De momento lo coloco sin utilizar ningún mezclador de píxeles con el fondo. La rutina sería así:

Código: Seleccionar todo

      ;sprite 4x4
      ld b, 32
      ld de, mariposa   ; puntero al bitmap
      ld hl, VRAM_ADDR+500
   spr01:
      ld a, (de)
      ld (hl), a
      inc de
      inc l
      ld a, (de)
      ld (hl), a
      inc de
      inc l
      ld a, (de)
      ld (hl), a
      inc de
      inc l
      ld a, (de)
      ld (hl), a
      inc de
      dec l
      dec l
      dec l            
      call calc_next_vram
      djnz spr01


(la rutina calc_next_vram se vio en este hilo: viewtopic.php?t=8372 )

Y se vería así:



Lóxicamente al no haber ningún mezclador, los píxeles "transparentes" del sprite borran el fondo. Así es como trabaja el NIRVANA, y esto hace que no sea un buen motor gráfico cuando tienes un fondo de pantalla, pero si quieres multicolor es una absoluta virguería, oiga.

Bueno, nosotros vamos a añadir un mezclador para conservar el fondo. Cuando el sprite tiene zonas a dibujar en un color, y zonas transparentes hay que usar el mezclador "OR". Si el sprite tuviera 2 zonas de color más el transparente, entonces habría que recurrir a la tésnica MASK, uséase, usar máscaras de sprites, y esto lo intentaré en otra ocasión. De momento vamos a ver cómo se implementaría el mezclador "OR":

Código: Seleccionar todo

      ;sprite 4x4
      ld b, 32
      ld de, mariposa   ; puntero al bitmap
      ld hl, VRAM_ADDR+500   
   spr01:
      ld a, (hl)
      ld c, a
      ld a, (de)
      or c
      ld (hl), a
      inc de
      inc l
      ld a, (hl)
      ld c, a
      ld a, (de)
      or c
      ld (hl), a
      inc de
      inc l
      ld a, (hl)
      ld c, a
      ld a, (de)
      or c
      ld (hl), a
      inc de
      inc l
      ld a, (hl)
      ld c, a
      ld a, (de)
      or c
      ld (hl), a
      inc de
      dec l
      dec l
      dec l            
      call calc_next_vram
      djnz spr01


Obsérvese que lo único que hago es obtener el fondo con ld a, (hl), retenerlo en c, obtener el sprite coon ld a, (de), y mezclarlos con or c. Se vería así:



Se ve de escándalo.

Hasta aquí todo de lujo cuando se trata de imprimir una imagen estática sobre un fondo. Ya no habría que hacer más. PERO, ¿qué pasa cuando la imagen estática hay que moverla, lo que viene siendo un sprite? Si el sprite hay que pintarlo encima del anterior, podemos utilizar esta misma rutina. El poblema viene cuando hay que imprimir el sprite en otra posición. Lógicamente primero tendremos que restaurar el fondo que había antes de que pintáramos el primer sprite.

[Bubu]

Ahora me voy a encargar del fondo. Lo primero sería crear una rutina que volcara todo el fondo en un buffer, como vimos anteriormente, con la idea de que cada vez que haya que borrar un sprite, sacar del buffer el trozo de fondo y volcarlo en pantalla. Lo más simple para hacer una copia del fondo en un buffer es esto:

Código: Seleccionar todo

put_buffer:
      ld hl, VRAM_ADDR
      ld de, buffer
      ld bc, 6144
      ldir
      ret
      
buffer:
   DS   6144


Como veis, este fondo mide 6144 bytes, que es la totalidad de la pantalla. Si vuestro juego tuviera un ancho y alto inferior, pues sustituir el 6144 por vuestro caso y yastá.
A esta rutina hay que llamarla nada más que dibujemos el fondo, y antes de dibujar los sprites.

Una vez esto, ahora tendría que diseñar una rutina (la llamaré get_buffer) que reciba una posición VRAM, un ancho y un alto, y sacara del buffer ese restángulo y lo volcara en VRAM.

Voy a ello.

[explorer]

Lo mejor es guardar solo la parte que ha sido modificada, no toda la pantalla.

Solo merece la pena guardar toda la pantalla si el número de sprites es muy grande: usas la recuperación del fondo como una forma de limpiar toda la pantalla (fondo+sprites).

Y en casos como este donde el fondo se calcula mediante un procedimiento... pues tampoco necesitas guardar nada: te vale con aplicar el mismo procedimiento a la superficie que ocupa el sprite.

[Bubu]

explorer, ¿por qué has tachao tu respuesta, no es válida o es que ha sido tachada sin querer queriendo?

Bueno, yo efestivamente entiendo que lo mejor es guardar sólo el fondo donde se haya situado encima el sprite, y no toda la pantalla. Eso de toda la pantalla es que lo leí en uno de esos motores de sprites que hay por ahí, pero la verdad es que me pareció exagerao. Lo dicho, me voy a poner a pogramar pa que guarde sólo el trozo de fondo.

Lo que dices del fondo "calculable" es verdad, JAjAjAjaJAJ, no había caído, incluso en este caso de las diagonales sólo habría que guardar un trozo de diagonales, y nunca más re-capturarla, AJjAjA, pero es que lo puse por poner un ejemplo de fondo. En realidad habrán fondos cualesquiera: casas, calles, montañas, etc.