Primeros pasos con el FM-7

Avatar de Usuario
pser1
Mensajes: 2213
Registrado: 08 Dic 2012 18:34
Agradecido : 296 veces
Agradecimiento recibido: 310 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 19 Jul 2017 17:33

Último mensaje de la página anterior:

@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

Avatar de Usuario
minter
Mensajes: 1806
Registrado: 22 Jul 2014 18:51
Agradecido : 1170 veces
Agradecimiento recibido: 494 veces

Re: Primeros pasos con el FM-7

Mensajepor minter » 19 Jul 2017 18:32

pser1 escribió:Dragón sin mas cambios que el hecho de duplicar los pixels por el paso de 320 a 640

Osea... ¿que ya no se mueven 4 bits sino un byte?
En los juegos publicados para FM-7 no he visto movimientos de sprite suficientemente fluidos.
No vayas a hora a llevarles la contraria... -drinks

Avatar de Usuario
pser1
Mensajes: 2213
Registrado: 08 Dic 2012 18:34
Agradecido : 296 veces
Agradecimiento recibido: 310 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 19 Jul 2017 18:55

minter escribió:
pser1 escribió:Dragón sin mas cambios que el hecho de duplicar los pixels por el paso de 320 a 640

Osea... ¿que ya no se mueven 4 bits sino un byte?

Efectivamente, Brody se mueve 4 pixels en Dragón, pero al doblar anchura se convierte en 8 pixels = 1 byte, lo cual
permite (y lo necesitábamos) reducir el número de sprites a 3. Imágenes: Quieto y dos de movimiento, para hacer 2-1-3-1 y acabar
en posición estática (1) siendo 2 y 3 los fotogramas de movimiento.
Nos ahorramos los decalados 4 pixels si los de movimiento vertical también 'cuelan' para el horizontal, cosa que debería funcionar!
En los juegos publicados para FM-7 no he visto movimientos de sprite suficientemente fluidos.
No vayas a hora a llevarles la contraria... -drinks

No he probado ni un solo juego de FM-7 ni en el emulador XM7. ¿Qué quieres decir con suficientemente fluidos?
¿Te dan la impresión de ir a saltos?
saludos
pere

jltursan
Mensajes: 2197
Registrado: 20 Sep 2011 13:59
Agradecido : 101 veces
Agradecimiento recibido: 270 veces

Re: Primeros pasos con el FM-7

Mensajepor jltursan » 19 Jul 2017 20:22

Minter tiene razón, los juegos japoneses por regla general mueven las cosas de 8 en 8 (o 16 en 16) píxeles, o bien debido a la gran cantidad de datos bitmap a mover, o bien a que la máquina está plenamente orientada al uso de un generador de caracteres programable. Un ejemplo perfecto es uno de los videos que colgamos con el juego "Gangman" :-)

Para ilustrar un poco el tema de los planos y los "sprites", he programado un ejemplo en BASIC:

Código: Seleccionar todo

10 DEFINT A-Z:DIM A(200):DIM C(3)
20 SCREEN 7,7:COLOR 7,0:CLS:C(0)=0:C(1)=2:C(2)=4:C(3)=6
30 COLOR=(1,7):COLOR=(3,7):COLOR=(5,7)
40 LINE@ (0,0)-(31,15),PSET,1,BF
50 LINE@ (4,2)-(27,13),PSET,0,BF
60 GET@A (0,0)-(31,15),A,G
70 FOR Y=0 TO 64 STEP 16
80 FOR X=0 TO 640 STEP 32
90 LINE@ (X,Y)-(X+31,Y+15),PSET,C(INT(RND(1)*4)),BF
100 NEXT X
110 NEXT Y
120 REM MUEVE EL "SPRITE"
130 SCREEN 1,7
140 FOR X=0 TO 608 STEP 2
150 PUT@A (X,32)-(X+31,47),A,PSET
160 LINE@ (X-2,32)-(X-1,47),PSET,0,BF
170 NEXT X
180 SCREEN 7,7:LOCATE 0,16:END


Reservo R:G para el background (con sus 4 colores: negro, rojo, verde y amarillo, tal cual sin redefinir) y me quedo con el B para mover mi sprite, el cual es blanco siempre gracias a unas cuantas redefiniciones de paleta.
Gracias a que el B es un plano independiente de R:G, no me tengo que preocupar nunca en preservar fondos y esas zarandajas, me limito a operar sobre B sin acordarme de que existan los otros planos.

El problema es evidente, sólo dispongo de un color (sprites monocromos); pero en nuestro caso son bicolores reales (blanco y negro) por lo que no creo que quedasen muy bien.
Partiendo de este BASIC se puede probar a dibujar un background en algún plano, da igual cual, y dibujar un sprite en los otros dos a ver que tal.

Avatar de Usuario
Chema
Mensajes: 1855
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 931 veces
Agradecimiento recibido: 326 veces
Contactar:

Re: Primeros pasos con el FM-7

Mensajepor Chema » 19 Jul 2017 22:17

Ummm... no sé si lo entiendo, pero aunque sea por intentar ayudar...

Es normal que, para optimizar, los movimientos y las posiciones de los sprites estén alineadas a byte (normalmente 8 pixels). Eso no quiere decir que no se puedan realizar movimientos más "suaves". Basta con que los fotogramas intermedios tengan el desplazamiento que buscas.

Yo uso un desplazamiento para los pasos (los fotogramas 2 y 3 que dice pser1) de medio carácter, de forma que en la secuencia 1-2-1 se avance un carácter completo (se avanza su coordenada un carácter antes de pintar el segundo fotograma 1), pero más suavemente. Se pueden usar más fotogramas intermedios, claro, si se dispone de memoria.

Los sprites necesitan algo más de espacio en memoria, pero es asumible, en mi opinión. Quiero decir que un personaje de 4 caracteres de ancho necesita un byte extra (5) para los pasos intermedios.

A ver si una imagen vale más que mil palabras, aunque recordad que en el Oric un carácter tiene 6 píxeles en pantalla, así que los pasos intermedios son de 3 píxeles (en lugar de 8 y 4):
02-step2.png
Fotograma 1
02-step2.png (30.5 KiB) Visto 272 veces

01-step1.png
Fotograma 2
01-step1.png (31.54 KiB) Visto 272 veces

03-step3.png
Fotograma 3
03-step3.png (31.11 KiB) Visto 272 veces


Lo mismo se puede hacer para caminar arriba y abajo.

¿Es eso de lo que habláis o me he despistado mucho?

Avatar de Usuario
pser1
Mensajes: 2213
Registrado: 08 Dic 2012 18:34
Agradecido : 296 veces
Agradecimiento recibido: 310 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 19 Jul 2017 22:24

Hola,
a ver cuando puedo mirármelo con atención. Es muy interesante!
De momento ya tengo creado un programa en Dragon (ensamblador), que tomando los tres sprites
compuestos de máscara y sprite los duplica en anchura y además invierte la máscara como malik
sugiere en su mensaje.
Así que ya tengo los bytes para mostrar los tres fotogramas de Brody ...
Espero poder añadir mañana en el programa SHARK04 el código necesario para llamar a cuatro nuevos comandos
de usuario que moverán en las cuatro direcciones. Básicamente forzado por el hecho de que limpiar la columna/fila
que deja de estar ocupada por Brody implica distinto código.
La presentación, pensaba en tener una única rutina que lea el super sprite (16 bytes) y lo vaya enviando a los
dos planos a la vez desde el SubSistema
Quería hacer que la CPU principal controle el 'timing' enviando la orden para cada fotograma en las cuatro direcciones
así veremos si hacen falta 'retardos' o necesitamos 'petardos' para darle mas marcha -507
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2213
Registrado: 08 Dic 2012 18:34
Agradecido : 296 veces
Agradecimiento recibido: 310 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 19 Jul 2017 22:32

Chema escribió:Ummm... no sé si lo entiendo, pero aunque sea por intentar ayudar...
Es normal que, para optimizar, los movimientos y las posiciones de los sprites estén alineadas a byte (normalmente 8 pixels). Eso no quiere decir que no se puedan realizar movimientos más "suaves". Basta con que los fotogramas intermedios tengan el desplazamiento que buscas.
Yo uso un desplazamiento para los pasos (los fotogramas 2 y 3 que dice pser1) de medio carácter, de forma que en la secuencia 1-2-1 se avance un carácter completo (se avanza su coordenada un carácter antes de pintar el segundo fotograma 1), pero más suavemente. Se pueden usar más fotogramas intermedios, claro, si se dispone de memoria.
Los sprites necesitan algo más de espacio en memoria, pero es asumible, en mi opinión. Quiero decir que un personaje de 4 caracteres de ancho necesita un byte extra (5) para los pasos intermedios.
A ver si una imagen vale más que mil palabras, aunque recordad que en el Oric un carácter tiene 6 píxeles en pantalla, así que los pasos intermedios son de 3 píxeles (en lugar de 8 y 4):
Lo mismo se puede hacer para caminar arriba y abajo.
¿Es eso de lo que habláis o me he despistado mucho?

Hola Chema!
en la versión de Dragón estoy haciendo exactamente lo que cuentas, los fotogramas de movimiento solo avanzan medio byte así
que 'ocupan' cinco bytes en lugar de cuatro y funciona bastante bien.
En el FM-7 la definición es de 640x200 en lugar de 256x192, así que tanto el fondo como los fotogramas pasan a ocupar el doble de ancho!
Para mantener el mismo movimiento que en Dragón, ahora en el FM-7 cada paso será de un byte (2x4 pixels) facilitando la vida a la hora
de programar las rutinas que podría pasar a ser únicamente una, ya iré viendo sobre la marcha.
Hasta que no lo pruebe no podré ver si el movimiento es a saltos (jerky) o si es igual al de Dragón ...
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2213
Registrado: 08 Dic 2012 18:34
Agradecido : 296 veces
Agradecimiento recibido: 310 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 20 Jul 2017 12:26

Buenos días,
En la nueva versión de TIburón para FM-7 ya aparece Brody!
He 'marraneado' a colores el personaje, pero lo dejaré en blanco y negro como en Dragón ...
saludos
pere
BRODYenCOLOR.jpg
BRODYenCOLOR.jpg (71.97 KiB) Visto 244 veces

Avatar de Usuario
minter
Mensajes: 1806
Registrado: 22 Jul 2014 18:51
Agradecido : 1170 veces
Agradecimiento recibido: 494 veces

Re: Primeros pasos con el FM-7

Mensajepor minter » 20 Jul 2017 12:44

Mare meva, Pere!
Es que vas como un cohete!!!
Se vé perfecto!
Que yo me aclare como está el asunto. ¿Fondo el plano R y Brody en plano G? ¿Y silueta recortada con la mascara?
Y no hay mezcla de coloren del rojo y amarillo con el fondo!!! Porque... ¿Estan borrados del fondo y almacenados en un buffer?
Osea... ¿Si quitas el plano G... entonces tendríamos una silueta de Brody en el plano R?

Avatar de Usuario
pser1
Mensajes: 2213
Registrado: 08 Dic 2012 18:34
Agradecido : 296 veces
Agradecimiento recibido: 310 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 20 Jul 2017 13:11

minter escribió:Mare meva, Pere!
Es que vas como un cohete!!!
Se vé perfecto!
Que yo me aclare como está el asunto. ¿Fondo el plano R y Brody en plano G? ¿Y silueta recortada con la mascara?
Y no hay mezcla de coloren del rojo y amarillo con el fondo!!! Porque... ¿Estan borrados del fondo y almacenados en un buffer?
Osea... ¿Si quitas el plano G... entonces tendríamos una silueta de Brody en el plano R?

Veamos, despacito para no liarnos ...
Los planos son BRG (azul, rojo, verde) y para el cálculo de colores, valen respectivamente 1,2,4
Para 'captar' como se hace la mezcla de planos para obtener los colores compuestos, hay que tener presente esta tabla:

Código: Seleccionar todo

Color          B(azul)  Rojo    G(verde)  Código
NEGRO            0        0        0         0
AZUL             1        0        0         1
ROJO             0        1        0         2
VIOLETA          1        1        0         3
VERDE            0        0        1         4
AZULclaro        1        0        1         5
AMARILLO         0        1        1         6
BLANCO           1        1        1         7   

Pero nosotros hemos *redefinido* los colores asociados a cada código, por tanto cada combinación de planos.
El fondo en blanco y negro (la localización Casa) se envía al plano 'B' que es el de valor mas bajo.
Los códigos 0 y 1 han sido asociados en la paleta a los colores Negro y Blanco respectivamente, éstos forman el fondo (background).
Ahora nos quedan los planos 'R' y 'G' para el personaje. Tomamos el de *menor* valor o peso (el 'R') para meterle la máscara
invertida respecto a la que empleamos en Dragón. El cuerpo de Brody está formado por UNOS y los alrededores son CEROS.
Los ceros no afectan, pero como hemos definido en la paleta que los códigos 2 y 3 se muestren en negro, entonces, sea
cual sea el contenido del fondo, se pintará de color negro el interior de la silueta de Brody o máscara.
Ya solo nos queda enviar el dibujo real de Brody al plano 'G'. Como hemos definido que los códigos 4,5,6,7 sean Blanco, las
partes blancas (Unos) de la figura de Brody sobreescribirán la figura negra pintada en el plano 'R' obteniendo exactamente la
combinación deseada.
En mi imagen en color, he cambiado la paleta para que los códigos 2,3 sean ROJO y los 4,5,6,7 sean AMARILLO
por esto se ven en colores no muy acertados ...
Reconozco que el sistema es muy 'diferente' del que estamos acostumbrados a manejar, pero con paciencia nos iremos adaptando!
Cualquier duda respecto a la generación de Brody en pantalla, expónla aquí y comentamos la jugada
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2213
Registrado: 08 Dic 2012 18:34
Agradecido : 296 veces
Agradecimiento recibido: 310 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 20 Jul 2017 22:39

Novedades ...
He conseguido, a duras penas, que se mueva hacia la derecha empleando los fotogramas 2-1-3-1 siendo el 1 el estático y los
otros los de movimiento.
Me he tropezado con algunos problemas, estos son los que no tengo claro como evitarlos:
1) Cuando empleo el sprite 2 (o el sprite 3), aparecen en pantalla unas rayas horizontales sospechosas.
No sucede con el sprite1. Luego *algo* está modificando los datos de los sprites a nuestras espaldas
He encontrado que *dejando de usar* la rutina de imprimir texto en la linea 19 ... ya no sucede más!
Hay que averiguar qué área de la $c000-$cfff es usada por parte del monitor de texto
2) Al quitar la rutina de imprimir texto, cuando salgo del programa con la tecla Q, se queda la pantalla negra
pero haciendo CLS y Enter se muestra correctamente ... puede ser problema de restauración de colores / modo al salir
Resumiendo, los 3 sprites ocupan una barbaridad (3x16x56=2.688 bytes) y juntamente con el código especial para
el subsistema (nuevos comandos), llega desde $c000 hasta $cb8d -banghead

Hay un retardo exagerado en el programa para que se puedan ver los cuatro fotogramas del movimiento.
Para probarlo con una velocidad correcta, hay que hacer:
LOADM"SHARK11":POKE&H1125,16:EXEC&H1000
El valor que se ponga en &H1125 determina el retardo entre fotogramas, más rápido cuanto menor sea.
Básicamente creo que ya están puestos los pilares para incorporar los otros tres movimientos.
De momento solo admite mover DOS VECES hacia la derecha.
Una vez hecho, podéis mover DOS veces a la izquierda, Brody no se moverá pero el programa recuperará la posición inicial
de manera que se puede volver a entrar DOS veces derecha, aunque ahora se sobrepondrá con el dibujo que no se ha borrado.

En fin, ésto solamente es una muestra del avance del proyecto
Os adjunto zip con el fuente y el disco para probar
saludos
pere
SHARK11.ZIP
(52.9 KiB) Descargado 14 veces

Avatar de Usuario
minter
Mensajes: 1806
Registrado: 22 Jul 2014 18:51
Agradecido : 1170 veces
Agradecimiento recibido: 494 veces

Re: Primeros pasos con el FM-7

Mensajepor minter » 21 Jul 2017 12:33

pser1 escribió:Una vez hecho, podéis mover DOS veces a la izquierda, Brody no se moverá pero el programa recuperará la posición inicial
de manera que se puede volver a entrar DOS veces derecha, aunque ahora se sobrepondrá con el dibujo que no se ha borrado.


Jeje!!!
Le pongo el emulador al triple de velocidad y se mueve muy bien!!! -rofl
No pega saltos ni hace Moonwalker!
Es un avance de la repanocha!!!
-thumbup

Avatar de Usuario
pser1
Mensajes: 2213
Registrado: 08 Dic 2012 18:34
Agradecido : 296 veces
Agradecimiento recibido: 310 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 21 Jul 2017 18:52

minter escribió:
pser1 escribió:Una vez hecho, podéis mover DOS veces a la izquierda, Brody no se moverá pero el programa recuperará la posición inicial
de manera que se puede volver a entrar DOS veces derecha, aunque ahora se sobrepondrá con el dibujo que no se ha borrado.

Jeje!!!
Le pongo el emulador al triple de velocidad y se mueve muy bien!!! -rofl
No pega saltos ni hace Moonwalker!
Es un avance de la repanocha!!!
-thumbup

Con lo fácil que es hacer el poke y ponerle la velocidad que tu quieras sin 'modificar' la velocidad de emulación ...
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2213
Registrado: 08 Dic 2012 18:34
Agradecido : 296 veces
Agradecimiento recibido: 310 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 21 Jul 2017 19:58

Hola,
ya se mueve en las cuatro direcciones, si bien estoy empleando solamente los fotogramas que 'miran' hacia la derecha
Ahora tengo que encontrar una forma de decirle al SS que debe pintar invirtiendo los dibujos ...
Y aquí es donde pueden complicarse las cosas por tema espacio.
Tengo que añadir una rutina que lea el sprite en dirección contraria (de derecha a izquierda en lugar de izquierda a derecha)
y que busque el dato 'invertido' en una tabla de 256 bytes como se hizo en Dragón.
La cosa está en que aquí queda poquísimo espacio libre en el área $c000-$cfff
Habrá que ver si encontramos otra zona utilizable aunque sea pequeña. Cada byte cuenta!
Estamos siempre apurados por el espacio de memoria, que rabia -banghead
saludos
pere

jltursan
Mensajes: 2197
Registrado: 20 Sep 2011 13:59
Agradecido : 101 veces
Agradecimiento recibido: 270 veces

Re: Primeros pasos con el FM-7

Mensajepor jltursan » 22 Jul 2017 11:13

¡Brillante!, ya casi lo tienes :-)

Aunque el sprite quede en blanco y negro ya habrás visto que dispone de un color extra. Si es el rojo y lo mezclas con el blanco podrías darle colorete a la piel, ponerle pantalones negros y camisa a cuadros roja y negra :-D, la pena es que luego destacaría un montón con el escenario.

Todavía hay una apuesta arriesgada que hacer, dado que el personaje sólo se puede mover por determinadas zonas, sería cuestión de hacerse una idea clara de cuales son esas áreas a lo largo de todo el mapeado y saber que zonas del escenario estarían libres de sprites y así poderlas pintar con color. Es posible que se pudiese conseguir alguna mezcla discreta y que no desentonara mucho.

Avatar de Usuario
pser1
Mensajes: 2213
Registrado: 08 Dic 2012 18:34
Agradecido : 296 veces
Agradecimiento recibido: 310 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 22 Jul 2017 12:01

jltursan escribió:Aunque el sprite quede en blanco y negro ya habrás visto que dispone de un color extra. Si es el rojo y lo mezclas con el blanco podrías darle colorete a la piel, ponerle pantalones negros y camisa a cuadros roja y negra :-D, la pena es que luego destacaría un montón con el escenario.

Efectivamente, entiendo que trabajando en el PC se le podrían dar tres colores a Brody que responderían a las combinaciones
10 01 y 11 en los planos RG dejando el 00 para transparente.
Pero luego habría que convertirlo de nuevo al FM-7 y hacer el maldito proceso de generación de la máscara lo mas exacta posible.
No creo que valga la pena en nuestra situación actual ... de aprendizaje de programación de este cacharro!
Todavía hay una apuesta arriesgada que hacer, dado que el personaje sólo se puede mover por determinadas zonas, sería cuestión de hacerse una idea clara de cuales son esas áreas a lo largo de todo el mapeado y saber que zonas del escenario estarían libres de sprites y así poderlas pintar con color. Es posible que se pudiese conseguir alguna mezcla discreta y que no desentonara mucho.

Aquí si que se complican las cosas ya que en cada pantalla hay zonas accesibles y otras inaccesibles, pero no tengo claro que haya
una zona inaccesible común a *todas* las pantallas. La verdad es que preferiría plantearme mas adelante hacer un juego con sprites
bastante menores y a todo color, así veríamos como nos las apañamos con máscara y sprite como hice en Dragón (B y N)
En el próximo mensaje comento los puntos técnicos que me están frenando realmente
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2213
Registrado: 08 Dic 2012 18:34
Agradecido : 296 veces
Agradecimiento recibido: 310 veces

Re: Primeros pasos con el FM-7

Mensajepor pser1 » 22 Jul 2017 12:14

Buenos días,
Voy a intentar explicar mis 'preocupaciones' respecto a la conversión de Tiburón al FM-7
Es increíble que un programa que funciona sin problemas en un Dragón 32, resulte *CASI* imposible portarlo al FM-7,
probablemente debido a los sprites utilizados que son muy pero que muy grandes. Y no me refiero solamente a Brody, sinó
a los sprites que utilicé para hacer mover a Brody por detrás de la barandilla, del mostrador y del poste, NINGUNO de estos
sprites podrá añadirse en el FM-7 a menos que encontremos otra área de almacenamiento en el SubSistema

Actualmente ya *NO PUEDO* mostrar texto en pantalla sin que esto machaque algunos bytes de los sprites -banghead
Y quitar el texto de este juego es como matar el juego ... se me ocurre pintar textos en lugar de escribirlos con el subsistema
pero va a ser engorroso. Hay que ver lo poco que ayuda tener un área común tan ridículamente pequeña!
Y esto sin hablar del tema música de introducción y la reproducción de ficheros WAV para efectos, que aquí el chip dedicado
debería ayudarnos, ¿O no?

Voy a intentar añadir la rutina que invierte a Brody para el movimiento hacia la izquierda, que implica añadir la tabla inversora
que ocupa sus buenos 256 bytes, ya veremos si surgen mas pegas.

Resumiendo, que el absoluto desconocimiento de la máquina nos puede estar jugando una mala pasada, pero es lo que tenemos.
A ver si conseguimos una copia de los maravillosos manuales en castellano/inglés que ha 'heredado' Xion y ésto nos abre los ojos
para entender mejor a este ordenador que ahora nos resulta tan complicado.

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