Toqueteando las tripas del OCS en ASM. Nivel -1

Avatar de Usuario
Chema
Mensajes: 2664
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 3190 veces
Agradecimiento recibido: 926 veces
Contactar:

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Chema » 07 Jun 2019 22:19

Último mensaje de la página anterior:

Está genialmente explicado, Mlake. Creo que le voy cogiendo el tranquillo.

Aunque sigo sin mucho tiempo, he dedicado un par de horitas hoy a probar cosas con sprites. A parte de los letreros que se desplazaban y el cursor con colorines animados :) hoy he metido un par de sprites animados para simular brillos. Como son sprites, no se reflejan en el agua, mientras que si cambiase el gráfico del letrero con BOBs, sí que lo haría...

Ya sabéis que los gráficos no son lo mío y tengo una guerra particular con las paletas, pero bueno, se trata de pillar cómo funcionan las cosas, no de hacer una intro -507

Bueno, haré más cosas, pero si quieres cambiar de tema en el curso, perfecto. Estoy deseando llegar al blitter... de hecho tengo en la cabeza ya un pequeño proyectito que molaría :)

MyMovie (1).gif
MyMovie (1).gif (555.42 KiB) Visto 6145 veces

Avatar de Usuario
frankrodiii
Mensajes: 655
Registrado: 26 May 2019 14:46
Ubicación: ??!!!#=?¿****!!! ©
Agradecido : 514 veces
Agradecimiento recibido: 285 veces
Contactar:

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor frankrodiii » 08 Jun 2019 01:12

Chema escribió:Está genialmente explicado, Mlake. Creo que le voy cogiendo el tranquillo.

Aunque sigo sin mucho tiempo, he dedicado un par de horitas hoy a probar cosas con sprites. A parte de los letreros que se desplazaban y el cursor con colorines animados :) hoy he metido un par de sprites animados para simular brillos. Como son sprites, no se reflejan en el agua, mientras que si cambiase el gráfico del letrero con BOBs, sí que lo haría...

Ya sabéis que los gráficos no son lo mío y tengo una guerra particular con las paletas, pero bueno, se trata de pillar cómo funcionan las cosas, no de hacer una intro -507

Bueno, haré más cosas, pero si quieres cambiar de tema en el curso, perfecto. Estoy deseando llegar al blitter... de hecho tengo en la cabeza ya un pequeño proyectito que molaría :)

Para un inexperto en Amiga como yo estoy impresionado con este efecto. -grin
frankrodriguez.net
Apple IIc - Macintosh SE/30 - Amiga 500 Plus - SiDi

Avatar de Usuario
Mlake
Mensajes: 178
Registrado: 27 Mar 2019 19:54
Agradecido : 76 veces
Agradecimiento recibido: 324 veces

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Mlake » 08 Jun 2019 03:49

Chema escribió:Está genialmente explicado, Mlake. Creo que le voy cogiendo el tranquillo.

Aunque sigo sin mucho tiempo, he dedicado un par de horitas hoy a probar cosas con sprites. A parte de los letreros que se desplazaban y el cursor con colorines animados :) hoy he metido un par de sprites animados para simular brillos. Como son sprites, no se reflejan en el agua, mientras que si cambiase el gráfico del letrero con BOBs, sí que lo haría...

Ya sabéis que los gráficos no son lo mío y tengo una guerra particular con las paletas, pero bueno, se trata de pillar cómo funcionan las cosas, no de hacer una intro -507

Bueno, haré más cosas, pero si quieres cambiar de tema en el curso, perfecto. Estoy deseando llegar al blitter... de hecho tengo en la cabeza ya un pequeño proyectito que molaría :)

MyMovie (1).gif

Diras lo que quieras pero te ha quedado de PM. -thumbup

Todo lo que hemos hecho ha sido para aprovechar el DMA de sprites.
Si quieres profundizar, se podrian reutilizar los sprites y hacerles el "agua" cambiando SPRxPOS con el copper, a la vez que cambiamos la del scroll.

Ya que conoces como funciona SPRxPOS ($YYXX) y SPRxCTL ($YfMP), seguro que este link se hace entendible.

http://codetapper.com/amiga/sprite-tricks/stardust/

Aqui reutilizan los sprites a copper. (paran en X linea, cargan el puntero, modifican SPRxPOS y SPRxCTL y listo), ademas puedes ver como usan la triquiñuela de cambiar el modulo para hacer el reflejo del tunel. Como usan los sprites "mezclados" para la nave.....

Sobre el hilo, yo creo que solo hace falta explicar la prioridades entre playfields/sprites (saber que plano va delante del otro y/o sus posiciones entre los sprites). Con eso ya pueden ir tirando los que no se quieren meter en fregados nuevos y quieren consolidar lo anterior.

Despues nos meteremos a blitear. OJO, que nadie espere virguerias. No soy ELITE, veremos como funciona por encima, como operar con él (minterms) y poco mas... no vamos a hacer glenz vectors. -grin

Avatar de Usuario
Skynet
Mensajes: 48
Registrado: 04 Nov 2018 22:50
Ubicación: Almería
Agradecido : 125 veces
Agradecimiento recibido: 29 veces

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Skynet » 08 Jun 2019 23:44

¿Cómo que no? ¿No va a haber Glenz vectors? Bueno, pues algunos sencillitos en wireframe -grin

Avatar de Usuario
kikems
Mensajes: 5502
Registrado: 30 May 2013 19:23
Agradecido : 2638 veces
Agradecimiento recibido: 3112 veces

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor kikems » 09 Jun 2019 11:57

Uffff , la que vais a terminar armando aquí entre los tres.

Avatar de Usuario
Mlake
Mensajes: 178
Registrado: 27 Mar 2019 19:54
Agradecido : 76 veces
Agradecimiento recibido: 324 veces

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Mlake » 10 Jun 2019 13:00

Skynet escribió:¿Cómo que no? ¿No va a haber Glenz vectors? Bueno, pues algunos sencillitos en wireframe -grin

Con mis matematicas de Graduado Escolar en un centro de adultos,va a estar complicado...

Ojala estuviera en mi mano. :(

Y encima chema, kikems y ron te jalean. -rofl

Avatar de Usuario
Mlake
Mensajes: 178
Registrado: 27 Mar 2019 19:54
Agradecido : 76 veces
Agradecimiento recibido: 324 veces

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Mlake » 11 Jun 2019 03:41

CAP 5 Prioridad Playfields/Sprites

A los que ya dominan el tema, quiero que comprendan que la cantidad de burradas que puedan aparecer son para intentar explicar conceptos, sobre todo al principio.

Si ya nos apañamos con los sprites por DMA, solo nos queda organizar la pantalla.


El encargado de la prioridad es BPLCON2 .

http://amiga-dev.wikidot.com/hardware:bplcon2

De la misma forma que BPLCON0 se encargaba de la configuracion "general" y BPLCON1 del scroll, ahora tenemos BPLCON2.


Imagen
La mejor explicacion de todo el HRM es este dibujo.




Prioridad entre sprites:

Esta es sencilla, SPRITE0 es el mas cercano a nosotros y SPRITE7 el mas lejano.
Aqui no hay nada que rascar, al estar colocados en ese orden en el DMA, se da por hecho que a medida que te acercas a DDFSTART, los sprites deben ser mas "prescindibles" (ver la introduccion del hilo).
Recordad cuando haciamos el scroll, al ensanchar el DDF de $38 a $30, nos comiamos el ultimo sprite.

Imagen


Prioridad entre Playfields:

De esto se encarga el bit 6 de BPLCON2.
0 Si queremos el PF1 encima y PF2 debajo
1 Si queremos el PF2 encima y PF1 debajo


Ahora queda la prioridad PF/SPR.

Una vez tenemos claro como ordenar los fondos (bit 6), tenemos que configurar su posicion respecto a los sprites.

Como siempre, toca hacer un ejercicio mental:
Vamos a quedarnos con un solo Playfield y tenemos 8 Sprites (4parejas).
Podemos insertar nuestro PF entre aquellas PAREJAS que queramos.

Hay 5 "combinaciones" segun te interese.
¿Como las elijo? para eso tenemos 3 bits.

000 PFx SP01 SP23 SP45 SP67
001 SP01 PFx SP23 SP45 SP67
010 SP01 SP23 PFx SP45 SP67
011 SP01 SP23 SP45 PFx SP67
100 SP01 SP23 SP45 SP67 PFx

Teniendo esto claro, hay que pasar estos bits a BPLCON2.

Segun el manual, tienes los bits 0/1/2 para PF1 y 3/4/5 para PF2, en principio es sencillo....
Solo tiene una pega que hay que recordar. En SINGLE PLAYFIELD hay que usar los bits 3/4/5 (aunque la logica te diga single=PF1). Los bits 0/1/2 funcionan en DUAL PLAYFIELD. OJO.

Imagen

Para reciclar a nuestros pajaros, simplemente le hemos dado prioridad sobre la luna.
En cambio, al llegar a la zona pal aprovecho la parada y le doy preferencia al fondo.

De paso dejo una rutina chusterilla de joy para el que quiera hacer experimentos con lo aprendido.
Adjuntos
Loro2.zip
(7.82 KiB) Descargado 67 veces

Avatar de Usuario
Chema
Mensajes: 2664
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 3190 veces
Agradecimiento recibido: 926 veces
Contactar:

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Chema » 12 Jun 2019 22:07

Ajá... ya me parecía a mí que tenía que poderse poner un sprite detrás de un plano :)

Supongo que pillarle el truco a esto es ya cuestión de hacer cosas y resolver problemas para acostumbrarse. La rutinilla con los pájaros mola un montón :)

Según te he entendido anteriormente, ¿sería posible cambiar la posición del sprite con el Copper, *en medio* de su pintado? Es decir, ¿entre una línea y otra? Con eso se tienen que poder hacer efectos chulos... como una imagen en un monitor que se deforma por el ruido o cosas así.

Crees que sería buena idea, por ejemplo, usar sprites para implementar las burbujas tipo cómic y donde el texto haga scroll, como en SkoolDaze? supongo que es cosa de ir bliteando el texto sobre el gráfico del sprite. Las burbujas eran, creo que de 48 pixels de ancho, aquí podrían hacerse con 3 sprites... (no, no pienso en portar Skool Daze, era sólo una idea...)

Avatar de Usuario
Mlake
Mensajes: 178
Registrado: 27 Mar 2019 19:54
Agradecido : 76 veces
Agradecimiento recibido: 324 veces

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Mlake » 13 Jun 2019 02:31

Chema escribió:Ajá... ya me parecía a mí que tenía que poderse poner un sprite detrás de un plano :)

Supongo que pillarle el truco a esto es ya cuestión de hacer cosas y resolver problemas para acostumbrarse. La rutinilla con los pájaros mola un montón :)

Según te he entendido anteriormente, ¿sería posible cambiar la posición del sprite con el Copper, *en medio* de su pintado? Es decir, ¿entre una línea y otra? Con eso se tienen que poder hacer efectos chulos... como una imagen en un monitor que se deforma por el ruido o cosas así.

Crees que sería buena idea, por ejemplo, usar sprites para implementar las burbujas tipo cómic y donde el texto haga scroll, como en SkoolDaze? supongo que es cosa de ir bliteando el texto sobre el gráfico del sprite. Las burbujas eran, creo que de 48 pixels de ancho, aquí podrían hacerse con 3 sprites... (no, no pienso en portar Skool Daze, era sólo una idea...)



Los sprites se pueden partir sin problema.
Solo tienes que esperar con el coper la linea adecuada y cambiar la $XX usando SPRxPOS.
Con eso le damos su nueva posicion.
Por ej:
dc.w $ac07,$fffe (Espera al principo de la linea $ac)
dc.w $SPRxPOS,$acXX
Al llegar a la linea $AC, la X vale lo que le hayas puesto.

Lo puedes hacer varias veces a lo largo del sprite.


Imagen

Si ademas de trocearlos quieres separarlos, se complica un poco.
Ahora no hay que estar pendiente de donde empieza el nuevo trozo sino donde termina el que estas pintando.
Si el sprite por defecto tenia 100 pixels (un suponer) y tu lo cortas, el puntero sigue corriendo mientras no lo usas.
Para evitar eso, usamos las paradas para frenar los punteros y despues cargar la nueva posicion.
Por ej:
dc.w $ac07,$fffe (Espera al principo de la linea $ac)
dc.w $SPRxXTL,$ac00 (frena los punteros dandole la Yfinal+byte de control 00)
dc.w $SPRxPOS,$bcXX (Coloca la nueva posicion ($YYXX) del sprite 16 pix mas abajo)

Y asi con los trozos que necesites......


Imagen

Espero haberme explicado bien.


Sobre los bocadillos..... como dirian los gallegos, depende.
Blitear sobre los sprites tiene 2 ventajas en este caso.
Si necesitas transparencia y si necesitas que se muevan (que vibre mientras hablan los personajes, que se muevan de un sitio a otro....).
Ahi te evitas guardar el fondo y usas blits sencillos A=D. Se podria mirar esa aproximacion.

Si el bocadillo es estatico y opaco. Usar BOBs de toda la vida solo es caro al principio (guardo fondo, pinto bocadillo) pero despues puedes blitear el texto dentro de forma directa, porque el propio bocadillo te disimula el fondo de la fuente.

Avatar de Usuario
Mlake
Mensajes: 178
Registrado: 27 Mar 2019 19:54
Agradecido : 76 veces
Agradecimiento recibido: 324 veces

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Mlake » 17 Jun 2019 00:09

Uso del DMA de SPRITES:

Para los que les gusta hilar fino y saber que ocurre con el DMA, quiza esto les sirva de ayuda.

Imagen

En violeta tenemos el tiempo en el que trabaja el DMA de Sprites.
Los primeros puntos son el momento en el que procesan los punteros que les da el copper. SPRxPTH/L
Se iluminan todos los canales porque siempre hay que declarar todos los sprites, aunque sea a uno dummy.

Despues podemos ver como abren y cierran para mostrar la imagen de los sprites.

Como vimos en el post anterior, podemos abrir y cerrar los DMA a mano usando SPRxCTL/SPRxPOS.

Avatar de Usuario
Mlake
Mensajes: 178
Registrado: 27 Mar 2019 19:54
Agradecido : 76 veces
Agradecimiento recibido: 324 veces

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Mlake » 23 Jun 2019 21:22

CAP 6 Introduccion al blitter

A los que ya dominan el tema, quiero que comprendan que la cantidad de burradas que puedan aparecer son para intentar explicar conceptos, sobre todo al principio.

Un blitter es un circuito que en base a X parametros, es capaz de copiar/operar con bloques de memoria sin necesidad de estar gastando CPU.

Un ejemplo simple:
La cpu le da un puntero de origen, uno de destino y le dice cuantos bytes tiene que copiar.
A partir de ahi, el blitter accede a la memoria y empieza a copiar lo que la CPU le ha ordenado, dejando libre de carga al procesador.
Como concepto es cojonudo, te olvidas de las restricciones de los tiles/charsets/sprites y puedes usar un framebuffer completo para lo que quieras (ventanas, objetos redimensionables...).

El concepto es sencillo, ahora hay que llevarlo al amiga asi que hay tener unas cosas claras:

Primero: El amiga trabaja con words (16 bits).
Segundo: El blitter solo se mueve en CHIPRAM.
Tercero: No solo tenemos un origen y un destino. Tenemos 3 fuentes (ABC) y 1 destino (D).
Teniendo eso en mente, vamos a intentar nuestro primer blit.



Paso 1) Comprobar que el blitter no esta ocupado con otra cosa.

No podemos decirle que nos dibuje X personaje cuando aun esta liado con el anterior.
Tiene que haber alguna forma de saber cuando ha terminado. Para eso tenemos un bit en DMACONR que nos avisa.

http://amiga-dev.wikidot.com/hardware:dmaconr
14 BBUSY Blitter busy status bit (read only)

Solo tenemos que esperar a que se encienda y podemos mandarle otra orden.




Paso 2) Configurar el blit

http://amiga-dev.wikidot.com/hardware:bltcon0
Para eso tenemos BLTCON0 y BLTCON1.

Asi de primeras puede parecer un poco lioso, por eso vamos a simplificar esos dos words.
El blitter tiene 2 modos de uso. El modo area (el que estamos viendo) y el modo linea (line). Por eso estan los bits por "duplicado" en los manuales.

Nosotros vamos a pensar en la configuracion como una doblepalabra (32bits) con el siguiente formato.

$AFMMB000

A= desplazamiento FUENTE A
F= ¿Cuantas fuentes/destino?
MM= Minterm
B= desplazamiento FUENTE B
000 = Lo demas apagado.

No hace falta entender que es cada cosa, simplemente es una guia para iniciarnos.



Nuestros primeros "conceptos":

FUENTES/DESTINO
Como vimos antes, no solo podemos copiar de un sitio a otro sino que al tener varios origenes (A B y C), podemos "combinarlos" en D (destino).

MINTERM
Todas esas combinaciones tienen una "identificacion", eso va a ser el minterm.

Con estas dos cosas claras vamos a hacer el blit mas sencillo (que no el mas barato).



Comenzamos con nuestra guia y despejamos.
$AFMMB000

¿Cuantas fuentes voy a usar? Solo 1, la D (destino)
$A1MMB000

como no voy a usar la fuente A y B, no necesitan configuracion
$01MM0000

Nos queda el minterm.....

En este caso no usamos ninguna fuente de origen con la que operar (solo el destino), asi que vamos a utilizar el blitter para borrar.
El minterm $00 significa, "pase lo que pase, el destino es 0" (mas tarde haremos la tabla de verdad)
Con esto, tenemos la doble palabra completa.

$AFMMB000 = $01000000.


Blitter configurado.





Paso 3) Modulos

Aqui se complica la cosa si no dominas el data fetching (recomiendo leer anteriores capitulos)
Como sabemos, la memoria es una linea pero nuestros bitmaps son bidimensionales, tenemos que darle forma usando los modulos.
Lo que sobra en nuestro blit hay que saltaselo.

http://amiga-dev.wikidot.com/hardware:bltxmod


Paso 4) Punteros

Como solo usamos el destino, el puntero a declarar es BLTDPTH/L.
Esto es facil.

http://amiga-dev.wikidot.com/hardware:bltxpth




Paso 5) Arrancar el blitter

Una vez esta todo configurado, es hora de darle la patada al blitter y que empiece a trabajar por su cuenta. Para eso tenemos BLTSIZE
http://amiga-dev.wikidot.com/hardware:bltsize

La forma mas facil de atacar al registro es la siguiente.
Alto del blit*64+Ancho del bit en words.
Un byte para el alto (*64 para desplazarlo a la izda) y otro byte para el ancho (en words)





Resumen:
Queremos hacer el blit de 160x32


.esperablit:
btst #6,custom+DMACONR
bne .esperablit:

move.l #$01000000,custom+BLTCON0
move.w #20,custom+BLTDMOD
move.l #Pantalla,custom+BLTDPTH
move.w #32*64+10,custom+BLTSIZE


Testeamos para ver que el blitter esta libre.
Configuramos con la doblepalabra.
Modulo: La imagen tiene 320 (40 bytes) y nuestro blit 160 (20 bytes), la diferencia (20) es el modulo.
Puntero: Pantalla es el bitmap que usamos de fondo, como no hemos añadido un offset, el blit queda en la esquina.
blitSIZE: El blit tiene 32 lineas de alto y 10 word (160 pixels) de ancho.
En cuanto escribes en BLTSIZE, el blitter se pone en marcha.



Imagen


Tambien podemos aprovechar para cambiar el minterm y usar $FF ("pasa lo que pase, todo a 1")


Imagen


Esto es simplemente una introduccion, mas adelante usaremos fuentes, calcularemos los minterms, el uso del DMA.... por ahora solo queremos familiarizarnos con el lenguaje que vamos a usar.
Adjuntos
Blit1.zip
(2.19 KiB) Descargado 71 veces

Avatar de Usuario
Mlake
Mensajes: 178
Registrado: 27 Mar 2019 19:54
Agradecido : 76 veces
Agradecimiento recibido: 324 veces

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Mlake » 27 Jun 2019 04:00

Cap 6b Blitter: A=D

En la introduccion tocamos un poco por encima la idea del blitter, vimos que con "cuatro" lineas lo tenemos apañado. Hoy vamos a hacer el blit mas tipico y explicaremos las cosas un poco mas a fondo.

Nuestro primer blit no usaba fuentes de origen, simplemente usamos el destino con un minterm sacado de la manga para borrar/rellenar el area que que necesitabamos.
Ahora que tenemos una fuente, podemos empezar a meterle mano al asunto.



Siguiendo la idea del capitulo anterior, para copiar necesitamos seguir una serie de pasos.

1. Esperar a que el blitter esté libre (testeas el bit 14 en DMACONR)
2. Configurar el blit con nuestra "chuleta" $AFMMB000 (BLTCON0/BLTCON1)
3. Mascara de la Fuente A (BLTAFWM/BLTALWM, estas son nuevas)
4. Modulos del origen y el destino (BLTxMOD)
5. Punteros de origen y destino (BLTxPTH/L)
6. Tamaño del blit para empezar a copiar (BLTSIZE)

Vamos al turrón.


1.Esperar a que el blitter esté libre.
Esta es sencilla, simplemente testeamos el bit 14 en DMACONR.
Si está encendido, podemos proceder. Si esta apagado, no podemos interrumpirlo o nos cargaremos el blit en curso.


2. Configurar el blit con nuestra "chuleta" $AFMMB000

http://amiga-dev.wikidot.com/hardware:bltcon0

Para configurar el blitter tenemos 2 words (BLTCON0/1), nosotros los unimos en una doble palabra por comodidad.
La A y la B de nuestra chuleta no las vamos a usar aun, asi que las podemos dejar a 0.
Solo nos queda la F (fuentes/destino) y MM (minterm).

Sabemos que el blitter tiene 3 entradas (ABC) y una salida (D), para encenderlas solo hay que editar el nibble en cuestion.
D= bit 0
A= bit 3
B= bit 2
C= bit 1

En el primer ejemplo usamos 1 (solo la D), ahora usamos 9 (A y D).
$09MM0000

Depende de las fuentes que activemos, gastaremos mas o menos slots.
Tres fuentes mas el destino son 4 words que tienen que pasar por el DMA (slots).

Sin embargo, a la hora de hacer los calculos hay que tener en cuenta unos detalles.

En la introduccion deciamos que el blit mas sencillo (solo D) no era mas el mas "barato".
¿como es posible si una fuente/destino = un word?

La razon es que el blitter (por su funcionamiento) no trabaja con un solo word, siempre va a mirar como minimo la fuente A, por eso se dice que A es gratis. La uses o no, el blitter va a gastar los 2 slots.

Si ademas activamos la fuente B, gastamos otro slot. Ya van 3 (A B y D).
Y si encima activamos la C, gastamos otro. 4 en total.
Esto es entendible ¿no?

Ahora viene la triquiñuela. ;)

Si yo solo enciendo C y D, porque me apetece hacerlo asi, el blitter va a tardar lo mismo que si tuvieras ABC
Si me da por encender B y D, tardaremos lo mismo que AB.
Si quiero gastar el minimo tiempo posible, tiene que ser A y D. Por eso A=D el "rey de los blits".

Moraleja, hay que usar las fuentes en orden (A-->B---->C).



Teniendo claro el nibble F, toca el minterm.


Imagina un bitmap de 1 bitplane, donde cada bit es un pixel. Sencillo ¿no?
Cada pixel puede estar encendido/apagado (1/0).
Ahora metemos un trozo de bitmap en cada fuente (ABC) y empezamos a procesarlas bit a bit.

Esta tabla representa todas las combinaciones que pueden salir de las 3 fuentes.

Imagen


Como solo tenemos la fuente A, nos deshacemos de los demas.

Imagen

Como siempre, A puede estar encendido/apagado (0/1). ¿Hasta aqui todo claro?

Ahora toca saber que queremos en el destino (D).

Si queremos una copia tal cual:
D tiene que ser 0 cuando A sea 0
D tiene que ser 1 cuando A sea 1

Imagen

$F0 es el minterm que necesitamos para copiar de A a D.
Si quisieramos un negativo de A, usariamos $0F (donde A=1,D=0 y viceversa)

Si me he explicado bien, ahora podeis deducir el origen de los minterms que usamos en la introduccion.

Imagen

Da igual la combinacion o el numero de fuentes, D siempre va a ser 0 ($00) o 1 ($FF)

Cuando añadamos mas fuentes, veremos el juego que nos da la tabla.


Ya tenemos nuetra doblepalabra.
$09F00000.





3. Mascara de la Fuente A (BLTAFWM/BLTALWM)

http://amiga-dev.wikidot.com/hardware:bltafwm
Aqui empiezan las novedades, y es que la fuente A tiene bastante jugo.

No solo podemos copiar bitmap tal cual, podemos ponerle una mascara (ocultar los pixels) del pricipio/final.
¿Para que sirve eso? Pues con lo aprendido, lo primero que se me viene a la cabeza es que si el blit solo trabaja de 16 en 16 pixels (1 word), podemos usar esa mascara para tapar lo que no nos cuadre en los extremos.
Por ejemplo, si nuestra fuente/tile/bob tiene 8 pixels de ancho y el blit recorta 16, podemos deshacernos de los otros 8 que sobran en el extremo.

BLTAFWM Mascara de los primeros (FIRST) 16bits/pixels
BLTALWM Mascara de los ultimos (LAST) 16bits/pixels

Como nuestros blits van a cuadrar, usamos $FFFF para que no se pierda nada.




4. Modulos del origen y el destino (BLTxMOD)

El concepto de modulo ya lo conocemos, basicamente saltamos la parte que no queremos tocar.
A la hora de blitear hay que tener en cuenta si nuestos tiles/bobs/caracteres estan sueltos o juntos.

Si estan sueltos, no hay modulo.
Si no, hay que saltarse lo que sobra.

Imagen



5. Punteros de origen y destino (BLTxPTH/L)
Mas de lo mismo, tenemos que tener en cuenta que los offset deben cuadrar a 16 pixels.
Si un tile está en PANTALLA, el siguiente en PANTALLA+2, el otro en PANTALLA+4 .... asi hasta el ultimo en PANTALLA+38, ya que PANTALLA+40 cae en el siguiente renglon y no interesa.
De ahi saltamos las lineas necesarias segun el alto del tile/bob/caracter.


6. Tamaño del blit para empezar a copiar (BLTSIZE)

Esto lo vimos en la introduccion, BLTSIZE dispara el blit al recibir las dimensiones del mismo.
El word tiene el formato $ALaw (ALTO EN LINEAS ancho en words)




Como es esto en codigo.

WaitBlit
move.l #$09f00000,custom+bltcon0
move.l #$ffffffff,custom+bltafwm
move.w #0,custom+bltamod
move.w #38,custom+bltdmod
move.l #Tile0,custom+bltapth
move.l #Pantalla,custom+bltdpth
move.w #16*64+1,custom+bltsize

Macro que espera al blitter
Configuramos blitter: A=D
Sin mascara, que se vea todo.
Modulo de A: 0 porque el tile esta suelto
Modulo de D: 38 porque el tile tiene 2 bytes(16px) y la pantalla 40(320px)
Puntero del tile en A
Puntero de Pantalla en D
Blit de 16 de alto por un word (16pix) de ancho.



Como siempre dejo un ejemplo sin mucha complicacion.
Hay que aprender a ubicarse en pantalla usando offsets de 16 pix (2bytes)

Simplemente generamos un tileset con 4 tiles + 1 en blanco. todos en el mismo bitmap, por lo que hay que usar modulos. OJO.

Imagen


Podemos editar añadir mapas, toquetead con otros tamaños (respetando los 16pixels)....

PD: Necesito feedback, a veces no se si quedan las cosas claras o no.
Adjuntos
Blit2.zip
(3.42 KiB) Descargado 58 veces

Avatar de Usuario
Chema
Mensajes: 2664
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 3190 veces
Agradecimiento recibido: 926 veces
Contactar:

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Chema » 27 Jun 2019 09:52

¡Vaya explicación más buena del blitter que estás haciendo! Yo, que ya había hecho alguna cosa, lo estoy disfrutando porque ahora tengo alguna cosa mucho más clara.

Al final, si has implementado alguna vez una rutina que haga un blit más o menos genérico, le pillas el truco, porque es muy parecido a lo que se suele hacer por software (incluyendo máscaras cuando llegues). A mí me recuerda incluso al BlitBlt de las API de Windows XD, aunque con "cosillas".

Como yo ya había hecho algo con el blitter (tengo que pasarlo a un gif animado para ponerlo aquí) pues no estoy haciendo los deberes esta vez, pero ten por seguro que tengo cosas en mente... en cuanto tenga tiempo (no sé cuándo, pero será) posteo algo.

Tengo que mirar tu ejemplo (aún no lo he hecho) para ver cómo manejas el tileset, porque es una de las cosas que necesito. Imagino que será poner los offsets correctos y alinear los tiles bien, pero fijo que alguna cosilla más se me escapa.

De verdad que este hilo está quedando canela fina... De lo mejorcito que he visto en RW. Es una lástima que la gente le tenga un poco de respeto a programar en asm, porque es sencillo de seguir y estaría bien que la gente se animase. ¡Es muy divertido!

Avatar de Usuario
Mlake
Mensajes: 178
Registrado: 27 Mar 2019 19:54
Agradecido : 76 veces
Agradecimiento recibido: 324 veces

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Mlake » 28 Jun 2019 00:52

Chema escribió:[...]
Tengo que mirar tu ejemplo (aún no lo he hecho) para ver cómo manejas el tileset, porque es una de las cosas que necesito. Imagino que será poner los offsets correctos y alinear los tiles bien, pero fijo que alguna cosilla más se me escapa.

[...]




Se puede hacer de varias maneras segun te cuadre.


Imagen


Estamos trabajando a un bitplane (para pillar conceptos), asi que he elegido la primera forma. ¿por que? porque solo tengo que leer el byte del mapa (0,1,2,3,4.. hasta el hipotetico tile 255), multiplicarlo por dos (lo sumo a si mismo para ahorrar) y ya tengo el offset con respecto a tileset.
Ademas, como el blit va a ser de 16 o de 32, el calculo del offset lo apañas con una suma o como mucho desplazando bits que es mas barato que multiplicar.
¿Las pegas? que tener bitmap de 2500 (un suponer si se nos va la mano con los tiles) por 16 es un poco desastroso para editar. :D
Ademas hay que modificar el modulo si aumentas o disminuyes el numero de tiles.

La segunda forma es mas normal, un bitmap de X por Y tiles.
Facil de editar, el modulo no cambia ya que tienes hueco en vertical para apilar.
El probrema es que calcular el offset requiere lidiar con filas/columnas y eso es mas caro.

La tercera forma es una mezcla entre las dos y ademas te despreocupas por el modulo.
El calculo del offset es asequible, facil de editar.....


A la hora de ponerlos en pantalla, solo es la tipica lectura/escritura que arreglas con un par de "FOR/NEXT" para X e Y.
Primero una fila, cambias de renglon, la otra y asi.....



Por lo demas, aqui estamos para cualquier cosa. -thumbup

Avatar de Usuario
Mlake
Mensajes: 178
Registrado: 27 Mar 2019 19:54
Agradecido : 76 veces
Agradecimiento recibido: 324 veces

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Mlake » 30 Jun 2019 02:04

CAP 6c Afinando A=D.

A los que ya dominan el tema, quiero que comprendan que la cantidad de burradas que puedan aparecer son para intentar explicar conceptos, sobre todo al principio.

Hasta ahora hemos hecho blits basicos, clavados a 16pixels. Esto es util para hacer mapas, componer fondos/logos a base de tiles.... pero para mover algo por la pantalla, no sirve. (Mas adelante veremos que si)


Shifting. (No, no esa guarrada de los puños.)

El "desplazamiento" consiste en empujar nuestro BOB X pixels a la derecha, para poder compensar los saltos de 16 en 16.
Al igual que pasaba con el scroll, tenemos un nibble que nos permite afinar esos pixels.

¿Recordais nuestra chuleta $AFMMB000? Pues ahi teneis de donde viene la A, el nibble que buscamos.
Antes poniamos 0 porque sabiamos que los blits estaban cuadrados al milimetro, ahora podemos ponerlos donde queramos sin preocuparnos.


Por ejemplo:
Si tu BOB está en X=20 (Y=0), sabemos que el offset es +2 bytes (16 pix) y necesitamos un desplazamiento de 4 pixels (16+4=20).
No es dificil, dividimos la X entre 16 y el resto será nuestro shift. Lo metemos en BPLCON0 usando la chuleta y listo.

La teoria es facil, pero siempre hay truco.....




Imagen

Aqui empieza la pega.....
Tenemos nuestro blit con su tamaño correcto pero al desplazar el BOB se nos queda a medio fuera. :(

¿Como lo arreglamos?


Imagen




Lo primero, tendremos que blitear un word extra para poder hacer el desplazamiento y que se siga viendo el BOB, el problema es que al copiar 2 words, arrastramos cosas que no queremos.

Ahi entran BLTAF(L)WM . {Blitter A first(last) word mascara}
Cuando el blitter hace el shift, deja limpia la parte a la izquierda del BOB, pero la derecha queda "manchada". Por eso aprovechamos esos registros para limpiar lo que queda de blit.

Asi que ya podemos ver que un blit bien cuadrado es mas barato que uno "shifteado" (+1word).






El ejemplo de hoy:

Reutilizamos el anterior, esta vez le añadimos un BOB corriendo de izda a dcha.
Movemos usando una variable (blitX).

Antes de "dividirlo" (movemos bits a la dcha), sacamos el resto (el nibble para shifting).
Para no andar con historias, hay una tabla con todos los desplazamientos hechos:

$09F00000
$19F00000
$29F00000
$39F00000
.
.
.

El resto que sacamos para el shifting, lo usamos como offset de la tabla y dejamos ya configurado BPLCON0/1.



Una vez hecho, nuestro BOB corre libremente.


Imagen


Algo pasa. :(

Vale que nos manche el fondo, al fin y al cabo estamos copiando cosas en él.. ¿que es lo que ocurre?
Que nos hemos olvidado de enmascarar las sobras y se ha formado un "pegote".

Una vez arreglado (BLTALWM a $0000). Tenemos otro aspecto....



Imagen

Esto esta mucho mejor, pero hay algo raro.
Al shiftear dijimos que la parte izquierda quedaba limpia y resulta que no. ¿Por que?

No mentí cuando dige que al desplazar, la izda quedaba limpia.
El problema es que cada 16 pixels, el nibble vuelve a 0 y no hay shift, asi que esa barra queda atras.
Toca perder tiempo en borrar... :(



Un momento, nos estamos desplazando a un pixel.
¿Y si me da por quitarle ese mismo pixel y santas pascuas? a lo mejor nadie se da cuenta y me ahorro tener que borrar el BOB.

Ahora toca hablar con BLTAFWM, en este caso vale un $7FFF (muestra todos menos el primero de la izda)

Imagen

Tampoco ha quedado tan mal. Con lo que sabemos, nos ha salido resulton.


Ahora (por fin) podemos hacer un blit extra para borrar lo que nos queda al final y santas pascuas. Aunque con lo aprendido en el curso podriamos hacer un mapa un poco mas grande y ocultar la zona.


Imagen


Alguno se estará mordiendo las uñas esperando a saber como hacer blits mas complejos, para no tener que hacer tanta triquiñuela y no perder esos fondos que se han currado.
Hasta ese momento, tenemos que darle un par de vueltas mas al blitter, como he dicho varias veces, AD es la combinacion mas "versatil".

Mientras tanto, toca aguantar....... :(


















¿o no?

Imagen


Solo hay 2 cambios en el codigo.
El mapa lo pintas en una pantalla y el BOB otra, para todo lo demas, el DUAL PLAYFIELD que conocemos (solo es cambiar el valor de BPLCON0 en la copperlist). ;)
Si no necesitas mucho color, te puede salvar el pellejo mas de una vez.
Algunos lo llaman FASTBOBs, por aquello de ahorrarte la "mezcla" con el fondo.

Espero que no se haya hecho un coñazo. :(
Adjuntos
Blit3.zip
(3.79 KiB) Descargado 74 veces

Avatar de Usuario
Mlake
Mensajes: 178
Registrado: 27 Mar 2019 19:54
Agradecido : 76 veces
Agradecimiento recibido: 324 veces

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Mlake » 09 Jul 2019 08:23

Cap 6d Descending mode, el mundo al reves.

A los que ya dominan el tema, quiero que comprendan que la cantidad de burradas que puedan aparecer son para intentar explicar conceptos, sobre todo al principio.

A la hora de mover nuestros BOB en horizontal, vinos que no habia mucho problema.
Calcular el offset, añadir los pixels extras (si hacen falta) usando el shift y tapar la "basura" con las mascaras de A (BLTAFWM). Perfecto.
En vertical parece que no deberia haber problemas, pero siempre hay truco. ;)



Vamos a hacer un ejercicio mental con una "imagen" muy simplificada para pillar la idea.
Usaremos el blit basico A=D y nuesto plan es mover un icono (mini WB3.1) que hay en pantalla.
Hoy estamos escasos de memoria asi que no nos podemos permitir el lujo de guardar copias o estar gastando mucho tiempo en borrar....



Cuando el BOB se desplaza hacia arriba, la cosa va bien.

Imagen

No nos ha hecho falta ni borrar, solo dejar que el blitter corriera un poco mas para taparnos la basura. Hasta aqui todo bien y barato.



¿Que pasa cuando el BOB se mueve hacia abajo? Que se lia parda.....

Imagen

Al estar leyendo y escribiendo en el mismo buffer, el blitter nos "pisa lo fregado".

Primero mueve la linea 1 al sitio de la linea 2.
Cuando va a leer la linea 2 (para bajarla a la tres), ya no existe porque nos la hemos cargado en el paso anterior. :(
Por eso solo vemos la primera linea del blit.



¿Como lo arreglamos? Dandole la vuelta al blitter.

La configuracion la teniamos en nuesta doble palabra $AFMMB000.
http://amiga-dev.wikidot.com/hardware:bltcon0

Ahora pasaria a ser $AFMMB002.

Ademas ya no tenemos que apuntar al primer word de nuestro blit sino al ultimo.

Imagen

Con esto desplazamos el BOB hacia abajo y con unos words mas, limpiamos los restos.



Esa es la funcion del descending mode, si la fuente y el destino se solapan, hay que hacer el blit al reves para poder moverlo hacia abajo.






¿Para que nos puede servir esto, ademas de lo explicado anteriormente?
Hoy empezaremos un scrolltext sencillo.



Partimos de una pantalla con algo de morralla para que podais apreciar el efecto.

Imagen


Elegimos una zona de trabajo, para no liarnos lo vamos a dejar todo al descubierto.
Nuestra fuente es de 16x16 asi que con 16 lineas nos da.



¿Como hacemos el scroll con el blitter?

La idea es copiar un trozo de pantalla sobre si misma, pero shifteando X bits.

La zona va a ser 320x16, asi que ya tenemos el tamaño del blit. 16 lineas x 20 words
Modulos 0. Vamos a usar toda la linea, no hay nada que saltar.
Punteros, A= Pantalla D=Pantalla. Simple, es la esquina superior izda.
Mascara de A, $FFFFFFFF lo queremos todo.
Configuracion $19f00000. A=D pero shifteado 1 pixel



Con estos datos armamos el blit y conseguimos esto.

Imagen

¿Se entiende la idea? Leemos una linea con A, la desplazamos un pixel y la volvemos a copiar a D.





España es Asturias, lo demas es tierra conquistada.

El shifting del blitter funciona desplazandose a la derecha y nosotros necesitamos lo contrario, que desplace a la izda para que podamos sacar el texto por el lado derecho.
Ahi entra el descending mode (DM), al hacer el blit al reves el shift tambien se da la vuelta. ;)

Si alguno hace un scroll en arabe, japones... no lo necesita.



En la practica todo queda casi igual que antes.

La zona va a ser 320x16, asi que ya tenemos el tamaño del blit. 16 lineas x 20 words
Modulos 0. Vamos a usar toda la linea, no hay nada que saltar.
Mascara de A, $FFFFFFFF lo queremos todo.

Los cambios:

Configuracion:
$19f00002
A=D pero shifteado 1 pixel a la derecha + DM activado (pixel a la izda).

Punteros:
A= Pantalla+ (40*15+38)
D= Pantalla+ (40*15+38)
El blit tiene 40 bytes de ancho, asi que el ultimo word cae en el byte 38.
El blit tiene 16 lineas de alto, asi que la ultima linea empieza en 15 (uno menos)*40
Los sumamos y tenemos el offset respecto a Pantalla.


Con el blitter del reves, conseguimos esto.

Imagen

Ya tenemos el scroll en marcha, mas adelante empezaremos a escribir.

Como siempre perdon por la chapa.

Avatar de Usuario
Chema
Mensajes: 2664
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 3190 veces
Agradecimiento recibido: 926 veces
Contactar:

Re: Toqueteando las tripas del OCS en ASM. Nivel -1

Mensajepor Chema » 02 Ago 2019 09:58

Bueno, he estado ahogado con temas del trabajo y no he podido hacer nada :( Además, ahora Llega esa época en el año en la que uno disfruta lo que puede con la familia y eso deja poco tiempo libre para vicios :)

Prometo hacer lo posible para seguir aprendiendo cosillas de programación con el Amiga. De hecho ya tengo ideas de qué cosas quiero probar estos días... a ver si se logra.

Mlake, no dejes de avanzar con este hilo, que está quedando genial. Ya van 8 páginas ¡y lo que falta!

Tengo muchas ganas de que llegues al modo de línea del blitter.


Volver a “Software & OS Amiga”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 2 invitados