Armando Perez Abad wrote:
"Fernandez D. Sopra-Bull" wrote:
Screen 2 o 4, el problema sería idéntico. Luego te lo explico.
Sigo ... ejem ... espero que se me entienda.
Vamos a ver. Como espero que sepas, Screen 2 es un modo de patrones. Es similar
al modo de video de nuestro pero claro ... no tienen sprites.
Los sprites son limitados, todos lo sabemos y en MSX1 mucho más.
Cuando se creaban estos juegos normalmente necesitaban de "sprites" mucho más
versátiles que los de la propia máquina. No había otra manera de conseguirlos,
que lo que se hace en MSX2 y Screen 5 con los copys, con la salvedad de que el
Screen 5 es un modo bit mapped (o algo así) donde cada punto puede ser de un
color y encima el VDP nos hace las "máscaras"
automáticamente, es decir, redefinir los caracteres.
En Screen 2 esto es muy complejo ya que partimos de que :
* Solo puede haber 2 colores por linea de byte. Que corresponden al bit
encendido y apagado.
* No disponemos de un comando que "pinte" un punto de un color determinado.
Esto lo consigue el Basic redefiniendo los patrones de caracteres cada vez.
Entonces para crear estos sprites, se necesita ir modificando los caracteres
continuamente. Si usamos COLOR para los caracteres, tendremos el famoso
"emborrachamiento" del mismo.
Imaginemos un sprite con unos colores determinados, y un caracter de fondo con
otros. Cuando el sprite se "superponga" encima si coincide que son 3 colores
diferentes ya está liada, pues solo se pueden tener 2 por mucho que te curres
la máscara. No se si estoy liándote o me estás entendiendo.
Venga te pongo un caso para que lo veas claro. Ponte el Maze of Galious. Si te
fijas en los objetos que dejan las piedras al romperlas, verás que hay un
"cuadro" negro alrededor. Esto es por que son caracteres, y a Konami le importó
poco el usarlos y dejar que se viera lo "negro" a realizar todo el juego en
monocromo. No se si me vas pillando.
Esta gente lo hacía todo en monocromo puesto que aquí "no hay emborrachamiento"
y se pueden hacer perfectamente todas las máscaras.
Entonces se hace lo siguiente :
Definimos toda la pantalla con colores negro para el bit a 0 y x para el bit a
1 (normalmente x era amarillo, aunque en la abadía usan más colores para
simular el anochecer, la parte de la biblioteca, cuando llevas la lampara, etc
...).
Luego se coge y cuando "pintas" el sprite lo que haces es redefinir los
caracteres que afecten a la x e y del sprite, de forma que dejes el fondo tal
cual y el sprite encima.
La verdad es que la técnica era compleja, y MÁS en MSX. Este modo viene
heredado de Spectrum PERO en Spectrum la Vram está direccionada como una parte
más de la memoria, permitiendo actuar sobre ella con cualquier comando típico,
lo cual da una velocidad muy aceptable ... Pero pongamonos en el caso del MSX.
Aquí es más complejo pues no podemos tratar la Vram
directamente, y hay que hacer un "buffer" en memoria y luego "mandar" los datos.
A ver :
Si hago :
ld a,1
ld (direccion de patrones en spectrum),a
Estoy redefiniendo la primera linea del primer patrón, pintando un pixel.
pero en MSX sería :
ld hl,0 (dirección patrones en SCREEN 2)
ld a,l (parte baja)
out (099h),a
ld a,h
or 64 (no recuerdo bién pero para escritura creo que había que sumar 64 al la
parte alta)
out (099h),a
ld a,dato (el uno del anterior ejemplo)
out (098h),a
A parte de que aquí lo que estás haciendo es que el patron (o caracter ) 0
tenga esa linea alterada.
Luego te toca ir a la tabla de nombres y poner el patron 0 en la posición de
pantalla 0
ld hl,01800h (dirección tabla nombres o atributos en SCREEN 2)
ld a,l (parte baja)
out (099h),a
ld a,h
or 64
out (099h),a
xor a (ld a,0)
out (098h),a
Por lo que es un poco bastante más lento si no te haces un buffer y trabajas
mandando muchos datos a la vez a la Vram (con otir)
El mismo problema lo tienes con los scrolls aunque este no es el caso. Si
quieres mover pixel a pixel un modo de patrones, al ir moviendo los caracteres
tienes que ir redefiniendo, y si el patron que esta a la derecha tiene colores
diferentes al de la izquierda (imaginemos un scroll nemesis), la has jodido.
Creo, y rectificarme si esto no es cierto, que el Moskow de Matra, evita este
problema al hacer el scroll de las vallas publicitarias, redefiniendo muy
estrictamente los patrones usados (sobre todo el color) y moviendo de 4 en 4 o
así este scroll.
Claro, que se puede hacer, pero se ha de ser muy estricto en el colorido /
grafismo de los patrones.
¿Que te quiero decir con todo este rollo?
Pues que independientemente de que lo pasemos a Screen 4, el problema es el
mismo. Habría que hilar muy fino para que los fondos tuviesen separación de
colores grande, y los sprites deberían de tenerla también.
Además ya no habría que jugar solo con los bits a 1 y a 0, si no con la tabla
de colores, lo cual complicaría el doble el juego.
También se puede hacer en Screen 2 / 4, coloreando los fondos y los sprites
pero ignorando el problema de los "cuadros negros".
No te digo que sea imposible, pero difícil si es. Es mejor plantearse una
versión en Screen 5.
Y claro, si en aquellos tiempos hubiesen tenido algo de respeto por el MSX,
este juego se podría haber hecho usando sprites, y calentandose la cabeza con
las máscaras, de forma que los patrones de fondo hubiesen podido colorearse y
mucho.
¿Sabes que juego lo intenta con colores pero claro ....? Las Tortugas Ninja.
Pruébalo para ver lo que te digo.
Todos los demás juegos que usen colores tienen el emborrachamiento. Mira "Viaje
al Centro de la Tierra", "Mortadelo y Filemón 2" y un sinfín de estos que
venían de spectrum y usan colores.
La verdad es que conseguir gráficos coloristas y "detallistas" con patrones en
screen 2 / 4 es todo un arte.
Konami lo evitaba muy bién. Sacrificaba el scroll pixel a pixel y movimientos
megasuaves, por un mayor colorido y grafismo. Y al fin y al cabo si el juego
era adicctivo esos problemas ni los miras.
¿Alguien se ha quejado alguna vez de que los Némesis sean caracter a caracter o
que no sean divertidos?
De todas formas, como con todo hay excepciones ... Pippols y Circus Charlie
tienen scroll pixel a pixel.
Y no me enrollo más que ya he dicho bastante.
--
Un saludo,
Armando Pérez Abad
HELIO YAGO, S.L.
http://www.bogamari.com
Tlf: (96) 363 43 17
Fax: (96) 390 27 17
