La carrera de los bits y los megahercios, tercera parte

Cómo juegan los PCs y las consolas

Al final del anterior artículo comparábamos las especificaciones de la PlayStation 2 con las de un PC de la época, y tal y como dije, en éste voy a aplicar toda la teoría que expuse a este caso práctico, enfrentando ambas máquinas. ¡Que gane el mejor! 😉

Cómo «juega» un PC

El PC de prueba será un Athlon 700MHz, 128Mb RAM (SDRAM 100MHz) y una GeForce 256. Para ilustrarlo, iré mencionando las distintas fases en la ejecución de un juego en 3D.

1. Fase de aplicación

El programa, que se ejecuta en la CPU, controla la evolución del juego y determina los pasos que son necesarios en cada momento. Gestiona los controles (teclas, mando, joystick…), los datos con los que se trabaja (puntuación, inventario, vida…), la información del entorno (la disposición del paisaje, el punto de vista, la posición de los objetos, la organización…) y la inteligencia artificial. En definitiva, toda la ejecución del juego en la que no se procesan gráficos. En esta fase se hace uso de la CPU, la memoria RAM y el bus del sistema (para traer las instrucciones y los datos hasta la CPU). Así pues, un factor decisivo para agilizar esta fase será el ancho de banda del bus del sistema y la velocidad de la RAM y la CPU.

Ancho de banda de la Memoria	Caché CPU	Velolcidad CPU
1,6Gb/s	64Kb (L1) y 512Kb (L2)	700MHz

El ancho de banda de la memoria se calcula así: la memoria está conectada a la CPU a través del bus principal del sistema, cuyo ancho es de 128 bits, y funciona a 100 MHz, y como la memoria es de tipo SDR, manda un bit por cada linea en cada ciclo de reloj. Como hay 128 líneas, y 100 millones de ciclos (100MHz), tenemos,

(100MHz * 128) / 8 = 1600 MBytes

(la división por 8 es para pasar de bits a bytes)

Esta fase generará una representación matemática que definirá el mundo que se va a mostrar por pantalla, y que servirá para formar el entorno tridimensional, a base de polígonos, texturas y efectos.

---

2ª Fase de transformación El mundo que hay que mostrar está compuesto de polígonos, sobre los cuales habrá normalmente una textura (o varias), y seguramente algún efecto (la iluminación, por ejemplo). Estos polígonos están formados por vértices, y la posición de cada vértice tiene que ser calculada. Así pues, una pirámide de 3 caras tiene 4 vértices (el de la cima y 3 en la base), y será menos costoso de calcular que una pirámide de 4 caras (que tiene 5 vértices) e igual de costoso que un rectángulo (que también tiene 4 vértices). Hazte a la idea de que si se dice que un juego mueve 5 millones de polígonos por segundo, suponiendo que sean de 4 vértices, significará que el hardware está moviendo 5 * 4 = 20 millones de vértices, y cada vértice tiene 3 coordenadas (altura, anchura y profundidad). En total, 20 * 3 = 60 millones de coordenadas. El cálculo de los vértices y la posterior iluminación sobre ellos requiere muchas operaciones complejas en coma flotante. Esta será la tarea de la fase de transformación. Pasar la representación matemática del mundo a una lista de elementos preparados para ser convertidos a imágenes. En el PC, hasta la aparición de tarjetas aceleradoras con motor T&L y vertex shader, todas estas operaciones eran llevadas a cabo por la CPU. De momento supondremos que así es, para evitar complicaciones, y mantenerlo lo más didáctico posible (aunque la Geforce 256 del ejemplo fue la primera tarjeta en tener T&L, así que imaginemos que el juego que estamos ejecutando no hace uso del nuevo motor T&L, cosa que era muy habitual al principio). Por tanto, en un PC la carga en esta fase recae sobretodo en la potencia de la CPU, en especial en su rendimiento en coma flotante. También es importante el ancho de banda del bus, para asegurar que el suministro de datos es suficiente. No vale de nada calcular muy rápido si tienes que esperar a que te lleguen los operandos de la memoria. Si uno de los dos factores es bajo, limita al otro, y se dice que es un cuello de botella.

En esta fase, los movimientos de datos son similares a los de la fase de aplicación. La diferencia radica en que el trafico con memoria RAM es más elevado, y se traen muchos menos desde discos duros o CD (ya que suponemos que la información requerida está cargada). Además, la CPU lleva a cabo, habitualmente, más trabajo. El rendimiento de las caches es pues, más importante.

GFLOPS CPU	Ancho de banda de la Memoria	Caché CPU
2,8GFLOPS	1,6Gb/s	64Kb (L1) y 512Kb (L2)

Los GFLOPS de la CPU los he calculado así: El Athlon tiene 3 unidades vectoriales de coma flotante. Una es usada en operaciones simples de suma y comparación, otra en operaciones complejas, como la multiplicación o la división, y la otra se usa para cargar y almacenar operandos, luego no realiza operaciones estrictamente hablando, así que no la contaré (aunque sin duda es imprescindible para asegurar el buen funcionamiento de las otras). Cada una de las 2 unidad de cálculo puede hacer 2 operaciones por ciclo. Luego, para alcanzar el máximo teórico, podríamos hacer 2 sumas y 2 multiplicaciones por ciclo. Eso serían 4 operaciones por ciclo.

700MHz * 4 = 2800 MFLOPS = 2,8GFLOPS

Pero esto es muy optimista. Por ejemplo, debes recordar que 4 multiplicaciones llevan 2 ciclos, porque sólo hay una unidad de ejecución para ese tipo de operaciones (y sólo se alcanzarían 1,4GFLOPS). Para llevar al rendimiento máximo, habría que alternar sumas y multiplicaciones, por ejemplo. Además hay operaciones más costosas, como la división, que lleva varios ciclos de reloj, y que haría caer el rendimiento bien por debajo del GFLOP.

Cuando se finaliza la transformación, se envía la lista de elementos a la tarjeta gráfica para ser renderizada.

---

3ª Fase de renderización. Renderizar es convertir la lista de elementos 3D calculados en la fase de transformación a una imagen 2D que pueda ser mostrada por pantalla. En un PC esta tarea se lleva a cabo en la tarjeta gráfica. Por tanto habrá que mandar la lista, junto a las texturas necesarias, a la memoria de video, montada en la tarjeta. Y por tanto, la carga va a recaer en el bus que se usa para comunicar la CPU con la tarjeta (normalmente, desde hace años, AGP), y en la potencia de renderizado de la tarjeta, sobretodo su fill-rate, o tasa de relleno, que habitualmente índica el máximo número de píxeles por segundo que puede dibujar en pantalla. La tarjeta va procesando los píxeles, calculando su color, posición, y posibles efectos (como filtrado bilinear, trilinear o anisotrópico) y se van almacenando en la memoria de video, en lo que se llama frame-buffer (información de posición y color de cada píxel), y Z-buffer (información de la posición en profundidad de cada píxel). Es importante tener claro que todo esto está metido en la misma memoria de video, que se comparte para texturas, lista, frame-buffer y Z-buffer. Por tanto otro factor decisivo será la cantidad de memoria de video. Cuanta más memoria, más texturas podremos almacenar y mostrar simultáneamente, y más resolución podremos soportar. Supongamos que cada píxel puede mostrar unos 64.000 colores distintos. Se necesitan 16 bits para cada píxel (2^16 = 65.554), o lo que es lo mismo, 2 bytes. Un frame-buffer a 1024×780 de resolución, necesitará almacenar la información de 798.720 píxels, y como cada uno requiere 2 bytes, el frame-buffer ocupará 1.597.440 bytes de la memoria de video. Posiblemente el Z-buffer también, y por tanto unos 3 megabytes serán consumidos únicamente para almacenar una imagen a 1024×780, aunque no haya ni un solo polígono ni textura en ella.

Ahora vamos a meter tralla al bus AGP, para mandar todo a la tarjeta gráfica, así como al bus principal de la placa base. Los anchos de banda son ahora muy importantes. Aunque dibujo flujos desde y hacia la CPU, en realidad estos son menos importantes que el resto.

Ancho de banda del AGP*	Memoria Video	Ancho de banda de la memoria de video	Tasa de relleno
1Gb/s	32Mb	2,6Gb/s	480Mpíxels/s

El ancho de banda del AGP lo calculo sabiendo que su bus es de 64 bits, y suponiendo que funciona a 2X (133MHz):

(133MHz * 64) /8 = 1064 Mb

El ancho banda de la memoria de vídeo depende de la tarjeta. En el caso de la Geforce 256, la memoria funciona a 160MHz, y está conectada a la GPU por un bus de 128 bits:

(160MHz * 128) /8 = 2560 Mb (aprox 2,6Gb)

La tasa de relleno se calcula sabiendo que la GPU de la Geforce 256 tenía 4 pixel pipelines, y corría a 120MHz. Como cada pipeline podía generar, como máximo, un pixel por ciclo:

(120MHz * 4) = 480 Mpíxels

---

---

COMO “JUEGA” UNA CONSOLA. Ahora contrastaré la forma de hacer esto mismo, pero según Sony lo concibió para su PS2, una máquina construida desde los cimientos para obtener un alto rendimiento en entornos 3D. Veamos por qué. Primeramente comentare la arquitectura básica de la consola. Su corazón es el Emotion Engine, un chip que integra la CPU, 3 coprocesadores, memorias caché, y diversos circuitos específicos, entre los cuales hay un controlador DMA, para gestionar todo el trafico de información que entra, sale, y se mueve dentro del Emotion Engine, siendo capaz de manejar 10 transferencias simultáneas, sin intervención de la CPU. Todos sus componentes están unidos por un bus de 128 bits, y algunos disponen de un bus dedicado.

El recuadro azul es el Emotion Engine, y muestra todos sus componentes.

Los 3 coprocesadores: el de coma flotante (FP) y las unidades vectoriales (VU0 y VU1).

El controlador de entrada/salida, que está en amarillo.

El bus principal de 128 bits está en gris.

Los buses dedicados están en naranja.

A parte del Emotion Engine, hay un sintetizador gráfico (violeta), que se encargará del renderizado, y la memoria RAM principal (gris claro). La memoria es de tipo RDRAM (Rambus) y trabaja a 800MHz. Tiene dos canales, y cada uno manda 2 bytes por ciclo de reloj, luego el ancho de banda que ofrece es: 2 * 2 * 800Mhz = 3,2Gb/s El bus interno del Emotion Engine es manejado por el controlador DMA. En total puede mover 2,4Gb/s, que no está nada mal.

---

1º Fase de aplicaciónIgual que en el caso del PC, el programa, que se ejecuta en la CPU (en este caso, el core), determina el tipo de procesamiento requerido, como la disposición del paisaje, el punto de vista, la posición de los objetos, la organización, etc. En esta fase se hace uso del core, la memoria RAM y el bus del sistema (para traer las instrucciones y los datos hasta la CPU). Por tanto un factor decisivo para agilizar esta fase será el ancho de banda del bus del sistema y la velocidad de la RAM y la CPU.

Ancho de banda de la memoria RAM	Caché Emotion Engine	Velolcidad Emotion Engine
3,2Gb/s (1,6Gb/s por canal)	40Kb ( instrucciones) 32Kb (datos) 16Kb (SPRAM)	300MHz

Para el ancho del banda de la RAM, se sabe que la memoria funciona a 800MHz, y es de tipo RDRAM con bus de 16 bits por cana. Cada canal puede mandar 16 bits por ciclo. Por tanto:

(800MHz * 16 * 2) / 8 = 3200Mb

Las cachés del EE son la suma de todas las cachés. La CPU dispone únicamente de 16kb para insturcciones y 8 kb para datos. La unidad vectorial VU0 8kb de cada, y la VU1 16kb de cada. La SPRAM es una memoria especial colocada entre la CPU y la VU0.

---

2ª Fase de transformación Para el cálculo de los vértices, y la generación de la lista de elementos a renderizar, el Emotion Engine cuenta con un poderoso hardware para operaciones en coma flotante, el VU0 y el VU1, las unidades vectoriales. Se llaman vectoriales porque operan sobre conjuntos de números, a los que aplica la misma operación, en lugar de hacerlo con 2 números simplemente. Así se consigue aumentar mucho el rendimiento. Cada unidad vectorial trabaja con 2 operándoos de 128 bits, donde se han empaquetado 4 números de 32 bits (4*32 = 128). El VU0 es capaz de realizar 4 multiplicaciones y 4 sumas cada ciclo de reloj, además de una división cada 7 ciclos. En total 2,45GFLOPS. El VU1 es igual que el VU0 pero “reforzado”, ya que puede realizar 5 multiplicaciones y 5 sumas, y 2 divisiones cada 7 ciclos. En total 3,05GFLOPS. Estas dos unidades vectoriales aportan 5,5GFLOPS de la capacidad total de la consola de 6,2GFLOPS. O sea el 88% de su rendimiento en coma flotante. Así que podría decirse que son uno de los corazones de la máquina. Lo que la Play 2 no tiene es mucha memoria. Pero recuerda lo que expliqué sobre las aplicaciones dinámicas, y el ejemplo de la fábrica (artículo anterior). Es precisamente lo que ocurre en la PS2; mucho ancho de banda, y poca memoria. Para extraer toda su potencia, no se puede programarla como se haría en cualquier PC. La estrategia es aprovechar sus puntos fuertes. En concreto, lo que los desarrolladores hacen es poner a trabajar las unidades de coma flotante, distribuidas por el Emotion Engine, trayendo de la memoria RAM los datos a toda velocidad, y volcando los resultados continuamente al Graphic Syntetizer, situado fuera del Emotion Engine. Es decir, la idea es mantener un flujo continuo y elevado de datos por todo el sistema, sin recaer en la necesidad de almacenar grandes cantidades de información. Así exprimimos su potencia. En cambio, si se hiciera un programa estático típico, con poca o ninguna necesidad de cálculos decimales, las unidades vectoriales no tendrían trabajo, y el Emotion Engine perdería muchísimo rendimiento. Y si encima nos apoyáramos en almacenar mucha información en la memoria, no aprovecharíamos el ancho de banda, y como disponemos de poca cantidad de memoria, sufriríamos unas penalizaciones terribles. Así que la PS2 exige que se la sepa programar. Y si se hace bien, da mucho de sí. Por tanto, la carga en la fase de transformación recae sobretodo en la potencia de los procesadores vectoriales, y el ancho de banda con la memoria y el sintetizador gráfico.

GFLOPS Emotion Engine	Ancho de banda total de memoria	Ancho de banda dentro del EE	Ancho de banda EE – GS	Caché EE
6,2GFLOPS	3,2Gb/s	2,4Gb/s	1,2Gb/s	40Kb ( instrucciones) 32Kb (datos) 16Kb (SPRAM)

El ancho de banda dentro del EE hace referencia a las transferencias gestionadas por el controlador DMA. Al funcionar este a 300MHz, y disponer de un bus de 128 bits, de alguna manera (que no tengo del todo claro aún) se limita la transferencia de la memoria a los dispositivos internos del EE a sólo 2,4Gb/s.

El ancho de banda del EE con el GS, es el del canal que une el GIF del EE con el GS. Además de esto, el GS puede acceder a la RAM a través del controlador DMA a 2,4Gb/s (aunque en ese caso no habría ancho de banda disponible para el EE).

---

3ª Fase de renderización. En la PS2 esta tarea se lleva a cabo en el Graphic Syntetizer. Tal y como he comentado en el anterior apartado, el Emotion Engine manda toda la información necesaria para construir la imagen.

El Emotion Engine es el recuadro grande en azul claro. En verde el Graphic Syntetizer, y en amarillo el procesador que comunica todo esto con el resto de la consola, y provee la retrocompatibilidad con la Playstation

El Graphic Syntetizer (GS) dispone de 4Mb de memoria de video integrada dentro del mismo chip. Esto quiere decir que es muy rápida. Y precisamente se apoya en esta velocidad, de nuevo, para suplantar la escasa memoria disponible. En ella habrá que mantener el frame-buffer, el Z-buffer y las texturas necesarias. Donde más problemas tendremos es en esto último, ya que a 640×480, los dos buffers ocupan la mitad de la memoria de video, y 2Mb para texturas es muy muy poquito, si se quiere usar a lo bruto, sin plantearse muy bien cómo. Hay que mandar continuamente datos al Graphic Syntetizer, y esto se hace por dos canales. Uno, desde el Emotion Engine (a través del GIF), y otro desde la memoria RAM (a través del DMAC). Pero no valen para lo mismo. Del EE recibe datos previamente calculados de la lista de gráficos que sintetizar, y de la memoria, texturas e información necesaria, que no está en el EE. La carga va a recaer en los buses que se usan para estas comunicaciones. Tenemos: 1,2Gb/s para mandar datos del EE al GS, un poco más rápido que el bus AGP del ordenador con el que lo estamos comparando. 2,4Gb/s para mandar datos de la RAM al GS, que es más del doble de la capacidad de este bus AGP. El otro ancho de banda importante a considerar, y es donde verdaderamente la Playstation 2 alcanza cotas elevadísimas, es la de la memoria de vídeo con el renderizador. Todo ello está integrado dentro del GS. El renderizador es como yo llamo a los circuitos que generan la imagen a partir de la lista de vértices, y como he dicho reside en el mismo chip que la memoria de video. Y esto no sólo permite que la comunicación sea más rápida, sino que además permite usar un conexionado más “ancho”. En concreto, el bus de la memoria de texturas es de 512 bits (que permite leer 64 bytes de una sola vez), y el de la memoria de buffer de 2048 bits (que permite mover 256 bytes de una tacada, que se dice pronto). Aunque en realidad la mitad de este bus se usa para leer de la memoria, y la otra para escribir. Y de aquí es donde Sony saca la cifra de 48Gb/s de ancho de banda de la memoria de vídeo. Hay que matizar esto. La frecuencia de reloj del Graphic syntetizer es de 150MHz aproximadamente. Ancho de banda de la memoria de texturas: 64 bytes * 150MHz = 9,6Gb/s Ancho de banda de la memoria de buffer: 256 bytes * 150MHz = 38,4Gb/s De los cuales 19,2Gb/s son para leer, y otros 19,2Gb/s para escribir. El ancho de banda total es monstruoso (38,4 + 9,6 = 48Gb/s), aunque la cifra oficial de Sony de 48Gb/s no explica el verdadero reparto, tal y como yo lo he hecho. No son 48Gb/s para lo que quieras. Para leer del frame-buffer 19,2Gb/s, para leer texturas 9,6Gb/s, etc. En cualquier caso, es muchísimo, cifras masivas para el año 1999. Pero esto no quiere decir que todo el acceso a texturas sea a 9,6Gb/s. Esa velocidad es para las texturas previamente almacenadas en esta memoria integrada, y que han debido ser traídas de la memoria RAM, por un canal de 2,4Gb/s. Así que la velocidad máxima sostenida será de 2,4Gb/s, hasta que se reutilizen las texturas que ya estén dentro del GS. Estos matices son importantes, leche. De momento me ahorro más matemáticas. Este ancho de banda permite alcanzar una tasa de relleno de 2400 millones de píxels por segundo sin texturas, o la mitad si se aplica una textura a los polígonos. Concluyo revisando las especificaciones clave, como de costumbre.

Ancho de banda Memoria – GS	Memoria video (integrada)	Ancho de banda de la memoria de video	Tasa de relleno
1,2Gb/s	4Mb	48Gb/s (con matices)	2400Mpíxels/s* 1200Mpíxels/s**

* Sin texturas.

** Con textura.

La tasa de relleno se calcula fácilmente teniendo en cuenta que el GS tiene 16 pixel pipelines, cada uno trabajando sobre un pixel por ciclo de reloj, a 150MHz aprox:

(150MHz * 16) = 2400Mpixels.

Como el GS no tiene TMUs (unidad de texturas, hablare de eso en el próximo artículo), se apoya en su masiva tasa de relleno de pixels, para dibujar las texturas. Realmente el GS es un chip peculiar. No tiene una esteructura estándar, ni se parece a las modernas GPU. Como veremos pronto, el resto de consolas dwe esta generación, así como las de la siguiente, y todas las tarjetas gráficas de ordenador, tienen un esquema similar de vertex/pixel shader, TMU y pixel pipelines y ROBs. todo ello se encarga de las fases de transformación y renderización, aliviando en gran medida a la CPU. El GS de la Playstation 2 sólo se encarga de la renderización. La transformación es tarea del EE.

---

---

EL MATIZ DE LOS 66 MILLONES DE POLIGONOSAntes de acabar, me gustaria explicar de donde sale la cifra oficial de Sony de que su playstation 2 mueve 66 millones por segundo, lo cual es mentira en un 99%. El cálculo mágico viene de la tasa de relleno de 2,4Gpíxels/s del GS. Sony supone que cada polígono es de 36 pixels, y divide la tasa de relleno bruta por 36, obteniendo 66 millones de polígonos por segundo. Vamos, 2400Mpixels / 36 = 66 millones. Claro, esto es para DIBUJARLOS. Pero para dibujarlos, hay que calcularlos previamente. Ligero matiz, ¿eh? Y la Playstation 2 no puede calcular tanta geometría con su capacidad de procesamiento. Hay que distingir las cifras teóricas como estas, de las prácticas, que se obtienen cuando un juego está corriendo y se mide de forma empírica los fotogramas por segundo, si va fluído o no, y los polígonos que mueve. Por ejemplo, a la cifra de Sony de 66 millones de polígonos por segundo, contrastamos la cifra que dio Nintendo para su Gamecube, de alrededor de 6 millones. Ésta última estaba basada en pura especulación, no en una manipulación de cifras. En la práctica, la máquina de Sony se mueve en torno a los 5 y 10 millones de polígonos, mientras que la Gamecube llega a superar los 10 millones. Pequeños matices, ¿no? De quedar completamente aplastada, a incluso superar a su rival. El problema es que Sony, que era más inteligentes que Nintendo en tema de marketing, sabían que la gente compararía las dos cifras, y diría que la Playstation era mucho más rápida. Claro, obviando toda la información que yo estoy exponiendo en estos artículos.

En la práctica, la Gamecube y la PS2 mueven más o menos los mismos polígonos. Aunque no sólo importa los que muevas, sino, al menos para mí, CÓMO los muevas. Muchos juegos de PS2 se mueven a trompicones. No van fluídos. A mí eso no me mola nada. Porque puestos así, la Gamecube seguramente podría mover 180 millones de polígonos… pero actualizando la imagen cada 10 segundos! Jejej. Sensación de velocidad total.

En serio, no te dejes engañar sólo por cifras. Como dijo Umberto Eco, la estadistica es esa ciencia por la que un hombre come 2 platos, y otro no come nada, y en realidad cada uno ha comido 1 plato. Ligeros matices. ¡Sobretodo para el que no comió nada!

---

EL MATIZ DE LA GPUEn este articulo he supuesto que el ordenador de prueba llevaba una tarjeta GeForce 256. Además, en los diagramas, he representado la tarjeta como una GPU y una RAM. Aunque hay más componentes, los principales, para entender el proceso, son estos. La RAM la usa la propia tarjeta de video para acceder a cierta información de manera mucho más rápida, de lo que podría hacerlo a la RAM principal de la placa base. El matiz que quiero acalarar, es que la GeForce 256 fue la primera GPU de la historia. GPU significa procesador gráfico, que es capaz de llevar a cabo tareas de transformación y renderización. Las anteriores tarjetas gráficas (Voodoo 1,2 y 3, TNT, Intel 740,…) sólo se encargaban de la renderización. Pero, en este articulo, he descrito el comportamiento de la tarjeta de video como renderizadora únicamente, es decir, no funcionando como una auténtica GPU. Una GPU hubiera aliviado la carga de la CPU muy notablemente en la fase de geometría, realizando casi la totalidad de los cálculos necesarios en la creación del entorno 3D. Para ello, la Geforce 256 usaba el motor T&L (transform and lightining), y hoy en día se usan vertex y pixel shaders.

---

VEREDICTO FINAL Bueno, está claro que ambos sistemas funcionan. Pero mientras un PC tiene que verselas con multitud de aplicaciones y entornos distintos, la consola estás diseñada para hacer precisamente lo que va a hacer. Y esto permite conseguir un sistema más compacto, y con mayor rendimiento por Mhz, por Mb, y por coste. Aunque no debémos olvidar que mientras el ciclo de vida de una consola puede considerarse de 5 años, los PC evolucionan mucho en ese tiempo. Un ordenador de ahora le pega patadas a cualquier consola de la generación PS2-NGC-XBOX. Lógico, son hardware del 1999-2000. Pero que a gusto se está sin ventanas de error, ni cuelges, ni incompatibilidad de tu nueva tarjeta gráfica con no se que cosa,… En fin, cada uno tendrá sus preferencias. Hay quien le gusta jugar en el PC, y se gasta entre 200 y 500 euros en una tarjeta gráfica periodicamente. Otros se gastan entre 150 y 300 euros por una consola, con la que juegan felices hasta el fin de sus dias. Yo opino que ambos sistemas, el ordenador, y la consola, son distintos, y sólo los he comprado aqui por motivos didacticos. No creo que uno pueda sustituir al otro. Y es más, creo que no debería ser así (aunque Sony parece querer acabar con esto con su PS3).

---

El proximo artículo se centrará en comparar a la Playstation 2 con el resto de sus competidoras, para analizar como Nintendo y Microsoft enfocaron sus respectivas máquinas, y las estrategias que adoptaron para alcanzar un elevado rendimiento. Hasta pronto!