Pues depende de para qué tiene muchísimas ventajas, me explico (tocho con datos, cuidado):
Primero vamos a dejar claro que la discusión se basa en un MSX2 o superior. Teniendo esto en cuenta Screen 4 es, insisto una vez más, I-DÉN-TI-CO a SC2, con la única salvedad de que tenemos acceso al modo 2 de sprites y que en lugar de poder poner 4 sprites en línea podemos poner hasta 8. Así que dejando de un lado el tema sprites, todo lo que voy a comentar es válido para SC2 y SC4 (siempre que estemos en un MSX2 o superior, claro está).
La ventaja que tenemos con estos modos es que son modos por patrones, no modos bitmap como SC5 a SC8. Eso quiere decir que con un simple VPOKE podemos cambiar un bloque completo de 8x8 pixels, es decir 64 pixels. Eso mismo en SC5 supondría un total de 32 VPOKEs (puede que incluso sean necesarios además 32 VPEEKs) o 64 en SC8. Actualizar la pantalla completa supondría unos 768 VPOKEs frente a los 24576 en SC5 o los 49152 necesarios en SC8 (todo a 256x192, sin usar los 20 pixels verticales extra de los que disponemos si queremos). Recordemos siempre que las transferencias a VRAM son el principal cuello de botella del MSX, así que si necesitamos muchas actualizaciones de pantalla, el modo ideal es SC2/SC4.
Gracias a eso y con un poco de arte por parte del grafista, es posible hacer efectos bastante interesantes que en modos bitmap serían muy difíciles de conseguir (por no decir imposible). Échale un vistazo al Malaika de Karoshi. Está hecho en SC2, pero (repito) salvando los sprites es lo mismo que SC4. El scroll suave es por software, algo que es factible en SC2/SC4, pero no en SC5 o superior.
Vale, ahora dirás que no te vale el ejemplo porque el MSX2 puede hacer scroll por hardware. Cierto, aunque el MSX2 tiene scroll por hardware vertical y no horizontal, es posible simular un scroll horizontal mediante el comando SET ADJUST y un uso inteligente de sprites para enmascarar los bordes. Sin embargo ese scroll afecta a toda la pantalla. Si bien es cierto que con trucos sería posible hacer lo mismo para determinadas zonas, es bastante costoso y no se podría realizar lo mismo en vertical.
Vayamos con un ejemplo algo más contundente y con datos.
<Autopublicidad mode on>
Ahora échale un vistazo a mi juego QBIQS
en un MSX2. El juego está realizado en SC2, aunque si estamos en un MSX2 o superior se cambia a SC4 para así poder evitar los leves parpadeos de sprites que había en ocasiones. Por lo demás, el motor es el mismo.
El scroll de las piezas es por software y el de los laterales es un scroll mezcla de software (MSX1) con hardware (MSX2 o superior) que, además, no utiliza el registro de scroll vertical del MSX2 ni el SET ADJUST. Eso es IMPOSIBLE de hacer en un modo bitmap como hizo Konami con el Quarth. Si te fijas en ese juego (que está en SC5) los laterales van a la misma velocidad que las piezas y encima hay una línea de separación entre la parte de acción y los marcadores (debida a uno de los trucos que antes mencioné: un screen split que, en esta ocasión, no les quedó muy fino que digamos).
Gracias a que SC2/SC4 es un modo por patrones, actualizar la zona de scroll en modo 1 jugador cuesta sólo 320 transferencias a VRAM y en modo 2 jugadores 240 por jugador. Además, gracias a que el scroll de las piezas es por software, es posible que las piezas de cada jugador tengan un scroll suave, algo que tampoco aprovecha el Quarth (que en modo 2 jugadores sí que usa SC4 por motivos de velocidad, ya que es imposible usar SC5).
En cuanto al scroll de los laterales, en MSX1 supone un total de 242 VPOKEs cada 16 pixels que hayan avanzado las piezas y en modo 2 jugadores sólo 76 VPOKEs por jugador (en esta ocasión cada 2 pixels que hayan avanzado las piezas). Todas estas transferencias entran muy muy justas dentro del VBLANK salvo el scroll de los laterales en modo 2 jugadores a 60hz, que es el único punto del juego en el que las transferencias a VRAM se salen del VBLANK (y, por tanto, hay que meter pausas o el VDP se atraganta).
Ahora multiplica por 32 cada una de esas cifras y tendrá el número de transferencias necesarias para realizar eso mismo en SC5. Eso prueba la imposibilidad física de que este juego hubiera podido ser realizado en un modo bitmap como SC5.
<Autopublicidad mode off>
Ahora bien, si las pantallas son más estáticas, sin mucho movimiento, un modo bitmap puede ofrecernos muchísimo más colorido y libertad. No olvidemos las restricciones que tienen SC2/SC4 con respecto a los colores.
Espero que tras este tocho veas las grandes posibilidades que un modo por patrones tiene con respecto a un modo bitmap. Cada modo para lo que sirve, no hay que menospreciar ninguno... ¿quizá SC3?
