Mover sprite FW copiando el fondo en SC2

By Jury MSX

Resident (61)

Jury MSX's picture

18-04-2017, 16:47

Hola a todos,
¿Alguien conoce la técnica para ir copiando el fondo alrededor de un sprite creado por software en screen2?
Vamos, como hace el Batman o Head Over Heels, o la Abadía del Crimen (supongo).
Hasta ahora defino el contorno del sprite en tinta transparente, pero al colocarlo en pantalla me aparece el rectángulo vacío del sprite de 16x16 sobre el fondo. Supongo que deberé importar los bits del fondo sobre la parte sobrante de sprite, pero donde hacerlo ¿en las parte de VRAM reservada a los patrones de sprites (que no utilizaré)? o en la parte de ram definiendo variables para después pasar a la VRAM?.
La verdad es que no imagino como se consigue.

Gracias y saludos.

Login or register to post comments

By eldeljar

Supporter (9)

eldeljar's picture

19-04-2017, 10:57

Hola, yo estoy empezando a programar en MSX, por lo que no soy ningún experto en la materia. De momento estoy usando sprites por hardware, por lo que de momento no tengo mucha idea de los sprites por software.

Por lo que entiendo, al pintar el sprite sobre el fondo, la parte del sprite transparente "sobrescribe" los bits del fondo. En ese caso, el problema es que se está haciendo un "AND" bit a bit del sprite con el fondo. Puesto que el color transparente es el "0", al hacer una operación "AND" siempre el resultado será "0" y por tanto se pintará el color negro en lugar del fondo. Creo que lo correcto es unir el fondo y el sprite bit a bit mediante una operación "OR".

Como digo, no soy ningún experto ya que estoy empezando ahora, por tanto espero que te responda alguien que sepa más del tema por si lo que he dicho es incorrecto.

Saludos

By pitpan

Prophet (3131)

pitpan's picture

19-04-2017, 11:59

El sistema es sencillo, pero necesitas tener dos partes:
- Una "máscara" del sprite, que contenga lo que quieres que salga "negro" y donde quieres que se conserve el fondo.
- El sprite en sí mismo.

Primero pones la "máscara" sobre el fondo (usando AND) y luego el "sprite" encima (usando OR). Lo puedes complicar más y se puede optimizar todo lo que quieras, pero la idea básica es ésta.

Ejemplo muy sencillo:

Fondo de pantalla:
0101010101010101
1010101010101010
0101010101010101
1010101010101010

Máscara:
11000011
10000001
10000001
11000011

Sprite:
00000000
00111100
00111100
00000000

Fondo AND Máscara:
0100000101010101
1000000010101010
0000000101010101
1000001010101010

(Fondo AND Máscara) OR Sprite:
0100000101010101
1011110010101010
0011110101010101
1000001010101010

No sé si se ve bien, pero el concepto debería entenderse.

Lo más complicado con los sprites por software en MSX1 es lo siguiente:

- Necesidad de trabajar habitualmente en RAM para acelerar operaciones de lectura-escritura y hacer un único volcado (eficiente) a VRAM
- El desplazamiento pixel a pixel de los gráficos, que exige hacer muchas operaciones "shift" y lógica adicional para que todo funcione correctamente.
- Hacer todo lo anterior de una forma eficiente, optimizada y rápida (en esto nos gana siempre el Spectrum, por tener la VRAM accesible como RAM directamente)

En su día hice algunas pruebas, y aunque las demos ya no están disponibles on-line, el snippet que hacía el trabajo básico, sí: http://karoshi.auic.es/index.php/topic,1456.0.html

Hasta aquí llega mi capacidad actual de ayuda.

By Jury MSX

Resident (61)

Jury MSX's picture

19-04-2017, 19:43

Si que se capta muy bien la idea, queda muy bien explicado. A ver si puedo ponerlo en práctica (creo que estaré entretenido un buen rato).
Mil gracias.

By DarkSchneider

Paladin (867)

DarkSchneider's picture

27-04-2017, 12:27

Lo "malo" es que el MSX no se diseñó para eso y el operar sobre la VRAM para aplicar máscaras por software puede ralentizar mucho. Si no es importante pues adelante.

By pitpan

Prophet (3131)

pitpan's picture

27-04-2017, 14:30

El problema es cuando no se hace de una forma "optimizada". Las malas conversiones de Spectrum eran lentas precisamente por eso: volcaban demasiados datos de RAM a VRAM, donde está el auténtico cuello de botella, por lo que la renderización de cada frame ocupaba demasiado tiempo. Otros juegos, sin embargo, con una programación y diseño más eficiente, no se resentían tanto. Está claro que no es la opción óptima para MSX, y que siempre estaremos en desventaja en este sentido respecto a ordenadores con la VRAM mapeada en RAM, pero puede ser imprescindible para según qué conceptos.

Otra posibilidad es la combinación de sprites por software y por hardware, pero lo cierto es que ahora mismo sólo me viene a la mente el GREEN BERET de Konami UK. El juego no está mal, pero resulta lento y eso afecta a su jugabilidad. La idea no es mala: las máscaras negras de los objetos móviles son sprites por software, mientras que el resto son sprites por hardware.

En cualquier caso, con un uso razonable se pueden conseguir efectos interesantes y a velocidades asumibles. Como último apunte, decir que también se puede incorporar color a los sprites por software, pero esto supone duplicar la información a procesar.