Mojonia 3.0

Eso es diferente... Lo que hace ese emu es tener una especie de memoria rara "paralela" en la que cada bit es en realidad un byte. Lo que hace es que cuando la CPU manda copiar un byte de memoria de RAM a la pantalla, en realidad es copiar 8 bytes de la memoria especial... De ese modo, lo que antes era un pixel on/off (1 bit) es ahora un pixel de 256 colores.

Es como si fuera un spectrum con un mapa de memoria de 64x8 = 512 kbytes aparte de los 64Kb básicos, donde están los bits de la memoria principal "expandidos", y una ULA especial muy rara que mantiene sincronizada la memoria "normal" (de bits) con la memoria rara "Paralela" (de "bits de 8 bits"). Un show irrealizable en hardware, vaya.

Los juegos hay que adaptarlos a mano. Hay que buscar donde están los bits de los gráficos en la RAM y darles a cada uno un valor de color. No en todos los juegos es posible, suele funcionar sobre todo con los monocromos.

No es algo que pueda hacerse de modo automático con un juego normal para eliminar el colour clash. Ya te digo que para mover cosas en la pantalla solo hay que escribir bytes en la parte de la RAM que la representa. La ULA es la que interpreta esa RAM en forma de imagen. El emulador sólo ve bytes que se escriben en RAM. De un byte puede haber parte de sprite y parte del fondo que había antes... ¿Cómo saber qué parte es sprite y qué parte es fondo?

Gracias por la explicación.

Vamos, desde mi ignorancia, ¿pero no pinta primero una cosa y luego otra? Es decir, cuando hay un fondo y un muñeco moviéndose, ¿no se pinta primero el fondo y luego encima el muñeco? ¿O ambos van a la vez? Porque los colores sí se mezclan, pero los sprites parece que no... o al menos eso parece.

No. Tú sólo puedes mover bytes a la pantalla. Para que haya un fondo detrás del sprite, hay que coger el byte con el cacho de 8 pixels del fondo, ponerle encima el cacho de 8 pixels de la máscara, que hace un agujero negro en el fondo, y luego mezclarle encima el cacho de 8 pixels del sprite, sobre el agujero negro de antes. Y eso se coloca en la pantalla de nuevo. Eso es, digamos, "sprites por software": es el programa el que tiene que componer los sprites sobre el fondo, la CPU no se entera de nada, ella solo ve datos para acá y para allá. No sabe si son variables, fondos, sprites, programa... sólo son bytes de datos.

Otros ordenadores (C64, MSX) y consolas (cualquiera de la 3ª o 4ª generaciones) funcionan por hardware y tienen un chip que se encarga de hacer esas cosas de forma automática. En Spectrum o CPC no hay nada de eso y tiene que hacerlo el programador.

La diferencia es que en CPC se usan más bits por cada pixel, y por eso pueden tener varios colores. En modo 0 cada pixel lo forman cuatro bits, por lo que cada pixel puede tener 16 colores diferentes (hay 16 combinaciones diferentes de apagado/encendido para 4 bits). En Spectrum, sólo se usa un bit por cada pixel, y solo puede estar apagado o encendido, o sea, tenemos un bitmap monocromo. Luego toma un color u otro dependiendo de los atributos, que es como un celofán de colores de baja resolución que se le pone encima al monocromo, y por eso existe el "colour clash". Esto se hizo así porque permite gráficos de colores sin gastar mucha memoria RAM (poco menos de 7Kb).

Aparte de que lo que mola de los 8 bits son las peculiaridades de cada sistema. Es lo interesante y lo divertido. Cada sistema tiene su intríngulis y su aspecto y mola explotarlo y jugar con ellos

Si no quisiésemos limitaciones, hacer un juego en PC con las características de la churrera sería terriblemente sencillo... ¿pero dónde estaría la gracia?

$this->bbcode_second_pass_quote('na_th_an', 'S')i no quisiésemos limitaciones, hacer un juego en PC con las características de la churrera sería terriblemente sencillo... ¿pero dónde estaría la gracia?