Mojonia 3.0

Es que usar sprites para cubrir una pantalla es un poco overkill... En splib2, cada sprite ocupa 15 bytes de memoria dinámica por cada bloque que usa más un bloque más. O sea, un sprite de 16x16 que usa 9 bloques ocuparía 150 bytes. Estoy seguro de que en SP1 ocupan incluso más. 38 sprites son ya 5700 bytes, un pasote. Los 192 sprites que quieres poner ocuparían más de 28K de tu pool de memoria dinámica.

Por lo general cuando haces un juego estás bastante apretado (y con SP1 mucho más, por eso nunca me he decidido a pasarme), así que lo suyo es contar como un avaro cada bloque de memoria dinámica que vas a usar. En MK2 por ejemplo se reserva justo la memoria que se necesita para justos los sprites del tamaño justo que se va a necesitar en el juego. Para un juego normal, por ejemplo, de 4 sprites de 16x16 y 3 disparos de 8x8 reservamos 4*10+3*5=55 bloques, o sea, 55*15=825 bytes, y ni uno más. Hay que mirar mucho por la memoria.

Además, la velocidad de proceso de cada frame del juego si usas sprites de fondo puede ser REALMENTE lenta.

Para rellenar la pantalla hay que usar tiles de fondo del charset. Los sprites déjalos para cosas que se muevan. Los tiles sólo ocupan un par de bytes que ya están reservados en la tabla de tiles, dentro del binario estático que genera el compilador.

$this->bbcode_second_pass_quote('na_th_an', 'P')ara rellenar la pantalla hay que usar tiles de fondo del charset. Los sprites déjalos para cosas que se muevan. Los tiles sólo ocupan un par de bytes que ya están reservados en la tabla de tiles, dentro del binario estático que genera el compilador.

No.

Tienes que tener muy clara la diferenciación de los elementos que componen el display. Es muy importante.

splib2 y SP1 funcionan emulando el modo de funcionamiento de los chips gráficos de las consolas (la mayoría de las de 3ª y 4ª generación: NES, Master System, Megadrive, SNES...) y de algunos ordenadores como C64 o MSX. La pantalla no se considera un framebuffer o un array de pixels, sino que está formada por una rejilla de tiles de fondo y un número de sprites que se mueven sobre dicha rejilla, sin alterar el fondo. Como el Spectrum no es capaz de hacer eso por sí solo, splib2 y SP1 le proporcionan una solución software para comportarse así.

Un sprite es un elemento móvil, formado por un número de bloques de 8x8 pixels (en otros entornos, como cuando programas un chip gráfico de una consola, se llama "metasprite" porque los sprites, son, en realidad, las unidades básicas, en este caso cada cuadro de 8x8 que lo compone). Cada bloque almacena su posición, atributos y propiedades, y un enlace a información con el gráfico y su máscara. O sea, por cada cuadro de 8x8 se almacenan muchos bytes (en splib2, 15 en concreto), que son necesarios para poder cambiarlo de posición y poder restaurar el fondo que tiene debajo, entre otras cosas.

Un tile es un elemento fijo. La pantalla se divide en una rejilla de 32x24 tiles (correspondientes a los caracteres) de 8x8 pixels. Para cada celda de la rejilla se define un número de tile y su color. Es lo que se utiliza como fondo, porque un tile no se va a mover de su sitio y la información que se precisa almacenar es mínima.

El "charset" o "tileset", como quiera llamarse, es un número discreto de gráficos de 8x8, cada uno con un identificador o número de orden. En el tileset, la rejilla de fondo, se contienen los números que identifican a cada tile del charset, no el gráfico en sí. Por eso, el fondo únicamente puede estar compuesto por los gráficos del charset. Dependiendo del hardware o de la biblioteca que se use por software, este número varía. Por ejemplo, en NES o splib2 son 256. En Megadrive son algo más de 1500.

Cuando montamos una escena con una de estas bibliotecas, o con un chip gráfico basado en tiles y sprites, definimos un diseño dándole valores del charset a la rejilla de tiles y luego creamos un número de sprites que se muevan sobre la rejilla para representar al personaje, los enemigos, los proyectiles... las cosas que se mueven.

Lo que se exporta con mapcnv no es más que una colección de los metatiles que componen cada pantalla. Un metatile se define como un rectángulo de tiles que se considera una unidad. Por ejemplo, en la Churrera y en MK2, cada pantalla está compuesta por 150 metatiles en un rectángulo de 15x10, y cada metatile tiene un tamaño de 16x16 pixels, por lo que debe estar compuesto por 2x2 tiles de la rejilla de tiles que maneja la biblioteca.

El motor lee el array y dibuja sobre la rejilla cada uno de los metatiles según se los va encontrando, colocando los cuatro tiles que forman cada metatile según el índice que encuentre en el array. En la Churrera y MK2 el proceso es muy sencillo ya que cada metatile siempre está compuesto por cuatro tiles de id secuencial, empezando por el tile 64 del charset. O sea, cada vez que vamos a pintar un metatile que en el array está referenciado con el número "N", en realidad estamos pintando los tiles de charset de números 64+N*4, 64+N*4+1, 64+N*4+2 y 64+N*4+3, los dos últimos debajo de los dos primeros.

Esto se hace para ahorrar memoria. El área de juego de nuestros motores es de 240x160 pixels, o lo que es lo mismo, 30x20 caracteres. Eso ocuparía 600 bytes. Usando metatiles de 2x2 caracteres, perdemos algo de libertad para confeccionar las escenas, pero sólo necesitamos 15x10 metatiles que ocupan 150 bytes, o sea, la cuarta parte. Si, además, usamos sólo 16 metatiles diferentes para hacer nuestro mapa, vemos que en cada byte podemos meter dos, con lo que cada pantalla pasa a ocupar sólo 75 bytes. De esa forma, 10 pantallas pasarían de ocupar 6000 bytes a ocupar sólo 750, algo muy importante cuando se programa para máquinas tan limitadas.

Aunque no me gusta demasiado cómo resuelve algunas cosas, creo que los últimos capítulos del curso que se publicó en tiempos en Magazine ZX es buena introducción a este sistema de organización de la pantalla. Échale un vistazo a este PDF que recopiló Radastan, a partir de la página 93 http://www.bytemaniacos.com/ficheros/zx ... /z88dk.pdf

$this->bbcode_second_pass_quote('na_th_an', 'A')unque no me gusta demasiado cómo resuelve algunas cosas, creo que los últimos capítulos del curso que se publicó en tiempos en Magazine ZX es buena introducción a este sistema de organización de la pantalla. Échale un vistazo a este PDF que recopiló Radastan, a partir de la página 93 http://www.bytemaniacos.com/ficheros/zx ... /z88dk.pdf