Primeros pasos con el FM-7

jltursan
Mensajes: 5619
Registrado: 20 Sep 2011 13:59
Ubicación: Madrid
Agradecido : 990 veces
Agradecimiento recibido: 2040 veces
Contactar:

Re: Primeros pasos con el FM-7

Mensajepor jltursan » 15 Jul 2017 18:41

Último mensaje de la página anterior:

pser1 escribió:
minter escribió:y ahora la pregunta del millón.
y en la máquina real... sería rápido o despacio?
porque lo suyo sería el aproximarse a la real.
solo a tí se te ocurre hacer benchmark de emuladores hasta sacarles los colores. -507

Yo lo tengo altamente complicado para probarlo en mi super-escondido FM-7, tal vez José Luis
podría intentar probarlo o algún otro afortunado poseedor de un ejemplar de esta especie
A ver quien se anima -thumbup
saludos
pere


En cuanto haga hueco y lo monte, fijo que intento probarlo -wink

Avatar de Usuario
minter
Mensajes: 4826
Registrado: 22 Jul 2014 18:51
Agradecido : 6762 veces
Agradecimiento recibido: 2602 veces

Re: Primeros pasos con el FM-7

Mensajepor minter » 15 Jul 2017 20:49

pser1 escribió:Buenas tardes,
Os adjunto el .D77 para probarlo y el fuente en ensamblador para quien quiera echarle una ojeada


Probado!!! -thumbup
Va rápido! jltursan, cuéntanos como va en real!!! -nb

Una pregunta de concepto:
Los sprites: Cuando empecemos a jugar con los sprites... ¿Que micro nos va a hacer la copia parcial de pantalla, la mascara y el pegado?
¿Lo puede ejecutar todo la SubCPU mediante el envío de un comando a través de la "ventana"?
¿Ya no será necesario el manejar la pantalla completa, no? ¿Solo el trozo donde tenemos el sprite?

Y otra cosa. Cachis!!!! Me acabáis de hacer SPOILER con TibuRON!!!! -507

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 15 Jul 2017 20:57

minter escribió:Una pregunta de concepto:
Los sprites: Cuando empecemos a jugar con los sprites... ¿Que micro nos va a hacer la copia parcial de pantalla, la mascara y el pegado?
¿Lo puede ejecutar todo la SubCPU mediante el envío de un comando a través de la "ventana"?
¿Ya no será necesario el manejar la pantalla completa, no? ¿Solo el trozo donde tenemos el sprite?

Hola,
espero que utilizando el esquema de colores que sugirió Malik, no necesitemos máscara alguna y se pueda mover usando solamente
una copia del sprite (1 fijo mas 2 movimientos).
En principio los movimientos de Brody han de ser comandos especiales que debe resolver el control añadido en $c000 en el SS.
Hay que probarlo, ya iré mirando como montar el bucle de control en la CPU principal y como tener las rutinas de movimiento y los
tres sprites en el SubSistema ... esperemos que quepa todo en los 4k de $c000-$cfff
saludos
pere

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 15 Jul 2017 20:58

jltursan escribió:En cuanto haga hueco y lo monte, fijo que intento probarlo -wink

Solo aquellos que tenéis disquetera para FM-7 podéis probarlo en real ... que envidia!
Ya nos irás contando
saludos
pere

jltursan
Mensajes: 5619
Registrado: 20 Sep 2011 13:59
Ubicación: Madrid
Agradecido : 990 veces
Agradecimiento recibido: 2040 veces
Contactar:

Re: Primeros pasos con el FM-7

Mensajepor jltursan » 16 Jul 2017 09:43

Solo aquellos que tenéis disquetera para FM-7 podéis probarlo en real ... que envidia!


Espera, espera, que igual tengo algo para tí...;-)

Hoy montaré la marimorena a ver si puede ver algo.

Respecto a los sprites, el uso de los planos permite hacer trucos muy interesantes, los problemas que le veo son la búsqueda de una paleta de cuatro colores para los sprites que de juego (blanco,negro y otros dos colores) y la falta de equilibrio entre el fondo y el primer plano, sobre todo usando escenarios 100% blanco y negro.

En el Xanadu la paleta de los sprites consiste en blanco, negro, rojo y gris, no funciona mal del todo. El escenario al ser azul y amarillo da algo de color al conjunto, el problema es que queda rara.

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 16 Jul 2017 16:22

jltursan escribió:
Solo aquellos que tenéis disquetera para FM-7 podéis probarlo en real ... que envidia!

Espera, espera, que igual tengo algo para tí...;-)
Hoy montaré la marimorena a ver si puede ver algo.

No me tengas en ascuas .... eso será peor que la enfermedad de no tener nada -507
Respecto a los sprites, el uso de los planos permite hacer trucos muy interesantes, los problemas que le veo son la búsqueda de una paleta de cuatro colores para los sprites que de juego (blanco,negro y otros dos colores) y la falta de equilibrio entre el fondo y el primer plano, sobre todo usando escenarios 100% blanco y negro.
En el Xanadu la paleta de los sprites consiste en blanco, negro, rojo y gris, no funciona mal del todo. El escenario al ser azul y amarillo da algo de color al conjunto, el problema es que queda rara.

La paleta que sugirió Malik, se basa en trabajar en solamente blanco y negro, sin otros colores, dejó el plano AZUL
para el fondo (0=negro, 1=Blanco) y luego emplea los otros dos planos para mostrar el blanco (1s en plano Verde)
y el negro (1s en el plano Rojo) del carácter en movimiento. Cuando los planos Verde-Rojo son ambos cero, parece
que equivale a transparente y solo se ve el fondo.
Me parece un buen principio, mas adelante ya nos pelearemos con el tema colores, pero mejor que los fondos sean a
base de 'tiles' para facilitar su creación en lugar de cargar una pantalla de 8 colores = 48K ... nueve veces de la carga actual
ya que las pantallas de Dragón ocupan 5.001 bytes.
saludos
pere

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 18 Jul 2017 11:56

minter escribió:Los sprites: Cuando empecemos a jugar con los sprites... ¿Que micro nos va a hacer la copia parcial de pantalla, la mascara y el pegado?
¿Lo puede ejecutar todo la SubCPU mediante el envío de un comando a través de la "ventana"?
¿Ya no será necesario el manejar la pantalla completa, no? ¿Solo el trozo donde tenemos el sprite?

Buenos días,
respondí muy rápido basándome en los consejos de Malik sin haber analizado como implementarlo.
Estaba todavía en la fase do convertir las posiciones de memoria de Dragón a los mismos puntos en el FM-7
En Dragón tomando el punto de memoria del rectángulo del sprite arriba izquierda y haciéndole un ANDA #$1F
nos da gratuitamente la columna en la que se encuentra (de 0 a 31) ya que cada linea cuenta con 32 bytes
NO he sido capaz de encontrar ninguna manera para hacer lo mismo usando dicho byte en la pantalla del FM-7
El problema lo crea el hecho de que cada linea tiene 80 bytes ($50) y no hay manera de encontrar una operación
que permita detectar la columna en la que está. He acabado cambiado de táctica y en lugar del punto de memoria
guardo FilaColumna (dos bytes también) y con una tabla de inicios de linea (para evitar multiplicaciones) en dos
operaciones obtengo la direccion real de memoria, que le vamos a hacer! ... Jo, vaya parrafada, sin aliento estoy -507

Para mover a Brody y no machacar el fondo, usamos una máscara y el sprite con los alrededores a cero, de forma
que tomando el FONDO en A, haciendo ANDA con la máscara y luego ADDA (ó ORA) con el sprite, obtenemos el movimiento
sin pisar nada!
En FM-7 si enviamos el sprite al plano G, los unos se muestran como BLANCO y los ceros no hacen nada
Invirtiendo los bits (COMA) y enviándolo al plano R, los bits 1 (antes 0) se muestran como NEGRO, pero ...
Los 'alrededores' que estaban a cero, también se han convertido en 1s y ahora machacarán el Fondo -banghead
Voy a preguntarle a Malik si conoce alguna forma simple de evitarlo.
Obviamente, si le paso al FM-7 dos sprites, uno para cada plano no hay problema, salvo el espacio, que se duplica -banghead
Se admiten sugerencias, ideas, cerveza, lo que sea -drinks
Saludos
pere

Avatar de Usuario
minter
Mensajes: 4826
Registrado: 22 Jul 2014 18:51
Agradecido : 6762 veces
Agradecimiento recibido: 2602 veces

Re: Primeros pasos con el FM-7

Mensajepor minter » 18 Jul 2017 14:53

pser1 escribió:
minter escribió:Se admiten sugerencias, ideas, cerveza, lo que sea -drinks
Saludos
pere

En el plano, el negro significa transparencia. ¿No?
¿Y si pintamos la silueta de Brodi donde tiene negro por gris oscuro? Y seguimos manteniendo el negro como transparencia en el plano...
¿eso es posible?
Espera.... Hmmmm.... No! creo que no se puede! No puedo tener mas que activo o no activo, el pixel por plano.
¿Y copiando un cuadrado del plano G (fondo creo) y sumandolo al dibujo de Brodi en plano R del tamaño del sprite? Es una sarnosa OR, ¿No?

Para h OR...no 's estamos nosotros. QUe calor!!! -grin

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 18 Jul 2017 16:07

minter escribió:En el plano, el negro significa transparencia. ¿No?
¿Y si pintamos la silueta de Brodi donde tiene negro por gris oscuro? Y seguimos manteniendo el negro como transparencia en el plano...
¿eso es posible?
Espera.... Hmmmm.... No! creo que no se puede! No puedo tener mas que activo o no activo, el pixel por plano.
¿Y copiando un cuadrado del plano G (fondo creo) y sumandolo al dibujo de Brodi en plano R del tamaño del sprite? Es una sarnosa OR, ¿No?
Para h OR...no 's estamos nosotros. QUe calor!!! -grin

Copio aqui la sugerencia de malikto999
----------------------------------------------------------------------------------------------------------------------------------------------------------
FM-7's VRAM has three planes, blue, red, green.
You draw the background graphic on blue plane. Then draw the characters on the remaining red and green planes.
The color of the character's pattern data is assigned to the transparent color when both red and green bits are 0,
and to black and white otherwise. To superimpose characters and backgrounds, set color palettes as follows.
B R G -> ColorCode PaletteCode
---------------------------------------
0 0 0 -> 0 black(0) background - - - - - cuando el pixel en R y G están a 0, es transparente
1 0 0 -> 1 white(7) background
0 1 0 -> 2 black(0) character - - - - - - cuando el pixel está a 1 en el plano R, se muestra negro
1 1 0 -> 3 black(0) character
0 0 1 -> 4 white(7) character - - - - - - cuando el pixel está a 1 en el plano G, se muestra blanco
1 0 1 -> 5 white(7) character
0 1 1 -> 6 white(7) character - - - - - - si por cualquier motivo el pixel en R y G están en 1, prevalece el blanco
1 1 1 -> 7 white(7) character
----------------------------------------------------------------------------------------------------------------------------------------------------------
He puesto las notas en castellano para 'aclararme' del efecto que producen las variantes en los planos R y G
Para conseguir 'transparencia', hemos de forzar los pixels a CERO en los dos panos R y G y éste es el problema
ya que al invertir bits cambian todos siempre!
saludos
pere

jltursan
Mensajes: 5619
Registrado: 20 Sep 2011 13:59
Ubicación: Madrid
Agradecido : 990 veces
Agradecimiento recibido: 2040 veces
Contactar:

Re: Primeros pasos con el FM-7

Mensajepor jltursan » 18 Jul 2017 19:22

pser1 escribió:
minter escribió:Los sprites: Cuando empecemos a jugar con los sprites... ¿Que micro nos va a hacer la copia parcial de pantalla, la mascara y el pegado?
¿Lo puede ejecutar todo la SubCPU mediante el envío de un comando a través de la "ventana"?
¿Ya no será necesario el manejar la pantalla completa, no? ¿Solo el trozo donde tenemos el sprite?

Buenos días,
respondí muy rápido basándome en los consejos de Malik sin haber analizado como implementarlo.
Estaba todavía en la fase do convertir las posiciones de memoria de Dragón a los mismos puntos en el FM-7
En Dragón tomando el punto de memoria del rectángulo del sprite arriba izquierda y haciéndole un ANDA #$1F
nos da gratuitamente la columna en la que se encuentra (de 0 a 31) ya que cada linea cuenta con 32 bytes
NO he sido capaz de encontrar ninguna manera para hacer lo mismo usando dicho byte en la pantalla del FM-7
El problema lo crea el hecho de que cada linea tiene 80 bytes ($50) y no hay manera de encontrar una operación
que permita detectar la columna en la que está. He acabado cambiado de táctica y en lugar del punto de memoria
guardo FilaColumna (dos bytes también) y con una tabla de inicios de linea (para evitar multiplicaciones) en dos
operaciones obtengo la direccion real de memoria, que le vamos a hacer! ... Jo, vaya parrafada, sin aliento estoy -507

Para mover a Brody y no machacar el fondo, usamos una máscara y el sprite con los alrededores a cero, de forma
que tomando el FONDO en A, haciendo ANDA con la máscara y luego ADDA (ó ORA) con el sprite, obtenemos el movimiento
sin pisar nada!
En FM-7 si enviamos el sprite al plano G, los unos se muestran como BLANCO y los ceros no hacen nada
Invirtiendo los bits (COMA) y enviándolo al plano R, los bits 1 (antes 0) se muestran como NEGRO, pero ...
Los 'alrededores' que estaban a cero, también se han convertido en 1s y ahora machacarán el Fondo -banghead
Voy a preguntarle a Malik si conoce alguna forma simple de evitarlo.
Obviamente, si le paso al FM-7 dos sprites, uno para cada plano no hay problema, salvo el espacio, que se duplica -banghead
Se admiten sugerencias, ideas, cerveza, lo que sea -drinks
Saludos
pere


Buf, veamos...

1) ¿Lo que buscas es la función que dadas X (0-639) e Y (0-199) te calcule el byte de comienzo en la VRAM?. No tengo muy presente la organización de la VRAM; pero si es lineal de izq. a der. y de arriba a abajo, 80 bytes por linea, ¿no sería y*80+x\8?

2) No hay que usar mascaras ni preservar el fondo, si se pinta en B el background y se usan R y G para volcar el gráfico, el plano B permanece inalterado y por tanto no hay que restaurar nada.
Olvidándonos pues de todo lo que resida en B, la operación consiste únicamente en volcar el rectángulo del sprite. Si alrededor del sprite creamos un marco de píxeles transparentes R:0,G:0 tan ancho como el desplazamiento del sprite, nos podremos permitir el lujo de no borrar en una operación dedicada, ya que el pintado borrará simultáneamente.
Esto último sólo es aplicable cuando en pantalla desplazamos un único sprite (Brody) y puede campar a sus anchas por R:G. Si tuviesemos que mover alguno más y no ver solapes muy toscos, si que habría que usar una máscara con AND y pintar con OR; pero no me queda claro si este sería el caso.
En caso de desesperación, se puede sólo pintar con XOR o incluso con OR y confiar en que no se emborronaran mucho los solapes, aunque en este caso eso lo veo muy poco viable dado el tamaño y aspecto de los sprites (muy nítidos y definidos).

Respecto a la organización de la paleta de malik, el objetivo es conseguir B/N al 100%. Realmente podríamos usar un color extra en el caracter redefiniendo los colores 4 y 5 en vez de con blanco, con algún otro color que encajara con el personaje (rojo, verde, etc.).

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 18 Jul 2017 20:04

jltursan escribió:Buf, veamos...
1) ¿Lo que buscas es la función que dadas X (0-639) e Y (0-199) te calcule el byte de comienzo en la VRAM?. No tengo muy presente la organización de la VRAM; pero si es lineal de izq. a der. y de arriba a abajo, 80 bytes por linea, ¿no sería y*80+x\8?

Esta parte ya está solucionada. Multiplicar y Dividir en ensamblador de 6809 usa demasiados ciclos, ya lo tengo solucionado así:
- recibimos en regD fila y columna (regA y regB respectivamente) pero en bytes de pantalla (0<= Y <= 48; 8 <= X <= 71)
ldx #InicioTablaPrimerByteIzquierdaPorLineaDeGrid
ldx a,x ; carga el byte de la izquierda de la linea solicitada (A se incremente de 2 en 2 para facilitar offset a tabla)
abx ; le suma columna obteniendo direccion VRAM efectiva (B se incrementa de 4 en cuatro a cada salto)
La tabla infumable solo tiene 25 entradas ya que la pantalla útil es de 156 pixels de altura, restando los 56 de altura de Brody nos quedan 100
y como Brody se mueve verticalmente de 4 en 4 pixels, las posibles posiciones son 100/4=25. Probado y funciona perfecto y rápido!
2) No hay que usar mascaras ni preservar el fondo, si se pinta en B el background y se usan R y G para volcar el gráfico, el plano B permanece inalterado y por tanto no hay que restaurar nada.
Olvidándonos pues de todo lo que resida en B, la operación consiste únicamente en volcar el rectángulo del sprite. Si alrededor del sprite creamos un marco de píxeles transparentes R:0,G:0 tan ancho como el desplazamiento del sprite, nos podremos permitir el lujo de no borrar en una operación dedicada, ya que el pintado borrará simultáneamente.
Esto último sólo es aplicable cuando en pantalla desplazamos un único sprite (Brody) y puede campar a sus anchas por R:G. Si tuviesemos que mover alguno más y no ver solapes muy toscos, si que habría que usar una máscara con AND y pintar con OR; pero no me queda claro si este sería el caso.
En caso de desesperación, se puede sólo pintar con XOR o incluso con OR y confiar en que no se emborronaran mucho los solapes, aunque en este caso eso lo veo muy poco viable dado el tamaño y aspecto de los sprites (muy nítidos y definidos).

En tu explicación estás diciendo que TANTO en el plano R como G hay que poner ceros como 'alrededores' de Brody, Es exactamente lo que yo estoy diciendo que NO puedo hacer sin duplicar el número de bytes usados. Necesitaría un sprite para cada plano y cada uno es de 8x56=448
bytes, así que para los dos planos nos vamos a 896 bytes por sprite y necesitamos TRES para hacer el movimiento, o sea 2688 bytes en total,
cosa que pueda que quepa de $c000 hasta $cfff pero vamos a pillarnos los dedos para meter el código de presentación/movimiento del sprite.
Probablemente me he perdido alguna parte de tu explicación, así que si tu ves alguna posibilidad de trabajar con UN solo sprite para ambos
planos, dame alguna pista mas, por favor ... gracias!
Respecto a la organización de la paleta de malik, el objetivo es conseguir B/N al 100%. Realmente podríamos usar un color extra en el caracter redefiniendo los colores 4 y 5 en vez de con blanco, con algún otro color que encajara con el personaje (rojo, verde, etc.).

Cierto, trataré de hacer experimentos en cuanto Brody se mueva en pantalla.
Muchas gracias
pere

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 18 Jul 2017 20:27

Me da la impresión de que trabajando en 'colores', nos veremos obligados a definir los sprites multi-plano.
Así que parece natural que para mover a Brody que tiene áreas blancas y otras negras sea necesario disponer de un
sprite que abarque los dos planos (R-G) así que dudo que podamos evitar el 'uso' de 8x56x2=896 bytes para cada imagen -banghead
De todas formas, cualquier idea al respecto será bien recibida -nb
saludos
pere

Avatar de Usuario
minter
Mensajes: 4826
Registrado: 22 Jul 2014 18:51
Agradecido : 6762 veces
Agradecimiento recibido: 2602 veces

Re: Primeros pasos con el FM-7

Mensajepor minter » 18 Jul 2017 21:51

Buenas Pere,

¿No puedes ponernos una captura de pantalla de lo que ocurre?
Es que o no lo entiendo, o no lo veo, o me falla algo de concepto.

Off Topic
-Estoy mirando para la pared, donde hay un calendario del 2017, con la mano apoyada en la nariz y con la vista perdida. Y me acaba de decir mi señora...
¿Te pasa algo?
-Noooo... estoy pensandoooo.
¿Pero pensando en qué? ¿Estas bien? ¿Estás preocupado?
-Nooo... estoy pensando en cosas del foro del kiwikiwi.

Anda! Pensaba que te pasaba algo y estás con tus cosas.... Venga! A cenar!!! -507


Yo sigo pensando en traer el trozo del fondo al plano del sprite trabajando directamente sobre el plano, no en otra parte de la memoria.

Ya se que debería saberlo a estas alturas e igual ya fue comentado, pero... ¿existen prioridades de pantalla o se pueden activar sin hacer mezclas?

jltursan
Mensajes: 5619
Registrado: 20 Sep 2011 13:59
Ubicación: Madrid
Agradecido : 990 veces
Agradecimiento recibido: 2040 veces
Contactar:

Re: Primeros pasos con el FM-7

Mensajepor jltursan » 18 Jul 2017 22:11

En tu explicación estás diciendo que TANTO en el plano R como G hay que poner ceros como 'alrededores' de Brody, Es exactamente lo que yo estoy diciendo que NO puedo hacer sin duplicar el número de bytes usados. Necesitaría un sprite para cada plano y cada uno es de 8x56=448
bytes, así que para los dos planos nos vamos a 896 bytes por sprite y necesitamos TRES para hacer el movimiento, o sea 2688 bytes en total,


Claro, ya te pillo, es que la propuesta de malik era la de emplear dos planos integramente para los sprites, por lo tanto, emplear lo que tu llamas dos SPRITES (R:G) es imprescindible y por tanto plantearse el duplicado del tamaño sería obligado como ya has visto. La ventaja es simplemente que podrías ganar un color extra, las desventajas, el mayor trabajo y el doble de tamaño en bytes.

Ahora bien, démosle la vuelta, utiliza R:G para el background y sólo B para los sprites. Pasarías a tener cuatro colores en el decorado (que bien escogidos y con algo de tramado pueden dar mucho juego) y dos (blanco y negro) para el personaje. Vuelves a tener velocidad, tamaño reducido y un decorado más vistoso.

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 18 Jul 2017 22:14

minter escribió:Buenas Pere,
¿No puedes ponernos una captura de pantalla de lo que ocurre?
Es que o no lo entiendo, o no lo veo, o me falla algo de concepto.
Off Topic
-Estoy mirando para la pared, donde hay un calendario del 2017, con la mano apoyada en la nariz y con la vista perdida. Y me acaba de decir mi señora...
¿Te pasa algo?
-Noooo... estoy pensandoooo.
¿Pero pensando en qué? ¿Estas bien? ¿Estás preocupado?
-Nooo... estoy pensando en cosas del foro del kiwikiwi.
Anda! Pensaba que te pasaba algo y estás con tus cosas.... Venga! A cenar!!! -507

Yo sigo pensando en traer el trozo del fondo al plano del sprite trabajando directamente sobre el plano, no en otra parte de la memoria.
Ya se que debería saberlo a estas alturas e igual ya fue comentado, pero... ¿existen prioridades de pantalla o se pueden activar sin hacer mezclas?

Hola,
me sabe mal decir que NO tengo nada que mostrar puesto que todavía no está decidido el tamaño del sprite de Brody.
Todo lo que cuento es pura 'tormenta de ideas' o sea cosas que me atormentan -507
En algún momento he pensado en utilizar un único plano ya que trabajamos en blanco y negro, y emplear ahí el mismo método
que con Dragón, pero ésto sigue implicando tener dos áreas de 8x56 (máscara y sprite) para cada imagen, o sea 2x8x56= 896 que
es lo mismo que usando el truco de Malik, que posiblemente facilite mucho el trabajo de presentar datos ya que NO requerirá
usar máscara y sprite sinó un sprite 'fijo' para cada plano, por lo que bastará con hacer LDD y STD sin preocuparse de las operaciones
antes obligatorias ANDA máscara y luego ORA sprite, ganando velocidad de trabajo.
Esperaré hasta mañana por la tarde por si hay alguna idea de Malik o de otros colegas.
Entonces empezaré a hacer un programa de conversión de máscara + sprite de Dragón a sprite plano R y sprite plano G para FM-7
cosa que espero que no sea demasiado complicada ...
saludos
pere

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 18 Jul 2017 22:37

jltursan escribió:
En tu explicación estás diciendo que TANTO en el plano R como G hay que poner ceros como 'alrededores' de Brody, Es exactamente lo que yo estoy diciendo que NO puedo hacer sin duplicar el número de bytes usados. Necesitaría un sprite para cada plano y cada uno es de 8x56=448
bytes, así que para los dos planos nos vamos a 896 bytes por sprite y necesitamos TRES para hacer el movimiento, o sea 2688 bytes en total,

Claro, ya te pillo, es que la propuesta de malik era la de emplear dos planos integramente para los sprites, por lo tanto, emplear lo que tu llamas dos SPRITES (R:G) es imprescindible y por tanto plantearse el duplicado del tamaño sería obligado como ya has visto. La ventaja es simplemente que podrías ganar un color extra, las desventajas, el mayor trabajo y el doble de tamaño en bytes.
Ahora bien, démosle la vuelta, utiliza R:G para el background y sólo B para los sprites. Pasarías a tener cuatro colores en el decorado (que bien escogidos y con algo de tramado pueden dar mucho juego) y dos (blanco y negro) para el personaje. Vuelves a tener velocidad, tamaño reducido y un decorado más vistoso.

La verdad es que no se me había ocurrido lo de invertir fondo y primer plano ...
Me preocupa que si lo hicéramos entonces la carga de pantallas necesitaría mas tiempo del SS ya que cada byte de pantalla de Dragón
habría que enviarlo al plano R y luego invertido (COMA) al plano G.
Además de esta forma nunca R-G serán ceros a la vez, por lo que siempre predominarían sobre lo que haya en el plano B que sería Brody
(no habría transparencias), aunque puede que usando B-R para el fondo (B=negro, R=blanco), se podría usar G para el sprite, veamos las formulitas de Malik adaptadas
B R G -> ColorCode PaletteCode
---------------------------------------
0 0 0 -> 0 negro (0) fondo. No debería pasar nunca
1 0 0 -> 1 negro (0) fondo
0 1 0 -> 2 blanco (7) fondo
1 1 0 -> 3 blanco (7) fondo. No debería pasar nunca
Los pixels siempre estarán a UNO en un plano y a CERO en el otro, por lo que los valores 00 y 11 no existirán en la práctica
Pero ahora NO hay manera de forzar con el plano G DOS colores ya que el valor cero el G hace que B-R decidan color!
0 0 1 -> 4 blanco (7) caracter. No debería pasar nunca
1 0 1 -> 5 blanco (7) caracter --- el mismo valor no puede crear dos colores diferentes o sería una mancha!
0 1 1 -> 6 negro (7) caracter --- el mismo valor no puede crear dos colores diferentes o sería una mancha!
1 1 1 -> 7 negro (7) caracter. No debería pasar nunca
No veo por donde agarrarlo -banghead
si se te ocurre algo ... lo estudiamos, sinó tiraré por el sistema de sprite doble, que me parece que simplifica mucho las
rutinas de movimiento, además aquí se mueve doble espacio (640 pixels contra 320) así que a cada paso se mueve UN byte
y por tanto los sprites no requieren el desplazamiento de 4 bits que requerían en Dragón, que era un palo!
saludos
pere

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 19 Jul 2017 17:33

@minter, jltursan
Ya tenemos una alternativa, propuesta por malik en el hilo en inglés, que es muy interesante pues reaprovecha la información de
Dragón sin mas cambios que el hecho de duplicar los pixels por el paso de 320 a 640
saludos
pere


Volver a “Fujitsu FM7”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado