Q:
Ya solo falta un mes para el lanzamiento de GameCube, y dejaron impresionado
a todo el público en el E3.
R: Gracias. Fue la primera vez que mostramos al público la consola.
Ya habíamos anunciado sus dimensiones, pero todos siguen sorprendidos
de lo pequeña que es cuando la vieron.
Q:
Desde luego. Yo también me llevé una sorpresa.
R: Sí. Yo también me quedé alucinado cuando vi
lo minúscula que era la placa final; me convenció de que
esta consola es realmente algo único.
Q:
¿Tuvieron decidido el diseño cuadrado desde el principio?
La placa también es redonda, además.
R: No. Barajamos unas cuantas ideas al inicio; había un diseño
más plano rondando. El nombre GameCube vino una vez decidimos
el diseño cuadrado. También hubo división de opiniones
sobre la asa, pero pensamos que las consolas normalmente se colocan
en estanterías, y se van moviendo de habitación en habitación
para ir jugando. Creo que la inclusión de la asa fue la decisión
correcta.
Q:
Ya que hablamos de ello, ¿sobre qué bases se comenzó
el desarrollo de GameCube?
R: Empezamos a examinar todos los problemas que hemos tenido trabajando
con Nintendo 64 desde su lanzamiento.
Q:
¿Que tipo de problemas?
R: Por ejemplo, con la Super Nintendo los limites del hardware se conocían
desde el principio. Sabias exactamente cuantos sprites podías
mostrar en pantalla al mismo tiempo, cuantos decorados podían
haber, y demás. Cuando el sistema te deja trabajar con 4 decorados,
entonces cualquier programa escrito por cualquier desarrollador puede
usar cuatro decorados al mismo tiempo. Cada programador se enfrenta
a las mismas limitaciones. Pero cuando los gráficos pasaron a
las 3D, las especificaciones de hardware cambiaron. Los programadores
podían hacer lo que quisieran siempre que pudieran procesarlo
lo suficientemente rápido, así que todo se dejaba en sus
manos.
Q:
Tenían más libertad para hacer lo que querían.
R: Exacto. Pero esto resultó contraproducente porque los limites
del hardware de una consola no estaban tan claros como antes. Los programadores
no tenían ni idea de la potencia que podían sacar del
sistema.
Q:
¿Por ejemplo?
R: Pues, por ejemplo, cuantos polígonos pueden ser mostrados
por frame, cuantos polígonos puedes usar por personaje, cuanto
tiempo puede ser dado a rutinas de IA sin afectar a la calidad de la
imagen... pensar en todo se hizo muy difícil. No podías
saberlo hasta que lo probaras tu mismo. Como resultado, había
que llevar a cabo un exhaustivo proceso de optimización, y eso
requiere tiempo y energía.
Q:
¿Cuánto cree usted?
R: Mi opinión es que el proceso de optimización, que no
tiene nada que ver con el juego en sí, se lleva alrededor del
40% del tiempo y el dinero de un equipo en el desarrollo. Al desarrollar
para Nintendo 64, el diseñador y el programador tenían
que pasar por un proceso de "trial and error", usando cada
herramienta posible para probar y conseguir mejores resultados del sistema.
Básicamente, el tiempo de desarrollo dedicado a asuntos no relacionados
con el juego explotó con Nintendo 64, y los desarrolladores no
podían trabajar como estaban acostumbrados. Eso empezó
a causar retrasos, y en el peor de los casos, algunos proyectos tuvieron
que ser cancelados. Nos dimos cuenta de que todo este trabajo inútil
seguía aumentando, y que de seguir así no habría
mucho futuro para la industria del videojuego.
Q:
Así que esa filosofía fue la base del diseño de
GameCube.
R: Así es. Hemos intentado hacer un sistema del que es fácil
sacar el mejor rendimiento posible sin optimización. Nuestra
primera meta en el desarrollo fue el olvidarnos de números y
especificaciones.
Q:
¿Números y especificaciones?
R: Creo que Nintendo 64 fue un sistema muy avanzado para su tiempo.
Podías hacer grandes cosas si usabas correctamente sus capacidades.
El problema radicaba en esa separación entre especificaciones
y rendimiento real. Incluso hoy día, las especificaciones en
sistemas 3D solo hablan de los polígonos que puedes poner y todos
los efectos que puedes usar. Pero una vez empiezas a desarrollar un
juego, es fácil acabar viendo cosas como una caída del
90% en el rendimiento del juego, o la mitad de polígonos con
efectos. Los números son siempre increíbles, pero muchos
de ellos son o imposibles o falsos. Con GameCube no estamos enfatizando
en especificaciones, estamos enfatizando en el rendimiento que puedes
ver realmente en el desarrollo de un juego.
Q:
¿De que forma?
R: Por ejemplo, una de mis peticiones sobre GameCube fue que tuviera
una CPU 10 veces más rápida y un procesamiento gráfico
100 veces más rápido que Nintendo 64. Creí que
era lo mínimo que necesitaba para hacer software que fuera más
allá de la última generación. Si te fijas en las
especificaciones del hard de GameCube, la CPU no es 10 veces más
rápida, ni los gráficos son 100 veces más rápidos...
pero en rendimiento real, el sistema ofrece todo lo que yo pedí.
Q:
Pero al mismo tiempo, no han estado publicitando demasiado las capacidades
de GameCube.
R: Hay un motivo para eso. Los diseñadores de Gamecube tuvieron
éxito en ir más allá, y sé que están
todos verdaderamente satisfechos con su trabajo, pero al mismo tiempo,
ellos saben que Nintendo es, al mismo tiempo, un productor de Hardware
y el mayor productor de software del mundo. Saben que los consumidores
compran consolas por sus juegos, no porque su hardware sea avanzado.
Ese es el motivo por el que no hemos hablado demasiado sobre el hard.
Si recuerda bien, Genyo Takeda, el director del hardware de Gamecube,
dijo en el pasado E3 que "Primero son los juegos, el hardware va
después".
Q:
¿Que les hizo decidirse por usar una CPU de IBM y un chip gráfico
de ATI para GameCube?
R: Takeda y su equipo de hardware los escogieron después de pasarse
bastante tiempo investigando la tecnología mundial y deliberando
sobre el equilibrio entre coste y rendimiento. No hay otros motivos
de política.
Q:
¿Cómo esta construido el sistema?
R: El diseño básico es muy sencillo. Lo puedes dividir
en 3 partes: Gekko, la CPU PowerPC de IBM; Flipper, el chip gráfico
de ATI; y Splash, un set de 24 MB de memoria principal. Gekko es un
chip PowerPC750/G3 básico con una unidad vectorial, un chip gráfico
especializado y una gran caché de nivel 2 de 256K. Se pueden
ver grandes cachés de nivel 2 en los iMac y iBook, pero el diseño
que acordamos con IBM fue concebido antes de que esos ordenadores fueran
lanzados.
Q:
Es un diseño único.
R: Sí que lo es. Realmente necesitamos más caché
en los días de Nintendo 64, por eso la pedimos tanto. El equilibrio
entre la CPU y la memoria de sistema era inexistente; cuanto más
rápido iba el procesador, más encogía la memoria
de acceso. Por eso necesitamos mucha caché con un procesador
como el Gekko.
Q:
¿Cómo se compara el Gekko con el procesador de N64?
R: Sobre 4.5 veces más rápido. El de Nintendo 64 va a
93,75 MHz, y el de GameCube va a 485 MHz. Pero gracias a la gran caché
que tiene, la velocidad real de proceso es como mínimo 10 veces
más rápida.
Q:
¿Que tiene de especial el Flipper?
R: Flipper contiene la tecnología gráfica, alguna DRAM
incluida, un DSP de audio, y unas cuantas "interface features",
todo en uno. Es el corazón del sistema, con Gekko y Splash a
cada lado. Splash y Flipper fueron llamados para recrear la imagen de
un delfín, y Gekko significa luz de luna. Si puedes imaginarte
la luna, y luego un delfín salpicando bajo ella, te será
fácil recordar el diseño principal del sistema.
Q:
Un delfín salpicando bajo la luz de la luna.
R: Así es. Otro asunto prioritario era el acceso a memoria. Podrías
decir que el diseño de GameCube se parece al de PS2 en conjunto,
aunque, en vez de ofrecer acceso DMA entre la CPU y la memoria principal,
GameCube conecta la memoria directamente al chip gráfico.
Q:
¿Cuál es la idea detrás de la conexión directa
de la memoria con el chip gráfico?
R: Nintendo se dio cuenta de que la incorporación de una mayor
caché a la CPU reduciría el número de accesos a
memoria que requiere el chip gráfico. También queríamos
hacerlo todo para reducir la carga que sufre la CPU por culpa de los
gráficos.
Q:
¿Que resultados se obtienen de esa forma?
R: Bueno, para explicarlo de la manera más sencilla, el mayor
problema son las texturas, o imágenes 2D que recubren los polígonos.
Estas texturas normalmente deben estar en el chip gráfico para
ser mostradas. Todas las consolas, incluyendo la Nintendo 64, funcionan
así. El problema está en que la memoria de video normalmente
es muy pequeña. La Nintendo 64 tenia solo 4 KB, y hasta GameCube
tiene solo 1 MB. Por eso,, las operaciones de un juego que requieran
cambios frecuentes de texturas en la memoria de video no pueden ser
procesadas suficientemente rápido. En Nintendo 64 tenias que
llamar a la CPU para que leyera las texturas de la memoria de video,
pero el chip gráfico de GameCube puede acceder a las texturas
directamente de la memoria principal sin molestar a la CPU. Es algo
así como una memoria de textura virtual. Gracias a esa memoria
GameCube puede manejar montones de texturas fácilmente sin ninguna
bajada de rendimiento.
Q:
¿Una memoria de texturas virtual?
R: Sí. Esta memoria fue una de las primeras cosas que introdujimos
durante el desarrollo, ya que fue la mayor queja de los desarrolladores
de N64. Fue bastante difícil de solucionar técnicamente.
Q:
¿Es por esa memoria que es tan fácil trabajar con GameCube?
R: Es uno de los motivos principales. Aun así, hacer software
más fácil de crear no es un problema de encontrar un problema
y solucionarlo, sino pasar por cada obstáculo principal y aplastarlos
todos, uno por uno. Si no prestáramos atención a todo
seguiría habiendo pequeños detalles que harían
las cosas más difíciles. Hemos trabajado muy duro para
arreglar todos los problemas por ahora. Diría que el problema
de las texturas era el número 2 ó 3 de nuestra lista.
Q:
Había otras cuestiones que tratar.
R: Así es. Aunque los problemas de memoria fueron prioritarios.
Q:
Como, por ejemplo, como la memoria principal transmite las texturas
por si misma, pero el Flipper también tiene memoria integrada.
R: Estas hablando de video RAM. La PS2 usa DRAM en el chip gráfico
también. La tendencia en tecnología de chips hoy día
es incorporar un bus de conexión entre procesador y memoria integrada
amplísimo; esto permite procesamiento paralelo de los datos y
soluciona cuellos de botella relacionados con la memoria. Poner RAM
en el chip es la mejor manera de conseguir esta masiva conexión
en paralelo.
Q:
¿Así que la estructura de memoria de video de GameCube
se parece a la de PS2?
R: Comparte algunos aspectos con la PS2, pero nosotros lo hacemos de
una manera totalmente distinta, así que el diseño no es
tan similar.
Q:
¿Cuales son esas diferencias?
R: Bueno, en términos generales, la principal diferencia entre
GameCube y PS2 es que durante el desarrollo nos centramos exclusivamente
en las características necesarias para los juegos. El concepto
de PS2 es dejar a los programadores hacer todo lo que sean capaces de
conseguir; el nuestro es ofrecer alto rendimiento, fácil desarrollo
y la habilidad de concentrarse en materias más creativas. Sabemos
por propia experiencia que tipo de plataforma necesitamos, y hemos incluido
memoria de video integrada y procesamiento paralelo solo porque creímos
que era lo que los juegos requerían. Creo que es una visión
radicalmente distinta a la de PS2.
Q:
¿La memoria principal también esta diseñada para
agilizar el acceso a memoria?
R: Splash, la memoria principal de la GCN, usa 1T-SRAM de MoSys. Es
un chip muy especializado.
Q:
¿1T-SRAM?
R: Es SRAM de un solo transistor. La latencia de memoria (el tiempo
entre la petición de memoria y la recepción de datos)
se ha convertido en uno de los mayores cuellos de botella en procesamiento
de datos, y 1T-SRAM lo soluciona. Reúne bajo coste y baja latencia
al mismo tiempo.
Q:
¿Qué les hizo decidirse por esa memoria?
R: Fue una de tantas tecnologías que Genyo Takeda encontró
después de buscarla. Creo que la RDRAM de Rambus fue usada por
primera vez de forma industrial por Takeda en la Nintendo 64. Después
de estudiar la N64 y valorar el tipo de memoria más adecuado
para una consola de videojuegos elegimos 1T-SRAM.
Q:
¿En que es mejor para una consola la 1T-SRAM?
R: Hay una gran diferencia entre el tiempo de acceso aleatorio entre
RDRAM y 1T-SRAM. La cualidad más distintiva de la RDRAM es que
el primer acceso es muy latente, pero si lees muchos datos al mismo
tiempo, la latencia disminuye. El problema es que los juegos acceden
a memoria de forma muy volátil, leyendo pequeños fragmentos
de aquí y de allá. Los meritos de la RDRAM no van dirigidos
hacia ese tipo de uso. La demora típica para acceder a memoria
es de unos pocos nanosegundos, y en un procesador a 480MHz y un chip
gráfico a 160MHz eso son docenas de ciclos desperdiciados.
Q:
Así que la latencia puede reducir el rendimiento de una consola.
R: Exacto. Los buses de los procesadores han experimentado increíbles
avances, y los chips van cada vez más y más rápido,
así que ahora el factor determinante que dicta lo rápido
que corre la máquina es la memoria. Con 1T-SRAM se usa SRAM,
que es mucho más rápida generalmente. Es unas 10 veces
más rápida que DRAM, así que el procesador solo
ha de esperar una décima parte del tiempo... o, realmente, nada
de nada. 1T-SRAM es absolutamente perfecta para consolas. Casi podrías
decir que GameCube no tiene ninguna memoria principal, sino que tiene
una inmensa caché de nivel 3.
Q:
¿Toda la memoria es una caché?
R: Así es. La memoria del Flipper también es 1T-SRAM,
para hacer que la memoria vaya lo más rápido posible.
Los juegos acceden a la RAM para texturas todo el tiempo, así
que eso nos da una gran ventaja respecto a la DRAM usada en la PS2.
La verdad es que la 1T-SRAM es probablemente la parte más distintiva
de la GameCube.
Q:
También hay algo llamado A-Memory en la tabla de especificaciones.
R: Eso es la abreviatura de memoria auxiliar; es una DRAM clásica.
No pudimos usar más de 24MB de 1T-SRAM por problemas de placa,
así que pusimos esta RAM extra para una especia de almacenamiento
temporal. Solíamos llamarla "memoria de audio" pero
entonces los tíos de sonido la querrían toda para ellos,
así que ahora lo cambiamos por A-Memory (risas).
Q:
Para que tipo de cosas podría usarse la A-Memory.
R: Un sample de buffer, un buffer de animación, caché
de disco; cualquier cosa.
Q:
Habéis dedicado mucho trabajo a la RAM.
R: Sí, y estamos sacándole partido. Sobretodo en los gráficos.
Si no fuera por 1T-SRAM nunca podríamos haber probado la idea
de la RAM de texturas virtual. Tendríamos que usar texturas sin
ningún tipo de arreglo, la velocidad hubiera caído en
picado, y la maquina en sí hubiera sido más lenta. No
podríamos haberlo intentado sin estos chips de alta velocidad
y baja latencia. Gracias a eso, puedes conseguir un rendimiento fabuloso
sin dedicar tanto tiempo a la optimización. Hace mucho más
eficiente el desarrollo.
Q:
¿Practicáis algún tipo de compresión de
texturas?
R: Desde luego. GameCube es cien veces mejor en gráficos que
N64, pero solo tiene 6 veces más memoria. Necesitamos hacer algo
sobre esto, o sino todo ese rendimiento no podría haber sido
aprovechable. Usamos S3TC (Tecnología de compresión S3)
para comprimir texturas, además de alguna compresión de
texturas por vectores.
Q:
¿Que es lo que hace?
R: La tecnología S3TC te permite comprimir una imagen a todo
color a cuatro bits por punto. Es la misma tecnología usada en
DirectX. Básicamente la comprime al 25% de su tamaño original.
Hay gente que dice el 16%, pero creo que 25% es mas preciso.
Q:
¿Y que hay de esa compresión por vectores?
R: Los modelos vectoriales en 3D normalmente se almacenan en RAM como
números decimales en coma flotante de 32 bits, pero GameCube
también puede guardarlos en formas enteras de 8 y 16 bits. Usando
compresión vectorial, puedes convertir esos números de
8 y 16 bits a 32 bits automáticamente. Es genial para conservación
de memoria cuando todo lo que necesitas es precisión de 8 o 16
bits, y teniendo menos datos que tratar acelera las operaciones de memoria.
Hay otras ventajas, pero estas son las principales. Básicamente
hemos estado intentado hacer todo lo posible por compactar los datos
y reducir carga a la memoria lo máximo posible.
Q:
¿Y esta compresión vectorial ha sido desarrollada por
la misma Nintendo?
R: Creo que sí. No he oído de ella en otro lugar.
Q:
Cuando Shigeru Miyamoto fue preguntado acerca del desarrollo para GameCube,
dijo que el coste de desarrollar para GCN era diez veces menor que para
N64. ¿Cómo habéis reducido tanto los costes?
R: Bueno, eso es solo que el precio del hardware se redujo esa cantidad.
Cuando Nintendo 64 fue desarrollada, el kit básico de desarrollo
incluía una estación Silicon Graphics. Y, obviamente,
esas estaciones cuestan mucho dinero, y para algunas compañías
fue una barrera impenetrable que no les permitía desarrollar
para N64. Con GameCube, en cambio, un PC corriente es lo bastante bueno
para el desarrollo.
Q:
¿Un Pentium III a 1GHz bastaría?
R: No necesitarías ni eso.
Q:
¿Pensaban en introducir nuevos talentos en la industria al hacer
las herramientas de desarrollo tan asequibles?
R: Bueno, la industria del videojuego en general no tiene un rendimiento
como el de antaño, así que queríamos un sistema
que opusiera los mínimos obstáculos posibles al desarrollo
y que requiriera de poco esfuerzo. Queremos que los creadores vuelvan
al corazón del desarrollo. La idea es que las casas de software
recuperen todo el tiempo malgastado en desarrollo y lo usen en hacer
cosas divertidas para los usuarios.
Q:
¿Que tipo de middleware tienen?
R: Tenemos lo básico, librerías para dibujar gráficos
3D y para leer el mando. También estamos empezando a apoyar a
las third parties con otro middleware. No creo que sea como para decir
que sin middleware no puedes hacer juegos, y también creo que
algunos de los problemas que se arreglan con middleware se arreglan
mejor de otras formas. Como la memoria de texturas y la reducción
de latencia, por ejemplo.
Q:
Hemos oído multitud de cosas sobre lo difícil que es aprender
el middleware de PS2, y como solo las mejores casas de software saben
usarlo. Con GameCube, parece que ocurre lo contrario.
R: Hablando del tema, creo que hay que mencionar que la versión
GameCube de Phantasy Star Online que visteis en el E3 se tardó
un solo mes en hacer desde cero. Eso debería deciros algo sobre
las habilidades de la consola. Pero al mismo tiempo, no es que diseñáramos
la consola para ser fácil de trabajar con ella solo porque hacerlo
con PS2 sea difícil. Hemos estado pensando durante 3 años
como debería ser nuestro nuevo sistema, y nuestra solución
para los problemas que hoy tiene la industria resultaron ser "una
consola más simple". Solo eso nos mereció muchos
halagos en el E3. No se ha vendido una sola GameCube y muchas compañías
están interesadas en la consola, lo que prueba porqué
escogimos simplicidad al final. No creo que veamos una escasez de títulos
como N64 vio.
Q:
¿Así que no hay ningún kit de desarrollo propio?
R: No. Hay una consola test para probar software, pero solo es una versión
con ligeras diferencias con la consola de mercado. No puedes usarla
para programar.
Q:
¿Cuantas GameCubes planean vender para final de año?
R: Nintendo no tiene ninguna meta particular por ahora, pero el plan
oficial es de 4 millones de consolas. Nuestras fábricas están
montando todas las que materialmente pueden.
Q:
¿Eso es para Japón solamente?
R: Japón y América. Años ha cuando estábamos
diseñando las consolas de 8 bits teníamos que usar tecnología
anticuada incluso para entonces, pero ahora estamos creando chips gráficos
considerados entre los mejores del mundo; estamos trabajando con lo
último de la tecnología informática. Por eso no
es tan simple tener sistemas listos para el lanzamiento como antes.
Desearía enormemente poder tener más preparadas. 4 millones
de consolas son muchas, pero predigo que habrá incluso más
demanda, así que espero que podamos ser capaces de producir muchas
más rápidamente.