Toqueteando las tripas del OCS en ASM. Nivel -1

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 Sep 2021 16:50

Último mensaje de la página anterior:

mgyv escribió:Una vez inicializado el framebuffer, aunque sea a 4 colores, necesitaba hacer unas tablas de senos/cosenos, y me he animado a hacer un programita en blitz basic 2 para generarlas. Sé que está la aplicación de windows, Sinus creator (que es muy completa, por cierto), pero me da rabia tener que hacer los archivos en Windows y traerlos al amiga (sobre todo después de ver las últimas retrocriptas de Microsoft de Ron, -rofl )
He intentado añadir el código fuente, pero no me deja adjuntar extensión .bb2. Lo dejo en zip, por si a alguien le interesa.
No me deis mucha caña, que es mi primer programa en Blitz....Para compilarlo hace falta el deflibs de 150k del disco de extras. Ah, y solo lo he probado en WB3.1. -nosweat

download/file.php?mode=view&id=200025046

download/file.php?mode=view&id=200025044

Perdonad por los links e imágenes salpicadas, pero es que no me aclaro cómo ponerlas como yo quiero (voy a tener que practicarlo, también)

Ya volviendo al ensamblador, Sigo en el ejemplo 6. Todavía me cuesta "pensar" en ensamblador, y para ir practicando he hecho una rutina de poner puntos, para poder probar las tablas generadas por el otro programita. Solo es un círculo, pero es la base para poder hacer rotaciones.

download/file.php?mode=view&id=200025047
download/file.php?mode=view&id=200025048

Ah, y tengo unas dudas acerca del asmtwo que me rondan la cabeza...
-Si queda una tabla de dc.w desalineada en ram, ¿hay alguna directiva para que quede en posición par? Es que depende del código que tenga anterior a la tabla, a veces tengo que poner un dc.b delante de la misma.
-¿Cuánto stack tienes en tu programa al lanzarlo desde el asmtwo? Digo porque voy a tener que empezar a usar la pila para guardar registros, etc, y sería interesante saberlo.
-Sería interesante tener un ejemplo de añadir un módulo de protracker y poder tener una rutina para pegar en el código, inicializar, playear, parar, etc

PD: Buff, todo lo que me queda para ponerme al día......

Ahora mismo ando en el curro y no me puedo extender mucho. A ver si por la noche tengo un rato y puedo ojear con tranquilidad el codigo.

Lo primero gracias por el programa, en el amiga solia usar el propio asmone para crear las tablas. En cuanto pueda pruebo el tuyo.

Sobre alinear los datos, puedes usar el comando EVEN.
Por ejemplo :

Datos1: dc.b 3,4,8,7,5
EVEN
Datos2: dc.b 5,8

Hemos declarado 5 bytes en Datos1, para que Datos2 no quede en impar, usamos el EVEN.

En tu codigo, vi que has declarado un byte a 0. No se si hacia falta, porque en ese hunk solo esta la copperlist y la imagen de fondo y es dificil que la tabla caiga en impar.

Otra cosa, las tablas las tienes en memoria chip. Podrías pasarlas a memoria fast y asi gastas menos.
En este caso tendrias que poner un EVEN despues de "gfxlib" para que no te caiga en impar y meter ahi las tablas.
O meter las tablas antes y dejar gfxlib al final del hunk.

Sobre el tema del stack, eso lo gestiona el AmigaOS durante el arranque (por defecto tienes 4k en A7). Yo personalmente no uso apenas la pila mas alla de guardar algun registro para no perderlo . Y siempre que he intentado toquetear el tamaño/dirección acabo con cuelgues y problemas.
Por eso directamente paso de usarla.

Sobre el tema de los mod, te puedo preparar un post sobre el P61 si quieres, pero lo suyo es ver primero como funciona paula y despues usar esa libreria para ahorrarnos trabajo. Usarla sin saber como funciona es un poco dar palos de ciego.

Entiendo que cuando empiezas a ver bitmaps en pantalla te den ganas de correr , pero yo te recomiendo primero hacer cosas con el copper y familiarizarte con el DMA, cuando lo tengas dominado empezar con los bitplanes y el audio.

De todos modos por aqui estamos si estás "impaciente" jejeje...
Lo dicho, esta noche le echo un ojo mas a fondo a tu codigo y comentamos la jugada.

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 » 12 Sep 2021 04:30

Vaya pensé que tenia el ejecutable incluido. Es que no uso Blitz :(
A ver si me lio la manta a la cabeza y le meto mano.


Así por encima viendo el codigo, yo haria un poco de limpieza.
Si vas a "plotear" a un 1bpl ponte un playfield a medida. Monta un buffer sencillo con DCB.x y practica ahí.

Intenta tambien ordenar el programa con arreglo a la señal del CRT, no al reves.

Antes de hacer nada, ubicate en el monitor, como se mueve y piensa como vas a constuir el frame.
A partir de ahi, elige una linea donde empezar a trabajar y que te permita mantenerte detras del rayo. No esperes al VBlank a mitad del trabajo como haces entre el borrado y pintado del punto.

Si vas a empezar en el VB, usa ese momento para hacer todo y cuando el rayo pase ya está pintado.

A ver si encuentro alguna forma de explicarme mejor, porque escribiendo soy incapaz. -banghead
Buscaré algun tipo animaciones o algo así.

Avatar de Usuario
mgyv
Mensajes: 179
Registrado: 10 May 2021 21:49
Ubicación: Vigo
Agradecido : 157 veces
Agradecimiento recibido: 107 veces

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

Mensajepor mgyv » 12 Sep 2021 13:59

Este es el ejecutable del Genseno:
GenSeno.zip
(24.35 KiB) Descargado 60 veces

Hmmm. Al o mejor no estoy entendiendo qué hace exactamente el WaitVB. Tengo claro que si lo pones en cualquier parte del loop, va a haber una espera de 20ms cada vez.
Lo que no tengo completamente claro es:
Justo después del WaitVB, ¿el rayo está empezando a volver desde el último pixel de la pantalla (y mientras tanto no está pintando nada), o es justo cuando está posicionado justo antes del primer pixel de la pantalla (y es cuándo empieza "la carrera contra el rayo")?
Por lo que entiendo, parece ser la primera opción...
-coam1 A2000 [TF534+6mb ZII+opalvision], A500 [ide68k+9.5mb], CD32 [TF330], PiStorm, -sp3zy +2A

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 » 12 Sep 2021 19:10

mgyv escribió:Este es el ejecutable del Genseno:
GenSeno.zip
Hmmm. Al o mejor no estoy entendiendo qué hace exactamente el WaitVB. Tengo claro que si lo pones en cualquier parte del loop, va a haber una espera de 20ms cada vez.
Lo que no tengo completamente claro es:
Justo después del WaitVB, ¿el rayo está empezando a volver desde el último pixel de la pantalla (y mientras tanto no está pintando nada), o es justo cuando está posicionado justo antes del primer pixel de la pantalla (y es cuándo empieza "la carrera contra el rayo")?
Por lo que entiendo, parece ser la primera opción...


La razon por la que te recomendaba a hacer cosas con el copper antes de meterte en esto era precisamente para que veas como funciona el raster. Sin eso es dificil seguir, el amiga esta contruido sobre la señal de video.

Aun asi vamos a ver si con esto me puedo explicar mejor.

Imagen
En el monitor tenemos una imagen, un frame de nuestro ejemplo. Pero sabemos que el raster hace mas cosas, por lo que es mas "grande" de la pantalla visible.
Con la imagen del rastertime vemos mas margen izdo porque se incluye el tiempo de todos los DMA, el DDF completo, etc....
Tambien ganamos el overscan superior y el inferior.
Tambien tenemos que sumar el vblank propiamente dicho (que no aparece en el bitmap pero lo podemos imaginar)
Abajo del todo hay un puñado de colores, ese es el momento en el que se esta ejecutando nuesto loop.

Si hemos pillado la idea, sabemos que el frame 0 (por ejemplo) está en pantalla, se ha ejecuta el loop al final y para la proxima recibiremos el frame 1, loop preparará el frame 2 y asi....





¿Que hace la rutina waitVB?


Imagen

Lo que hace EXACTAMENTE es bloquear la CPU hasta que el raster llegue a la linea $12f.
Toma la posicion vertical de VPOSR y VHPOSR (todo esto es basico de las primeras lecciones) y las compara con $12f00. al llegar sale del bloqueo.
Asi haciamos las rasterbar en la primera leccion, por ejemplo.

¿Por que la llamo waitVB si no es exactamen el VBLANK?

Porque desde $12f para abajo no se va a ver y me da igual. De esta forma gano unas lineas MÁS el tiempo del VBLANK.



¿Se puede poner el loop donde te de la gana?
Veamos.....

Vamos a cambiar la rutina waitVB para que busque la parte visible de arriba, en este caso $1c.


Imagen
Parece que todo es igual, pero la situacion es distinta.
Ya no estamos viendo el frame 0 sino el frame 1, asi que hemos perdido aquellas lineas extras + el VBLANK. Y ahora nos toca correr contra el rayo.
Gracias a dios ya sabiamos que nuestra rutina ocupa 16 lineas y habia un margen.
Pero acabamos de llegar por los pelos.



¿Que pasa si colocamos la espera del loop donde nos de la gana?


Imagen

Pues que te vas a pelear con el rayo para poder colocar el frame.
Fijate lo que le pasa al bob oscuro al llegar a la "frontera", los sprites claros van a su aire, pero estamos pisando lo fregado.

Imagen

Siempre tienes que mantenerte detras del rayo o delante de él (segun quieras el frame 0 el frame 1) pero no puedes dejar que el micro trabaje a su aire (por ahora).



Esa es la idea que tienes que tener por ahora, ya tendras tiempo de poner interrupciones y liarte la manta a la cabeza. -grin

Avatar de Usuario
mgyv
Mensajes: 179
Registrado: 10 May 2021 21:49
Ubicación: Vigo
Agradecido : 157 veces
Agradecimiento recibido: 107 veces

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

Mensajepor mgyv » 12 Sep 2021 20:30

Muchas gracias. Te lo has currado y se entiende perfectamente:
El waitVB lo puedes colocar dónde quieras, y tiene que coincidir de forma óptima justo cuando se acabe de pintar la parte visible del frame, e intentar adelantar y calcular todo lo que puedas desde ese momento.

Mlake escribió:La razon por la que te recomendaba a hacer cosas con el copper antes de meterte en esto era precisamente para que veas como funciona el raster.......


Tienes razón, tengo que aprender a andar antes de correr...
-coam1 A2000 [TF534+6mb ZII+opalvision], A500 [ide68k+9.5mb], CD32 [TF330], PiStorm, -sp3zy +2A

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 » 12 Sep 2021 23:13

mgyv escribió:Muchas gracias. Te lo has currado y se entiende perfectamente:
El waitVB lo puedes colocar dónde quieras, y tiene que coincidir de forma óptima justo cuando se acabe de pintar la parte visible del frame, e intentar adelantar y calcular todo lo que puedas desde ese momento.

Creo que el problema viene por el propio nombre de la rutina "waitVB".
Si lo hubieramos llamado "WaitRASTER", a lo mejor hubiera sido mas sencillo de explicar.
El VBlank simplemente es una zona mas del rastertime. Es jugosa porque como no hay que pintar, hay mas hueco a memoria.

Simplemente hay que sincronizar las iteraciones de tu "loop" con el refresco del monitor.

Esto normalmente lo aprendes al mover la rasterbar del principio del hilo.
Al cambiar el eje Y sin sincronizar el loop, ves solo funciona en una direccion.

Avatar de Usuario
mgyv
Mensajes: 179
Registrado: 10 May 2021 21:49
Ubicación: Vigo
Agradecido : 157 veces
Agradecimiento recibido: 107 veces

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

Mensajepor mgyv » 13 Sep 2021 11:29

Mlake escribió:CAP 3B Playfield Segunda parte.
........
Ahora toca rizar el rizo para comprobar que todo esta entendido:

Imagen

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.
...


Estoy en el ejercicio 8, con los "interleaved" bitmaps. He conseguido mostrar correctamente la luna2.raw, que tiene 2 bitmaps entrelazados. :-D
Luego, pones como reto una imagen con 3 bitplanes entrelazados, a la vez con diferente ancho que la pantalla (ver quote arriba)
El problema es que no tengo ninguna imagen entrelazada ("interleaved") con 3 bitplanes.
He probado con el personal paint y en raw, me lo guarda con un bitplane en bloque a continuación de otro.
Tenía a mano también el DPaintIV, pero veo que no guarda en raw (o por lo menos no veo la opción)
¿qué herramienta se puede utilizar para guardar la imagen en raw con los bitplanes "interleaved"?, o en su defecto, un conversor...
-coam1 A2000 [TF534+6mb ZII+opalvision], A500 [ide68k+9.5mb], CD32 [TF330], PiStorm, -sp3zy +2A

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 Sep 2021 14:47

mgyv escribió:
Mlake escribió:Estoy en el ejercicio 8, con los "interleaved" bitmaps. He conseguido mostrar correctamente la luna2.raw, que tiene 2 bitmaps entrelazados. :-D
Luego, pones como reto una imagen con 3 bitplanes entrelazados, a la vez con diferente ancho que la pantalla (ver quote arriba)
El problema es que no tengo ninguna imagen entrelazada ("interleaved") con 3 bitplanes.
He probado con el personal paint y en raw, me lo guarda con un bitplane en bloque a continuación de otro.
Tenía a mano también el DPaintIV, pero veo que no guarda en raw (o por lo menos no veo la opción)
¿qué herramienta se puede utilizar para guardar la imagen en raw con los bitplanes "interleaved"?, o en su defecto, un conversor...


Yo uso IFF converter

http://janeway.exotica.org.uk/release.php?id=19257

https://www.youtube.com/watch?v=MxaNoIn_njQ

Avatar de Usuario
mgyv
Mensajes: 179
Registrado: 10 May 2021 21:49
Ubicación: Vigo
Agradecido : 157 veces
Agradecimiento recibido: 107 veces

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

Mensajepor mgyv » 14 Sep 2021 00:20

Ya lo he hecho! (¿habré hecho trampa?) -grin
Ej08_laced.zip
(6.68 KiB) Descargado 44 veces
Imagen

Hay un par de cosas que no acabo de entender bien:
-La imagen la preparé en el DPaintIV, con resolución de 448x256, 3 bitplanes, intentando dejarlo como en el ejercicio.
Si la imagen es de 320, el bplxmod sería 8+40+8+40+8=104 en teoría...sin embargo le tengo que poner 128 para que "enganche las líneas"
correctamente.
En cuanto a la separación entre bitplanes, en el inicio, rutina .l, lo lógico sería apuntar cada bitplane 48 bytes más adelante, pero solo me llega a
funcionar si lo aumento a 56
-Nunca había visto el opcode dbf, pero ya lo he buscado: es como un dbra...
Adjuntos
Ej08_laced.gif
(22.16 KiB) No descargado aún
-coam1 A2000 [TF534+6mb ZII+opalvision], A500 [ide68k+9.5mb], CD32 [TF330], PiStorm, -sp3zy +2A

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 » 14 Sep 2021 03:40

mgyv escribió:Ya lo he hecho! (¿habré hecho trampa?) -grin
Ej08_laced.zipImagen

Hay un par de cosas que no acabo de entender bien:
-La imagen la preparé en el DPaintIV, con resolución de 448x256, 3 bitplanes, intentando dejarlo como en el ejercicio.
Si la imagen es de 320, el bplxmod sería 8+40+8+40+8=104 en teoría...sin embargo le tengo que poner 128 para que "enganche las líneas"
correctamente.
En cuanto a la separación entre bitplanes, en el inicio, rutina .l, lo lógico sería apuntar cada bitplane 48 bytes más adelante, pero solo me llega a
funcionar si lo aumento a 56
-Nunca había visto el opcode dbf, pero ya lo he buscado: es como un dbra...


El problema era una errata en el dibujo.
128 pixels son 16 bytes, no 8. Seguramente estaria pensando en words o directamente se me fue la pinza. :oops:

Ya está corregido. ¡Gracias! -drinks

Ahora te cuadrarán las cosas. El ancho real son 56.
Al calcular el modulo, 16+40+16+40+16=128
Y tambien la separacion de los bitplanes son 56. No 48.

Si los pusiste al tun-tun, ya tienes la explicacion. Si no, es que ya le vas pillando el truco. -thumbup


El dbf y dbra son lo mismo.

move #numero de iteraciones-1,Dx

loquesea:

x
x
x
x


dbf Dx,loquesea

En nuestro caso son 3 porque son 3 bitplanes.
Esa es la razon de BPLCON0 sea $3200. 3 bitplanes ($3000) + la compatibilidad A1000 ($200)





Si ya pillas esto, tienes mucho adelantado.

Imagen

Solo son un par de lineas en la copperlist.
Adjuntos
Ejemplo8B.7z
(3.52 KiB) Descargado 38 veces

Avatar de Usuario
mgyv
Mensajes: 179
Registrado: 10 May 2021 21:49
Ubicación: Vigo
Agradecido : 157 veces
Agradecimiento recibido: 107 veces

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

Mensajepor mgyv » 15 Sep 2021 15:24

Ya lo voy pillando.

He probado a saltar hacia atrás 2 líneas, para que quede más estrecho y parezca más un espejo. Además, cambio la paleta más azulada y oscura.
Al hacerlo así, me sale "basura" de la parte de la memoria anterior a los bitplanes, al final de la imagen, pero la he ocultado cambiando la paleta de nuevo después de hacer el reflejo...¿hay otra forma de hacerlo más "limpiamente"?
Con respecto a la paleta, ¿Se pueden llegar a cambiar 32 colores entre línea y línea?, y eso me lleva a otra pregunta...¿cuánto sobra de acceso a memoria para el procesador (o cuántos slots libres de acceso a memoria) desde que se pinta el último pixel de una línea hasta que los DMA de Audio, sprites, etc de la línea siguiente empiezan a ocupar los slots de DMA? (en resumen, ¿cuánto dura un "horizontal blank"?
Adjuntos
ej08_espejo.png
ej08_espejo.png (7.13 KiB) Visto 2216 veces
Ej08_Espejo.zip
(5.98 KiB) Descargado 56 veces
-coam1 A2000 [TF534+6mb ZII+opalvision], A500 [ide68k+9.5mb], CD32 [TF330], PiStorm, -sp3zy +2A

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 » 15 Sep 2021 16:13

mgyv escribió:Ya lo voy pillando.

He probado a saltar hacia atrás 2 líneas, para que quede más estrecho y parezca más un espejo. Además, cambio la paleta más azulada y oscura.
Al hacerlo así, me sale "basura" de la parte de la memoria anterior a los bitplanes, al final de la imagen, pero la he ocultado cambiando la paleta de nuevo después de hacer el reflejo...¿hay otra forma de hacerlo más "limpiamente"?
Con respecto a la paleta, ¿Se pueden llegar a cambiar 32 colores entre línea y línea?, y eso me lleva a otra pregunta...¿cuánto sobra de acceso a memoria para el procesador (o cuántos slots libres de acceso a memoria) desde que se pinta el último pixel de una línea hasta que los DMA de Audio, sprites, etc de la línea siguiente empiezan a ocupar los slots de DMA? (en resumen, ¿cuánto dura un "horizontal blank"?


Bien hecho, cuando llegues a los scroll le puedes hacer las ondulaciones al reflejo y te queda un efectillo curioso.

Para quitar esa morralla puedes hacer una parada de copper justo al terminar el logo y apagar los bitplanes poniendo BPLCON0 a $0000.

Tambien puedes cambiar el DIWSTOP hasta donde llegue el reflejo del logo y te ahorras la parada de copper.

Si por lo que sea quieres seguir usando la pantalla porque quieres poner unos créditos (por ejemplo). En lugar de apagar los bitplanes, le das unos punteros nuevos (BPLxPTH/L) para que pinte otro buffer.

Hay unos 226 slots por linea,
el hblank va mas o menos desde DDF $DF hasta $05.
Los BPL tienen preferencia, despues el copper, luego el blitter y el último mono es la CPU.

El copper necesita 2 slots por instruccion (2 words) asi que son 8pixels en el mejor caso, 16 pixels en el peor.

Avatar de Usuario
mgyv
Mensajes: 179
Registrado: 10 May 2021 21:49
Ubicación: Vigo
Agradecido : 157 veces
Agradecimiento recibido: 107 veces

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

Mensajepor mgyv » 19 Sep 2021 09:16

Todavía no he empezado a ver los scrolls (ya empecé el curro y tengo mucho menos tiempo)
Me gustaría poder depurar paso a paso el código. El asmtwo tiene debugger, pero en cuanto deshabilitamos el OS, ya no se puede utilizar (obviamente)
¿Cómo hacéis vosotros para depurar paso a paso, ver los registros, etc?
-coam1 A2000 [TF534+6mb ZII+opalvision], A500 [ide68k+9.5mb], CD32 [TF330], PiStorm, -sp3zy +2A

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 » 19 Sep 2021 22:30

mgyv escribió:Todavía no he empezado a ver los scrolls (ya empecé el curro y tengo mucho menos tiempo)
Me gustaría poder depurar paso a paso el código. El asmtwo tiene debugger, pero en cuanto deshabilitamos el OS, ya no se puede utilizar (obviamente)
¿Cómo hacéis vosotros para depurar paso a paso, ver los registros, etc?


Para que funcione tiene que hacer las cosas usando el SO y eso es lento. :(
Por eso se usa mucho eso de poner colorines entre la ejecucion del codigo, para ver si las cosas van (mas o menos) como tu quieres. No es un depurado al uso pero a veces ayuda.


A malas puedes tirar de UAE

Shift+12 y listo. usa "h" para ver los comandos.

Imagen

Tiene cosas curiosas como los slots que gastas, la posicion del raster antes y despues de la instruccion....

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 Sep 2021 00:45

Cap 7b CLXCON y CLXDAT


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.

Llega la hora de colisionar.

Lo primero que hay que hacer es "filtrar" lo que queremos que dispare la colision.
Para eso tenemos CLXCON

Imagen

Imaginalo como unos interruptores ON/OFF.A la izda bit 15, a la dcha bit 0.

Por defecto, los sprites pares estan incluidos. Si no los usamos, con no leer despues la colision, va que chuta.
Ahora, si queremos usar los impares tambien, tenemos que encender el bit correspondiente.
En amiga sabemos que los sprites van en pareja siendo el par el "dominante" (ver lecciones anteriores).

En nuestro caso somos un BOB que trata de huir de los sprites zombis.

Como queremos que todos "muerdan", activamos los 4 bits.
Aqui viene la primera pega:

Si nuestro protagonista fuera el sprite 0 y su "arma" es el sprite 1 (por aquello de aprovechar la misma paleta compartida), la colision no sabria distinguir si el enemigo ha chocado con el prota o con la espada, ahi saltaria la bandera y despues habria que hacer a mano el calculo.
Ahora no tenemos ese problema.

Los siguientes bits son los bitplanes. De bpl6 al bpl1

Imagen
Nuestra imagen funciona a 4 colores single playfield , solo encenderiamos el interruptor bpl1 y bpl2.
En otros casos, elegid los que necesiteis,pere SIEMPRE hay que dejar encendido alguno, aunque despues no lo uses.
Si volvemos a nuestro ejemplo, nos encontramos con otra pega:
Los tiles de fondo estan pintados (COLOR01), por ahora sabemos que esto va hacer saltar la colision con los sprites.

¿Como lo arreglamos?
Lo mas facil seria desactivar el bpl1 del sistema de colisiones y a correr.
Pero para precisar el contacto, tenemos los ultimos 6 bits.Ahi podemos elegir si queremos que la colision se detecte o en 1 o en 0.

Si resumimos, nos queda:
CLXCON=1111000011000010

Sprites 6/7. OK
Sprites 4/5. OK
Sprites 2/3. OK
Sprites 0/1. OK
BPL6. NO
BPL5. NO
BPL4. NO
BPL3. NO
BPL2. OK
BPL1. OK
Valor de BPL6: 0 Sin uso
Valor de BPL5: 0 sin uso
Valor de BPL4: 0 sin uso
Valor de BPL3: 0 sin uso
Valor de BPL2: 1 Colision con el BOB
Valor de BPL1: 0 Ponemos a 0 para que no salte con el fondo

Esto lo colocamos con el copper al inicio de pantalla o al menos antes del lugar donde quieres comprobar la colision.



Una vez echadas las redes, solo hay que recoger y para eso está CLXDAT



Imagen

Misma analogia que CLXCON, aqui se van a encender todas las colisiones, cada bit es una posible situacion, sprites contra sprites, sprites contra playfieds y playfield contra playfield.
El bit 15 no se usa.

Nuestro ejemplo necesita saber la colision de TODOS LOS SPRITES contra el PF1 que es donde está nuestro BOB, asi que tendriamos que mirar los bits 1-2-3-4 para ver si hay contacto y con que pareja ha sido.

CLXDAT=00000000000xxxx0

Imagen


Si usais dual playfield con sprites, mirais del bit 5 al 8.
Las colisiones entre sprites las lees de los bits 14-13-12-11-10-9
El bit 0 se encarga de colisiones entre playfields. Si pones los bobs en un plano y el fondo en otro, se activará cuando haya contacto entre ellos.

Como siempre, os pongo mas pegas.
La colision salta cuando ya hay contacto, no se puede recular. Si te vale asi, de lujo.
Si necesitas que salte antes de pintar el frame, no te vale.

otra:
Cuando lees CLXDAT, se resetea el valor. Esto puede ser una forma de "limpiarlo" a voluntad si lo miras de forma positiva. Lo comento por si es necesario que guardes el valor en algun lado.
Adjuntos
Colision.7z
(5.25 KiB) Descargado 31 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 » 01 Oct 2021 23:21


Avatar de Usuario
mgyv
Mensajes: 179
Registrado: 10 May 2021 21:49
Ubicación: Vigo
Agradecido : 157 veces
Agradecimiento recibido: 107 veces

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

Mensajepor mgyv » 02 Oct 2021 08:56

¿Es una conversión tuya en asm? -thumbup

En cuanto al curso, estoy con los scrolls. Al estar trabajando me cuesta muchísimo más ponerme con el tutorial. A ver si puedo en unos días y traigo los "deberes" de ese tema -grin
He visto que andabais por el curso de Amigawave de Fernando Cabrera. Muchas de las cosas ya las tenía aprendidas de aquí (fue la primera parte), hubo algunas cosas que no sabía, o no me había fijado.
Ah, también he tenido curiosidad por ver quién había hecho el asmtwo...y Photon de Scoopex tiene un montón de material, ejemplos... una pasada. Eso sí, está en inglés.
-coam1 A2000 [TF534+6mb ZII+opalvision], A500 [ide68k+9.5mb], CD32 [TF330], PiStorm, -sp3zy +2A


Volver a “Software & OS Amiga”

¿Quién está conectado?

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