Toqueteando las tripas del OCS en ASM. Nivel -1

[Debvgger]

Último mensaje de la página anterior:

Gracias por el esfuerzo que estás dedicando a este tutorial El Amiga necesita más programadores.

Sobre el canal, me gustaría decir que hay gente de todos los niveles y que la única condición para entrar es querer aprender y mejorar; todo el mundo que la cumpla es bienvenido y no "acaba con los foros" sino que los complementa. La mensajería instantánea y la scene han ido de la mano desde hace décadas!

[Chema]

Sobre el canal, me gustaría decir que hay gente de todos los niveles y que la única condición para entrar es querer aprender y mejorar; todo el mundo que la cumpla es bienvenido

Doy fe de que el canal es muy interesante para cualquiera que quiera aprender. Totalmente recomendable. Puede que se entendiera mal mi comentario, y pido disculpas si así fue. Que a veces comentamos cosas en los foros sin pensarlas demasiado.

[Chema]

¡Tachaaaaaaaán!

Mi primer BOB en pantalla... sí. Ese Blake es un objeto de blitter con su máscara y todo...

Queda mucho, pero al menos ya me funciona poner un gráfico en pantalla con su máscara. Eso sí, supongo que no estaré haciendo las cosas bien, o de la mejor manera, pero me hace ilusión

bob powa.png (18.68 KiB) Visto 1129 veces

[Mlake]

¡Tachaaaaaaaán!

Mi primer BOB en pantalla... sí. Ese Blake es un objeto de blitter con su máscara y todo...

Queda mucho, pero al menos ya me funciona poner un gráfico en pantalla con su máscara. Eso sí, supongo que no estaré haciendo las cosas bien, o de la mejor manera, pero me hace ilusión

bob powa.png

Que grande eres

Si el bob está donde quieres,esta bien hecho.Con su mascara y todo.... de lujo.

Lo unico "raro" que hay que hacer es testear el bit 6 de DMACONR antes de hacer el blit, para asegurarnos que no está ocupado bliteando otra cosa.

Como solo tienes un.bob,no pasa nada.

[minter]

¡Tachaaaaaaaán!

Mi primer BOB en pantalla... sí. Ese Blake es un objeto de blitter con su máscara y todo...

Queda mucho, pero al menos ya me funciona poner un gráfico en pantalla con su máscara. Eso sí, supongo que no estaré haciendo las cosas bien, o de la mejor manera, pero me hace ilusión

bob powa.png

oh! Cielos!!!
Al Amiga le está entrando el virus del ORIC!!!!

Que bueno!!! Que envidia!!!

[Mlake]

CAP 3B Playfield Segunda parte.

Hasta ahora no hemos tenemos problema en cuadrar nuestro datafetching y nuestra ventana. Ahora vamos a probar otro escenario.



En este caso elegimos un playfield mas corto que la imagen.

Como siempre, definimos la ventana y calculamos el DDF que nos haga falta para cuadrar el bitmap. Aqui la unica novedad es fijarse donde "arranca" la imagen. Si quieres que el bitmap esté centrado, deberias añadirle los bytes necesarios a BPLxPTH/L para cuadrar esos 32 pixels (4 bytes). De otra forma, empezara a dibujar el primer pixel de la imagen al inicio de DIWSTRT.
Ha quedado claro, ¿no?

Pues solo nos queda el ejemplo donde el DDF es mas corto que nuestra imagen. Aqui deciamos que habia que saltar los bytes que no quisieramos.



De eso se encarga BPL1MOD y BPL2MOD ($dff108 y $dff10a). Uno manda sobre los bitplanes impares y el otro sobre los pares. Ahora mismo usamos playfields sencillos, donde podemos usar los bitplanes que necesitemos. En modo DUAL PLAYFIELD la cosa cambia y tienes los planos divididos entre pares e impares (imagina que quieres hacer un ""parallax"", pues el 1,3,5 serian para el plano cercano y el 2,4,6 se usarian para el fondo).
En el caso de la imagen solo tendriamos que poner dc.w BPL1MOD,40 en nuestra copperlist (o move.w #40,$dff108 si lo haces desde CPU). OJO, en este caso estoy usando DECIMAL, no hexa.



Da igual donde se encuentre el playfield, si los modulos estan separados el salto sigue siendo de 40 (la suma). Lo explico porque alguno puede pensar que solo hay que saltar la parte derecha.
Ahora que tenemos claro que es eso del modulo ¿que utilidad tiene ademas de ocultar lo que no cabe en el DDF?
Hasta ahora hemos trabajado con un bitplane. Como vimos en la introduccion, el color de la imagen se consigue apilando capas.
Plano 1
1111111111111111
1100000000000011
1100000000000011
1100000000000011
1100000000000011
1111111111111111
Plano 2
1111111111111111
1100000000000011
1100000000000011
1100000000000011
1100000000000011
1111111111111111
Plano 3
1111111111111111
1100000000000011
1100000000000011
1100000000000011
1100000000000011
1111111111111111

Si no conoces el concepto de modulo, esa seria la forma mas logica de trabajo. Sin embargo el Amiga se encuentra en su salsa cuando ve esto:
Plano1 1111111111111111
Plano 2 1111111111111111
Plano 3 1111111111111111
1100000000000011
1100000000000011
1100000000000011
1100000000000011
1100000000000011
1100000000000011
1100000000000011
1100000000000011
1100000000000011
1100000000000011
1100000000000011
1100000000000011
1111111111111111
1111111111111111
1111111111111111

Todo este entrelazado lo podemos expresar de esta forma:


Si aplicamos lo que habiamos aprendido, vemos que hay que usar los modulos para saltarnos los demas bitplanes. En este caso seria (40+40) BPL1MOD =80 BPL2MOD=80 porque estamos usando bitplanes pares e impares en playfield SENCILLO.

Imaginemos como se va a generar la imagen.
El rayo llega DIWSTRT, el chipset busca BPL1PTH/L, BPL2PTH/L y BPL3PTH/L y empieza a dibujarlos (haciendo que vayan incrementandose), cuando termina la linea cierra el grifo, le da un empujon de 80 bytes a los 3 punteros (por orden BPL1MOD y BPL2MOD) y vuelven a pintar.....
La forma de ubicar los punteros a la hora de cargarlos, es usando el primero como referecia y despues le sumas el ancho en bytes de cada bitplane. En el caso del ejemplo vemos +40 +80 .
Espero que no haya sido muy lioso.



photo sharing
Basicamente hemos hecho un pequeño loop para pokear las direcciones de los BPLxPTH/L.
Como sabemos que la imagen es 40bytes de ancho, pues subimos 40 al puntero original, asi hasta llenar todos.

La copperlist no tiene muchos cambios, mas bitplanes mas colores, los modulos y encendido de 3 bpl con compatibilidad A1000.

Ahora toca rizar el rizo para comprobar que todo esta entendido:



Si estuvieramos en esta situacion, no tenemos que olvidar que ademas de saltar los otros bitplanes, hay que saltar lo que queda fuera del DDF.

¿Alguna duda?

[Chema]

Estoy en ello. Es que estoy aprendiendo ensamblador del 68K a la vez y tiendo a pensar como cuando uso 6502, así que hago las cosas un poco raras, y tengo que rehacer. Me cuesta ver cómo optimizar (dónde centrarme) por el cambio de procesador.

He estado liado dejando la rutina de bobs bien para que pinte aunque el mismo no esté alineado a una palabra. Me llevó tiempo entender cómo funcionan las máscaras de primera y última palabra de cada fila y cómo ajustar para que pinte realizando las rotaciones adecuadas. Menos mal que tenía el tutorial de Fernando Cabrera.

Y todavía no he salvado/restaurado el fondo...

Bueno, en cuanto a tu última entrega, tengo una pregunta. ¿Se pueden tener los planos uno detrás de otro tanto como entrelazados o sólo esto último? Si se pueden tener ambos, ¿hay alguna ventaja en el segundo?

Es que, en cuanto los bobs me funcionen completos, tengo que pasar a darle color

[Mlake]

Estoy en ello. Es que estoy aprendiendo ensamblador del 68K a la vez y tiendo a pensar como cuando uso 6502, así que hago las cosas un poco raras, y tengo que rehacer. Me cuesta ver cómo optimizar (dónde centrarme) por el cambio de procesador.

He estado liado dejando la rutina de bobs bien para que pinte aunque el mismo no esté alineado a una palabra. Me llevó tiempo entender cómo funcionan las máscaras de primera y última palabra de cada fila y cómo ajustar para que pinte realizando las rotaciones adecuadas. Menos mal que tenía el tutorial de Fernando Cabrera.

Y todavía no he salvado/restaurado el fondo...

Bueno, en cuanto a tu última entrega, tengo una pregunta. ¿Se pueden tener los planos uno detrás de otro tanto como entrelazados o sólo esto último? Si se pueden tener ambos, ¿hay alguna ventaja en el segundo?

Es que, en cuanto los bobs me funcionen completos, tengo que pasar a darle color

Los articulos de Fernando Cabrera son canela fina. De lo mejor que hay en español sobre el tema. Si ya tienes dominado el masking y el shifting en los blits, lo tienes todo hecho.

¿El problema de tener los planos independientes? Cuando le des color vas a tener que blitear cada biplane por separado.

BLTAPTH del plano 1 y copiarlo a BLTDPTH
BLTAPTH del plano 2 y copiarlo a BLTDPTH
BLTAPTH del plano 3 y copiarlo a BLTDPTH
Y asi.....

Como lo estas haciendo con un bitplane, te vale con una copia.

[Mlake]

CAP 3C Moviendo playfields.

Vamos a hacer el clasico scroll horizontal y vertical.

En capitulos anteriores vimos como mostrar nuestros bitmaps, el sistema de bitplanes y la forma de trabajar con planos entrelazados. Nuestra idea hoy es darles movimiento.

El movimiento vertical es sencillo



Lo unico que tenemos que hacer es modificar el puntero a nuestra imagen haciendo que apunte una linea mas abajo del dibujo. ¿como la calculamos? Si nuestra imagen tenia 40bytes de ancho, se lo sumamos. En este caso, al tener los bitplanes entrelazados, tambien contamos el ancho que tienen (40x2bitplanes).
Vamos a un ejemplo rapido.



Tenemos un bitmap de un solo plano, que mide 320x272 (16 pixels mas por abajo). Como la imagen es un patron de 8x8 pixels, podemos reutilizarla con solo bajar 16 lineas.Asi se entiende el concepto y conseguimos una imagen constante.

Usamos d7 para incrementar el puntero del bitplane y lo pokeamos en nuestra copperlist, si por el camino vemos que se pasa de las 16 lineas previstas (16lineasx40bytes=640bytes), reiniciamos el puntero "original". Si nuestro fondo fuera mas largo, lo podriamos dejar correr mas.



Nuestra copperlist no tiene nada nuevo, simplemente hemos jugado con BPL1PTH/L.
El resultado final seria algo asi.




El scroll horizontal se puede hacer por hardware, para eso esta BPLCON1
http://amiga-dev.wikidot.com/hardware:bplcon1

Como vimos, el DDF va de 16 en 16 pixels. Para poder hilar mas fino, podemos mover los bitmaps pixel a pixel usando esta parte del custom.

Para hacer scroll, la imagen tiene que ser mayor que la ventana.
Para seguir a pantalla completa podiamos sacrificar 1 sprite para poder agrandar nuestro DDF, pasando del habitual $38, al $30. (echadle un ojo a la imagen de slots/DMA). Pero hemos preferido perder pantalla dejando el DDF a $38 y bajando DIWSTRT a $2c91. De esa forma no perdemos ese sprite.

¿Cual es la mision de BPL1CON? Segun valga mas o menos (0-F) empezaremos a mostrar los pixels ocultos. De esa forma conseguimos el scroll horizontal.



El byte que maneja el scroll está dividido en 2, 4 bits para planos pares y 4 para impares.
Como vimos anteriormente, trabajamos con playfields sencillos asi que los usamos a la vez ($00-$FF). Si usaramos DUAL playfield , un nibble maneja los pares (el fondo, por ejemplo) y otro los impares (la zona cercana a tu personaje).

Otro ejemplo como el anterior, tenemos como bitmap una cuadricula de 8x8 y 320 de ancho x 256 de alto. No ha hecho falta hacer la imagen 16 pixels mas ancha porque hemos recortado la ventana 16pix, RECORDAD.


upload photos

Esta vez usamos d7 para incrementar el scroll de BPLCON1. Como tenemos que duplicar el nibble que informa del scroll para cada par/impar. usamos D0 como apoyo y convertimos 01,02,03,04.... a 11,22,33,44.....
Esto es necesario para usar los 16 bits de scroll, si usais incrementos de 8 bits os ahorrais este follon y solo necesitais hacer una suma de $11 en $11 (Gracias Chema).



El unico cambio en la copper list es incluir la zona para pokear BPLCON1 (scroll:).

El resultado:

[Chema]

Acabo de terminar las rutinas de BOBs y ya puedo desplazar un número de ellos por la pantalla correctamente. Falta optimizar un montón, supongo (no sé dónde centrarme en optimizar y mi código es un poco horrible aun), pero funciona todo y son rutinas más o menos genéricas

Tengo que aprender a exportar como gif animado y así os lo enseño. De todas formas, enseguida me pongo con el color y el scroll… Es que este desvío me ha tomado el tiempo libre que tuve estos días de fiesta

[Chema]

Ya me funciona el scroll... Una imagen con 3 bitplanes que se desplaza de izquierda a la derecha (la escena de la intro de Los 7 de Blake). En realidad convertida en una imagen de 640 pixels de ancho, para simplificarme la vida. Tal y como recomiendas, en modo entrelazado (ahora entiendo por qué es mejor, gracias a tu respuesta).

He tenido que ir actualizando los punteros cada 8 rotaciones por programa ($11, $22, $33,... $ff) por programa. Supongo que estas cosas hay que hacerlas con código, no hay manera de que te lo haga el copper o algo...

Por cierto, en el código tu tienes add.l #11,d7, pero yo tuve que poner add.l #$11, d7 (en hexa). ¿Se me escapa algo o es un typo?

¿Hay alguna manera fácil de medir el tiempo de frame que te lleva un trozo de código? Algo para ver lo lejos que se está del límite de 50fps sin medir o contar ciclos a mano...

[Mlake]

Ya me funciona el scroll... Una imagen con 3 bitplanes que se desplaza de izquierda a la derecha (la escena de la intro de Los 7 de Blake). En realidad convertida en una imagen de 640 pixels de ancho, para simplificarme la vida. Tal y como recomiendas, en modo entrelazado (ahora entiendo por qué es mejor, gracias a tu respuesta).

He tenido que ir actualizando los punteros cada 8 rotaciones por programa ($11, $22, $33,... $ff) por programa. Supongo que estas cosas hay que hacerlas con código, no hay manera de que te lo haga el copper o algo...

Por cierto, en el código tu tienes add.l #11,d7, pero yo tuve que poner add.l #$11, d7 (en hexa). ¿Se me escapa algo o es un typo?

¿Hay alguna manera fácil de medir el tiempo de frame que te lleva un trozo de código? Algo para ver lo lejos que se está del límite de 50fps sin medir o contar ciclos a mano...

El incremento del scroll y la adaptacion de los punteros, hay que hacerlos con CPU. Yo suelo aprovechar los 16bits e incremento un word el puntero. Si te manejas mejor de byte en byte, no hay problema.
Sobre el add, sí es una errata (a ver si lo arreglo). De hecho la rutina no es correcta. simplemente era para pillar la idea.
Si te fijas, cuando terminemos la suma no vamos a pasar de FF a 00, sino de FF a 10 (el fallo de usar 11).
Lo suyo es usar un nibble para el calculo y "duplicarlo" para convertirlo en un byte. Si tenemos 0F, lo rotamos 4 bits (F0) y le sumamos el valor original(0F) resultando el FF que buscamos. (como a ti te vale con la mitad, te ahorras toda esta historia porque con el 11 te vale ya que no llegas al $10)


Sobre medir el tiempo, puedes usar el cambio de color de fondo al incio y al final del codigo, asi ves lo que ocupa en el rasterline en pantalla mientras ejecutas el programa.
Tambien puedes guardar el VHPOSR al principio y al final y ves lo que te ocupa.

[Chema]

Ok, gracias. Lo probaré todo... ¿Cómo generas los GIF animados desde el WinUAE? ¿O estás convirtiéndolos?

[Mlake]

Ok, gracias. Lo probaré todo... ¿Cómo generas los GIF animados desde el WinUAE? ¿O estás convirtiéndolos?

Con UAE hago la captura y lo convierto con un cutreprograma llamado Video to GIF de Watermark Software.

Sobre lo que hablabamos del raster, puedes hacer esto con cada rutina.



Si varias el color puedes ver lo que ocupa cada una. Solo tengo la rutina que mueve el starfield, asi que lo rojo es lo que ocupa el mover los 60 sprites de las 60 estrellas.Si tienes otras puedes poner azul, verde, etc.... y te puedes hacer una idea.



En el gif va brusco, pero son 50fps.

[kikems]

Mlake, que sepas que con Chema estas creando un monstruo. Con el exitázo que ha tenido anoche la DemoScene, a ver si gracias a tu esfuerzo de tutorial, más gente se va animando y tenemos nuevos coder para la siguiente generación de amigueros.

[ron]

Mlake, que sepas que con Chema estas creando un monstruo. Con el exitazo que ha tenido anoche la DemoScene, a ver si gracias a tu esfuerzo de tutorial, más gente se va animando y tenemos nuevos coder para la siguiente generación de amigueros.

subscribo 100% el comentario.

[Mlake]

Mlake, que sepas que con Chema estas creando un monstruo. Con el exitazo que ha tenido anoche la DemoScene, a ver si gracias a tu esfuerzo de tutorial, más gente se va animando y tenemos nuevos coder para la siguiente generación de amigueros.

Esa es mi intencion, que muchos le quiten el polvo al A500. Desde que existe WHDload, los tienen muertos de risa y tiran de AGA o UAE.

Anoche se demostró que aun no estan muertos.

Si este hilo ayuda a que la gente saque cosas (intros, juegos, slideshows....) para A500, me quedo mas que satisfecho.