Toqueteando las tripas del OCS en ASM. Nivel -1

[Mlake]

Último mensaje de la página anterior:

Esto me pasa por meterme en foros atarianos....


quiero ver mis fotos

Por fin me ha dejado editar el post.

[kikems]

Esto me pasa por meterme en foros atarianos....

Y los atarianos se quejan de que sea un foro de amigueros.

[Chema]

Gracias Mlake! Ahora está aún más claro... Tienes que tener paciencia conmigo, que a veces leo en diagonal y estamos en esa edad en la que leemos una cosa y se nos olvida

Mi pregunta con respecto a la posición del sprite es porque sólo hay 8 bits para la posición x, pero la resolución es de 320, que no cabe (entiendo que la posición X no está dada en bytes de 0 a 39).

En un hrm que hay en la red (http://amigadev.elowar.com/read/ADCD_2. ... e00BB.html) especifica que el bit alto tanto de HSTART como de VSTART están en la palabra de control, así que ambas pasarían a ser de 9 bits y llegar de 0 a 511 que ya es suficiente... un poco incómodo, pero tiene sentido. ¿Es así o se me pasa algo?

También dices que los bitmap en Amiga "siempre van entrelazados" y es que yo había entendido que eso dependía de la configuración de la pantalla. Entre eso y que mi conversor de imágenes soporta un "modo entrelazado" con una opción, creí que se podía tener también sin entrelazar. Vamos, que me armé un poco de lío.

Por último, lo de la paleta ya está aclarado, gracias La cosa es que tu bitmap tiene que ser quien indique el color transparente al ponerlo en como código 0 (primera entrada de la paleta). Estaba usando el MSPaint guardando a 256 colores (luego el conversor coge menos, si se lo pido) y se empeña en poner la primera entrada como color negro, sin dejarme reorganizar la paleta.

Creo que Gimp sí que deja, así que es cosa de buscar las herramientas adecuadas.

Lo dicho, mil gracias por las aclaraciones.

[Salva]

Genial este hilo!
Lo que gente como yo que en mi época del Amiga (88 - 91), no encontré ninguna información en castellano, ningún source de ejemplo ni nadie que me pudiera orientar...
Así que siguiendo el curso y deseando más entregas... Más efectos "oldschool"...
Como me comentaste MLake, scrolltext con letras bailarinas y por ejemplo un efecto de movimiento de degradado con el copper dentro de un gráfico de un bitplane...
Felicidades MLake por la iniciativa ( que sepas que hay gente que seguimos el curso con ganas ) y a ver si esto no se queda aquí y la gente que sabe va aportando y enriqueciendo con más cosas.
Gracias.

[kikems]

Me alegra ver que más y más gente se va apuntado al curso, la verdad que es una gran oportunidad que nos brinda Mlake. Yo voy un poco retrasado, he faltado a un par de clases y me he perdido, a ver si saco tiempo y me pongo al día.

PD: Salva, please, postea en el hilo de presentaciones.

[Mlake]

Gracias Mlake! Ahora está aún más claro... Tienes que tener paciencia conmigo, que a veces leo en diagonal y estamos en esa edad en la que leemos una cosa y se nos olvida

Mi pregunta con respecto a la posición del sprite es porque sólo hay 8 bits para la posición x, pero la resolución es de 320, que no cabe (entiendo que la posición X no está dada en bytes de 0 a 39).

En un hrm que hay en la red (http://amigadev.elowar.com/read/ADCD_2. ... e00BB.html) especifica que el bit alto tanto de HSTART como de VSTART están en la palabra de control, así que ambas pasarían a ser de 9 bits y llegar de 0 a 511 que ya es suficiente... un poco incómodo, pero tiene sentido. ¿Es así o se me pasa algo?

También dices que los bitmap en Amiga "siempre van entrelazados" y es que yo había entendido que eso dependía de la configuración de la pantalla. Entre eso y que mi conversor de imágenes soporta un "modo entrelazado" con una opción, creí que se podía tener también sin entrelazar. Vamos, que me armé un poco de lío.

Por último, lo de la paleta ya está aclarado, gracias La cosa es que tu bitmap tiene que ser quien indique el color transparente al ponerlo en como código 0 (primera entrada de la paleta). Estaba usando el MSPaint guardando a 256 colores (luego el conversor coge menos, si se lo pido) y se empeña en poner la primera entrada como color negro, sin dejarme reorganizar la paleta.

Creo que Gimp sí que deja, así que es cosa de buscar las herramientas adecuadas.

Lo dicho, mil gracias por las aclaraciones.

Despreocupate, lo ultimo que queremos son prisas.
Es preferible repetir las cosas 20 veces ,antes que avanzar dejando cabos sueltos.

Por ahora nos interesa pillar la idea y despues empezar a hilar fino.
De momento solo queremos saber que es cada cosa, posicion inical Y, posicion inicial X, posicion final Y y byte de control. Ya trabajaremos mas adelante con ellos.

Si tienes curiosidad, te lo adelanto.

La posicion de X se mueve de 2 en 2 pixels. La posicion 0 es el pixel 0 en pantalla, la posicion 1 es el pixel 2, la posicion 2 es el pixel 4, la posicion 3 es el pixel 6......
Por cada 8 que mueves la X, avanzas 16 pixels. Asi que con un byte te da para los 320 pixels de la imagen + el overscan.
Si quieres moverte pixel a pixel en horizontal tienes que hacer algo parecido a los blits, colocas el sprite en la zona par mas cercana y "shifteas" un pixel usando el bit 0 del byte de control.
Por ejemplo: quiero colocar el sprite en X=33.
La X seria 16 (porque van de dos en dos,dando como resultado 32) y ademas tendria que desplazar un bit para llegar a la 33.
Como te digo, veremos el byte de control en la proxima entrega.
Por ahora solo hay que entender que un sprite consiste en IMAGEN, POSICION y PALETA, aunque no tengamos idea de que es cada cosa.



Sobre los bitmaps:

Imagino que por el idioma ingles, la palabra entrelazado da lugar a confusion.

Una cosa es un MODO DE VIDEO ENTRELAZADO, ahi entra el monitor, la forma en la que se mueve el rayo.....

Otra cosa es un BITMAP ENTRELAZADO, donde la palabra "entrelazado" da a entender que los bitplanes que forman la imagen estan ""mezclados"" como hemos visto a lo largo del hilo.

111111111111111111
111111111111111111
111111111111111111
111111111111111111
111111111111111111
111111111111111111
111111111111111111
....




Uno es un entrelazado FISICO (el monitor) y otro es LOGICO (los bitmaps)

Por eso existe el modulo (tanto a la hora de poner un fondo o hacer un blit) para desplazarnos dentro de esos bitplanes ""mezclados"" (entrelazados).
¿Que a lo mejor viniendo de otra plataforma parece una perdida de tiempo? Puede ser, pero cuando le pilles el truco le veras el sentido de tenerlos mezclados.



Sobre los programas de edicion, te puedo decir lo que hago yo.

Deluxe Paint para dibujar y guardo en .iff

Kefren´s IFF converter
https://www.youtube.com/watch?v=5sftmTU ... .be&t=2921
La opcion RAW BLIT es la que necesitamos para generar bitmaps entrelazados, tambien podemos guardar la paleta en formato copperlist, generar sprites.....

Intenta buscar algo equivalente o montarte un UAE para esto.


Espero haberte echado una mano. Siento lo de los programas pero me sacas del Amiga y ando pez.

[Mlake]

Genial este hilo!
Lo que gente como yo que en mi época del Amiga (88 - 91), no encontré ninguna información en castellano, ningún source de ejemplo ni nadie que me pudiera orientar...
Así que siguiendo el curso y deseando más entregas... Más efectos "oldschool"...
Como me comentaste MLake, scrolltext con letras bailarinas y por ejemplo un efecto de movimiento de degradado con el copper dentro de un gráfico de un bitplane...
Felicidades MLake por la iniciativa ( que sepas que hay gente que seguimos el curso con ganas ) y a ver si esto no se queda aquí y la gente que sabe va aportando y enriqueciendo con más cosas.
Gracias.

Buenas Salva.
Aqui andamos, sacando tiempo de cualquier lado.

Con lo que hemos aprendido, podemos colar algun degradado copper.
Cuando pongamos nuestros primeros sprites aprovecharemos el codigo para intentar meter el efecto por algun lado y asi repasamos las copperlist.

De todos modos, puedes echar un ojo a ejemplos anteriores.



En este (por ejemplo) la copperlist ataca a COLOR00 (rutina Coppersky:). Si lo cambias a COLOR01 ya tienes el degradado dentro del bitmap.
Ahora solo tendrias que cambiarle los colores, o mover los puntos de espera....


Para el Scrolltext es mejor esperar a llegar al blitter.

Me alegra ver que más y más gente se va apuntado al curso, la verdad que es una gran oportunidad que nos brinda Mlake. Yo voy un poco retrasado, he faltado a un par de clases y me he perdido, a ver si saco tiempo y me pongo al día.

PD: Salva, please, postea en el hilo de presentaciones.

Lo mismo que a Chema, no hay prisas. Y si hay que repetir/explicar algo, se hace.

[Chema]

Si tienes curiosidad, te lo adelanto.

La posicion de X se mueve de 2 en 2 pixels.
<ZAS>
Como te digo, veremos el byte de control en la proxima entrega.

Jajajaja, vale. O sea que el bit extra de la palabra de control es para eso, pero el peso no es el que yo había supuesto. En lugar de ser el bit de peso más alto, es el de peso más bajo.

Creo que lo he entendido.

Sobre los bitmaps:

Imagino que por el idioma ingles, la palabra entrelazado da lugar a confusion.

Una cosa es un MODO DE VIDEO ENTRELAZADO, ahi entra el monitor, la forma en la que se mueve el rayo.....

Otra cosa es un BITMAP ENTRELAZADO, donde la palabra "entrelazado" da a entender que los bitplanes que forman la imagen estan ""mezclados"" como hemos visto a lo largo del hilo.
<ZAS>

¿Que a lo mejor viniendo de otra plataforma parece una perdida de tiempo? Puede ser, pero cuando le pilles el truco le veras el sentido de tenerlos mezclados.

Aclarado, aclarado. Yo siempre me referí al entrelazado LÓGICO, por decirlo de algún modo. Y me parece una excelente idea, no una pérdida de tiempo, porque se puede blitear toda una zona con un sólo blit. Al menos por eso ya creo que merece la pena. Es que en mis experimentos con el blitter solo usaba un plano, por eso no lo tengo pillado.

Mmmmm creo que voy a tener que hacer otro intento con más colores, aunque sea por aclararme mejor

Mil gracias!!!

[Mlake]

La posicion de X se mueve de 2 en 2 pixels.

Jajajaja, vale. O sea que el bit extra de la palabra de control es para eso, pero el peso no es el que yo había supuesto. En lugar de ser el bit de peso más alto, es el de peso más bajo.

Creo que lo he entendido.

Los que tienen un bit extra para la posicion son la Y inicial y la Y final, por aquello de que el display PAL va desde la linea $2c hasta la $12c (256 lineas).

Los bits extra en la X son para "afinar" la situacion ya que en ese eje funciona de 2 en 2 pixels.

Un bit para desplazar 1 pixel, otro para desplazarlo "medio pixel" y otro para desplazarlo "un cuarto" de pixel.

04 Start horizontal value, 70nS increment -----------------Medio Pixel a la derecha
03 Start horizontal value 35nS increment------------------Cuarto de pixel a la derecha
02 Start vertical value 9th bit--------------------------------Bit que nos falta en Y inicial
01 End (stop) vertical value 9th bit--------------------------Bit que nos falta en Y final
00 Start horizontal value, 140nS increment----------------Un pixel a la derecha

[Chema]

Lol, ok. No vuelvo a intentar adivinar nada

[Mlake]

Lol, ok. No vuelvo a intentar adivinar nada

Adivinar y toquetear es lo mejor para aprender, asi que por ese lado hay que estar tranquilo.

Si te quieres entretener te propongo un ejercicio.

Como tienes la fuente del ejemplo de sprites, veras que el loop principal es asi:

move.l #sprite0+1,a0 ---------------- Sprite0+1 apunta al byte de la X de Sprite0
move.w #8-1,d0------------------------8 vueltas para 8 sprites en uso
.l:
sub.b #1,(a0)------------------------Le quito uno a la X
add.l #608,a0----------------------Sumamos los word de control, los de final y el sprite de 150 lineas
dbf d0,.l--------------------------------nos da 608 bytes hasta el siguiente spriteX.


Lo que haciamos era incrementar en 1 los byte X de cada sprite.


Ahora borralo cambialo por esto.

move.w custom+joy0dat,d0-----------------El estado del raton/joy esta en JOY0DAT/JOY1DAT
move.w d0,Sprite0--------------------------- muevelo tal cual al word de posicion del sprite
add.w #$9600,d0---------------------------el ejemplo tenia 150 lineas de alto ($96), se lo sumamos
and.w #$ff00,d0----------------------------para tener la Y final y limpiamos el otro byte (por si).
move.w d0,Sprite0+2------------------------En sprite+2 colocamos la Y actualizada y el control a $00


Ya tienes funcionando un puntero de raton. Se va a ver como el ojete porque es muy largo, pero seguro que eres capaz de hacerlo con uno mas manejable.

Esto a lo mejor te ayuda:

http://amigafonteditor.ozzyboshi.com/index_sprite.html

[Mlake]

Cap 4a Sprites en movimiento

En el post anterior comentamos los requisitos para montar un Sprite.
El dibujo del sprite en si (16pixels/ancho y 2 bitplanes), el word de posicion ($YYXX), la YFinal ($YF), el byte de control ($CC) y su paleta.

Hoy vamos a intentar darles vida.



¿Como armamos un sprite?

SpriteX:

dc.w $YYXX,$YFCC ;Posicion,YFinal+byte de control
dc.w $f0f0,$0f0f ;Nuestro dibujo
dc.w $f0f0,$0f0f
dc.w $f0f0,$0f0f
dc.w $f0f0,$0f0f
...... Tantas lineas como necesites
dc.w 0,0 ;Fin del Sprite

Tambien puedes hacer esto:

dc.w $YYXX,$YFCC ;Posicion,YFinal+byte de control
INCBIN "Spriteloquesea.raw" ;Bitmap preparado en formato raw
dc.w 0,0 ;Fin del Sprite


¿No tiene mucha dificultad verdad? Vamos a apretarlos un poco mas.

dc.w $YYXX,$YFCC ;Posicion,YFinal+byte de control del primer uso
INCBIN "Spriteloquesea.raw" ;Bitmap en formato raw del primer uso

dc.w $YYXX,$YFCC ;Posicion,YFinal+byte de control del segundo uso
INCBIN "Spriteloquesea.raw" ;Bitmap en formato raw del segundo uso

dc.w $YYXX,$YFCC ;Posicion,YFinal+byte de control del tercer uso
INCBIN "Spriteloquesea.raw" ;Bitmap en formato raw del tercer uso

dc.w 0,0 ;Fin del los usos del sprite


¿Que quiere decir esto? Que en principio podemos reutilizarlo tanto como quieras, siempre que no se "solapen" en la coordenada Y.

Por ej:
Si un sprite termina en la linea 10 , tienes que esperar a la 11 para "reciclarlo".




Teniendo claro como montarlo, ahora hay trabajar con el.

Lo primero, como hemos hecho otras veces, tenemos que indicar donde esta el sprite.
Para eso tenemos los alias SPRxPTH/L, donde la x va de 0 a 7.
Aqui no hay que preocuparse por modulos y bitplanes, con apuntar a nuestro codigo anterior es suficiente. Solo hay que cumplir una norma:
Hay que declarar los 8 sprites, aunque no los uses. De otra forma te pueden salir porquerias en pantalla.
¿Y donde los apunto si solo dibujé uno?
Para eso está el sprite dummy o nullsprite.

nullsprite:

dc.w 0,0 ;Posicion y control
dc.w 0,0 ;Dibujo
dc.w 0,0 ;Fin de sprite


Asi, tal cual. todo a 0.





Sobre la paleta.... Ya sabemos que nuestro rango de colores va desde COLOR16 hacia arriba.
¿Pero como se reparten? La paletas de sprites se reparten por parejas.

El 0 y el 1 tienen como paleta COLOR16, COLOR17, COLOR18 y COLOR19
El 2 y el 3 tienen como paleta COLOR20, COLOR21, COLOR22 y COLOR23
El 4 y el 5 tienen como paleta COLOR24, COLOR25, COLOR26 y COLOR27
El 6 y el 7 tienen como paleta COLOR28, COLOR29, COLOR30 y COLOR31

En la introduccion aprendimos que el color 16 se destruia para crear la transparencia, pues ahora se van a la puñeta tambien el COLOR20, COLOR24 y COLOR28




Si sabemos como crearlos,como darles color y como apuntar hacia ellos, solo nos queda empezar.

Lo primero, tener encendidos los sprites (ver alias DMACON). Pero ATENCION, hay que apagarlos antes de que llegue el vblank/fin del frame o seguramente os apareceran unas bandas verticales en la parte izda de la pantalla ("restos" en el DMA de sprites).
Por eso hay que apagarlos. Despues los encendemos con la copperlist (al inicio) y listo.

Por ej:

incicio del frame:

DMACON $87e0 Todo encendido excepto audio
.
.
.
Llegamos al final del frame
DMACON $87c0 Todo encendio excepto audio y SPRITES





Si tenemos esto claro, podemos pasar al plan:



No hay nada que no hayamos hecho, es muy parecida al "efecto agua" que conocemos. La novedad es el uso de sprites.

Solo he usado el sprite 0 para empezar, pero lo he reutilizado 3 veces sin cambiar el bitmap.
Asi podeis ver como va el tema (los 7 que faltan van a un nullsprite).

La posicion es intuitiva de conseguir si no nos importa movernos de 2 en 2 pixels (eje X), podeis trastear hasta pillarle el punto.

En el proximo post veremos el byte de control,aun asi el ejemplo de hoy tiene algo en ese sentido
El sprite de en medio se mueve pixel a pixel y el de abajo esta en una zona fuera de lo que permite un byte $XX. Todo esto gracias al byte de control.





Podriais "regalarme" unos bitmaps y/o unos logos, que estos ejemplos quedan muy cutrones.....
Para perdir, todo el mundo esta puesto, pero nadie se moja.
Si yo no fuera tan manco con el paint....

[Chema]

Hala, ya tengo trabajo. Y eso que no he hecho el puntero del ratón que tenía como deberes adicionales XD.

Este finde va a estar más complicado, que tenemos la Asturgaláica, pero para la semana que viene lo hago. No avances demasiado, por favor, que me quedo atrás

[Salva]

Disculpa por haberlo subido.
Es cierto, hay que pedir permiso.
No pasa nada, lo quito.
Gracias.

[kikems]

....

Podriais "regalarme" unos bitmaps y/o unos logos, que estos ejemplos quedan muy cutrones.....
Para perdir, todo el mundo esta puesto, pero nadie se moja.
Si yo no fuera tan manco con el paint....

Yo personalmente prefiero cosas así cutres y muy simples;

1º- no parece todo tan complejo y por tanto no asusta tanto, parece algo más abordable.
2º- visualmente es más comprensible y no corres el riesgo de confundir un efecto de código con un detalle de pixel art. Si vas a explicar un concepto, lo mejor es usar diseños conceptuales.

Como post del resumen de los capítulos si está bien aplicar lo aprendido con unos buenos gráficos, para que la gente se de cuenta del potencial de la información ofrecida, pero durante el proceso de aprendizaje y explicación prefiero el material "simple".

[Mlake]

Hola MLake...

Adjunto unos gráficos a ver si pueden servir.

En el .zip están en .iff

Lo primero, gracias por las molestias que te has tomado.

En principio no querria ripear material ajeno, por eso he tirado de ejemplos chusteros para explicar los efectos. Mi idea era que si algun forero grafista quiere que montar algo con lo que ya sabemos, poder aprovechar e incluso hacer cosas nuevas como alguna transicion chula, algun scroll o algo asi....

No me gustaria usar material ajeno sin permiso. Usé el logo de Retowiki porque no creo que haya pegas estando en el foro.

Yo personalmente prefiero cosas así cutres y muy simples;

1º- no parece todo tan complejo y por tanto no asusta tanto, parece algo más abordable.
2º- visualmente es más comprensible y no corres el riesgo de confundir un efecto de código con un detalle de pixel art. Si vas a explicar un concepto, lo mejor es usar diseños conceptuales.

Como post del resumen de los capítulos si está bien aplicar lo aprendido con unos buenos gráficos, para que la gente se de cuenta del potencial de la información ofrecida, pero durante el proceso de aprendizaje y explicación prefiero el material "simple".

A no me importa seguir con ejemplos chorra, pero como le decia a Salva, mi idea era interactuar con los foreros y si algun musico/grafista quiere empezar a hacer sus propios slideshows, efectos de copper en sus dibujos, etc.... usando lo que ya sabemos, pudiera empezar a abordarlos.
De la misma forma que cuando veamos el P61, hubiera pedido algun MOD a los foreros.

No solo estar dando la chapa con tochazos infumables.

Muchas gracias por la sugerencia.

[kikems]

Aquí te comparto los MOD de la Compo de AW celebrada en 2016, siempre que no se usen con fines comerciales, como es el caso, no tienen problemas, es más los autores encantados y orgullosos de que la gente los pueda usar.
Los autores son ; Joss, Fernando Cabrera, Uctumi, Fireboy y Trojar.

AmigaWaveWeekCompoI2016.rar

(30.95 KiB) Descargado 51 veces

De gráficos, a ver si rescato algunos render 3D y los podemos adaptar a modo de prueba.