Técnicas usadas por los programadores para sobrepasar límite teórico del Harware?

En los sistemas de 8 bits sobretodo se han hecho auténticas salvajadas. Mirando lo que se ha llegado a hacer con el MSX, Amstrad, Spectrum Comodore 64, o incluso Atari 2600. Buscando demos uno llega a sorprenderse:

http://www.pouet.net/

En muchas máquinas, hay dos efectos que se pueden hacer (el otro día los discutimos con @theelf en otro hilo)

- Cambio de paleta en midframe: Aprovechar la interrupción horizontal para cambiar la paleta antes de que se cambie de linea. Esto se usa en los Sonic para cambiar la paleta a medio frame para poner la paleta de debajo el agua. Dependiendo de la máquina, es posible que te dé tiempo a cambiar más o menos colores. Un efecto "común",era pintar el cielo con un color determinado de una paleta, e ir cambiando dicho color de la paleta cada pocas lineas, de manera que obtenía sun degradado multicolor solo gastando un color. Una variante, menos útil ya que solo funciona con imagenes estáticas, consiste en usar en la mega el DMA para actualizar un color cada PIXEL, pudiendo imprimir una imagen de 512 Colores simultaneos en lugar de 64.

- Multiplexación de Sprites: En máquinas con sprites por hardware (MSX, C64, consolas), usar los sprites por hardware en , por ejemplo, la mitad superior de la pantalla, y a mitad de pantalla, actualizar la tabla de sprites, de manera que vuelves a usar todos los sprites en la mitad inferior de la pantalla. Con esto, en C64, hacían juegos de naves solo con los 8 sprites por hardware disponibles.

kusfo79 escribió:En muchas máquinas, hay dos efectos que se pueden hacer (el otro día los discutimos con @theelf en otro hilo)

- Cambio de paleta en midframe: Aprovechar la interrupción horizontal para cambiar la paleta antes de que se cambie de linea. Esto se usa en los Sonic para cambiar la paleta a medio frame para poner la paleta de debajo el agua. Dependiendo de la máquina, es posible que te dé tiempo a cambiar más o menos colores. Un efecto "común",era pintar el cielo con un color determinado de una paleta, e ir cambiando dicho color de la paleta cada pocas lineas, de manera que obtenía sun degradado multicolor solo gastando un color. Una variante, menos útil ya que solo funciona con imagenes estáticas, consiste en usar en la mega el DMA para actualizar un color cada PIXEL, pudiendo imprimir una imagen de 512 Colores simultaneos en lugar de 64.

- Multiplexación de Sprites: En máquinas con sprites por hardware (MSX, C64, consolas), usar los sprites por hardware en , por ejemplo, la mitad superior de la pantalla, y a mitad de pantalla, actualizar la tabla de sprites, de manera que vuelves a usar todos los sprites en la mitad inferior de la pantalla. Con esto, en C64, hacían juegos de naves solo con los 8 sprites por hardware disponibles.

Sí señor, 2 técnicas muy habituales. De hecho la interrupción horizontal de línea permite incluso cambiar el modo gráfico, por ejemplo hacer el juego en low res y los marcadores en high res.

La multiplexación de sprites tiene una variante que se refiere al flicker de los mismos. Así por ejemplo los Aleste en MSX2 usan el doble de los sprites hardware que permite la máquina porque les cambian la prioridad en tiempo real de forma que flickean alternativamente en cada fotograma. https://www.youtube.com/watch?feature=p ... sWg#t=2955 No he encontrado video mejor, lo está jugando en normal, pero si lo juegas en hard la pantalla se peta de sprites.

Otro truco usado en MSX1 para implementar scroll al pixel ya que no puede hacerlo por hardware: almacenar los tiles gráficos desplazados. Se consigue un scroll endibladamente suave (60fps rocosos, https://www.youtube.com/watch?feature=p ... lFCk4#t=39 el vídeo no hace justicia) porque en verdad no estás haciendo tal scroll, sino que estás pintando variantes del mismo tile.

Otro truco, este de MSX2, para generar scrolles laterales (el VDP solo lo hace vertical): juegan con una función del VDP que permite desplazar la pantalla (Set adjust) de modo que desplazas la pantalla completa y recolocas los sprites. El efecto es un scroll a pantalla completa https://www.youtube.com/watch?feature=p ... 2WpdxM#t=9

Truco gráfico usado en MSX2: operación and de colores. Los sprites tienen un límite máximo de 2 colores por línea. Para paliar eso puedes definir operación AND entre colores, disfrutando de un 3er color adicional. El mismo Super Mario World del video anterior lo utiliza, dando lugar a sprites más vistosos.

En verdad en 8 bit hay técnicas a patadas, la gente le echa imaginación de narices para exprimir de donde no hay.

En Game Gear por ejemplo no se podían invertir los sprites. Tenias que duplicar la cantidad de sprites solo para cambiar la orientación de un personaje, con el consiguiente consumo de memoria.Pero descubrieron un bug en el hardware, que forzaba un retardo al acceder a la memoria de video y aprovechaban el retardo para duplicar el sprite e invertirlo cuando se cargaba el nuevo frame.

En muchas consolas de los 90 y algunas de los 00 como GBA era imposible conseguir transparencias, para eso usaban una tecnica llamada blending que permite combinar el valor para color en dos capas superpuestas, creando así una transparencia.

Otra técnica muy usada era la "coherencia de cache" en las consolas mas modernas donde se programaba en C, consiste en reducir dentro de lo posible los acceso a memoria para ahorrar ciclos de la cpu aprovechando los datos ya cargados en la cache.

En el Ranger X de Megadrive usaron un truco para aumentar la cantidad de colores en pantalla, aunque creo que en una captura igual no se puede apreciar.

NiTrO escribió:En Game Gear por ejemplo no se podían invertir los sprites. Tenias que duplicar la cantidad de sprites solo para cambiar la orientación de un personaje, con el consiguiente consumo de memoria.Pero descubrieron un bug en el hardware, que forzaba un retardo al acceder a la memoria de video y aprovechaban el retardo para duplicar el sprite e invertirlo cuando se cargaba el nuevo frame.

Qué curioso, un bug que se puede aprovechar para optimizar memoria y por consiguiente para mejorar los gráficos, por ejemplo.

javierator1981 escribió:

NiTrO escribió:En Game Gear por ejemplo no se podían invertir los sprites. Tenias que duplicar la cantidad de sprites solo para cambiar la orientación de un personaje, con el consiguiente consumo de memoria.Pero descubrieron un bug en el hardware, que forzaba un retardo al acceder a la memoria de video y aprovechaban el retardo para duplicar el sprite e invertirlo cuando se cargaba el nuevo frame.

Qué curioso, un bug que se puede aprovechar para optimizar memoria y por consiguiente para mejorar los gráficos, por ejemplo.

Lo creas o no los bugs se explotaban mucho en esa época, en los 8bit han sido fuente de técnicas poco ortodoxas para sobrepasar los límites del hard . Lo de invertir los sprites realmente es un problema habitual en esa época, fue una de las mejores funciones aportadas por ciertas consolas que podían hacerlo por hardware y evitabas tener que definir 2 veces el mismo sprite. Si no me equivoco fue la NES la que introdujo esta característica, me sorprende que Game Gear siendo muy posterior cometiera el error de no traerla.

No es ningun un truco, pero es algo que suelo usar en Megadrive

Por ejemplo, tenemos un elicoptero que ocupa bastantes tiles, asi que pasamos de que sea sprites, y lo hacemos como tiles normales en uno de los planos de scroll

Por decir algo, el elicoptero tiene 96 tiles, de los cuales, 60 son fijos, y los demas, corresponden a partes moviles



Pues el truco esta en hacer el mapa de tiles, de forma ordenada, para que los siguientes cuadros de animacion, usen el mapa original, y simplemente se cargen los nuevos tiles a vram



Parece una tonteria lo que digo, pero he visto mucho homebrew (no se si juegos comerciales) que directamente vuelven a cargar el sprite/mapa de tiles, en vez de usar un modo menos chuparecursos como el que digo

El truco de recargar los tiles de un tilemap, teniéndolos bien ordenados para ello, lo usamos para animar los cruceros del fondo de la primera fase del Antarex