EMaDeLoC escribió:Exacto. Tiene memorias dedicadas para framebuffer, z-buffer y la caché de texturas es inmensa.
Aunque las quejas por los 4KB de caché de texturas de la N64 son bastante artificiales, tiene el doble que PS1.
También tiene sus miserias, y de verdad que son muy miserables. Principalmente (para mi), son dos:
1) Una textura de 8 bits pesará siempre lo mismo que una textura de 24 bits... y no puedes hacer que todas las texturas de un juego sean de 24 bits porque no cabrían en aquellos mini discos.
¿Que significa esto?, que resident evil 4 podría haber tenido todavía mejores texturas, GRATIS en términos de rendimiento. Eso nos lo hemos perdido por no ver el juego dividido en 4 mini dvd's.
2) La siguiente pega que le veo es la enorme diferencia entre los polígonos que es capaz de calcular, y los que el rasterizador es capaz de dibujar. Para ser un hardware tan equilibrado y eficiente, esa parte de su pipeline es un descuído inaceptable.
Esto es a groso modo lo mas gordo que se le puede achacar a la máquina. Luego hubiese estado muy bien que incluyese las instrucciones altivec, o que se potenciase el uso de la caché de la cpu para emplear "custom shaders" en lugar de esas "fixed shaders"... que es algo que se puede hacer ya de por si (por ejemplo los famosos pixel shaders), pero me refiero a mayor escala, y sin lags.
Ya puestos, 32MB de RAM en lugar de 24MB hubiese estado genial, pero bueno.
EMaDeLoC escribió:Tener la RAM en paralelo en vez de en serie no significaría una mejora sustancial de velocidad en los paquetes pequeños, pero si en los grandes.
Pero lo interesante habría sido que tuviese dos buses independientes para cada chip de RAM, de forma que el RCP pudiese leer en uno y escribir en otro. De esta forma mientras dibuja los polígonos podría leer y escribir el z-buffer por un lado y escribir el framebuffer por el otro, sin necesidad de turnar las operaciones. Habría eliminado uno de los cuellos de botella más importantes de la máquina como es el uso del z-buffer.
Aún así yo creo que habría sido mejor los 8MB directamente de salida. El coste de fabricación sería mayor, pero se habrían ahorrado el conector, el jumper pak (que debía costar su aquel), la complejidad de la carcasa con el acceso del jumper pak y la tapita, aparte de diseñar un expansion pak.
Si las desarrrolladoras en vez de estar experimentando con los 8MB y el triple buffer desde el año 98-99 lo hubiesen hecho desde el 96 y sabiendo que todas la consolas lo tendrían, para el año 99 habrían podido salir algunas maravillas muy interesantes.
Y bueno, si Nintendo no hubiese sido tan cabezona en que por huevos había que usar el z-buffer, los juegos tendrían mejor rendimiento.
De todas formas hablamos de la era de inicio del 3D, ni los más expertos programadores sabian manejar algunas cosas.
Lo del doble bus y dos memorias para la ram pensaba que vendría bien para que la cpu y el rcp pudiesen trabajar en paralelo de forma real, no pensaba que solo el rcp podría trabajar sobre ambas memorias al mismo tiempo... o igual he entendido mal.
Pero vamos, que la lacra de trabajar peor con paquetes pequeños hubiera tenido un impacto menor si al mismo tiempo estás haciendo otras tareas en la otra memoria, porque la lentitud de la otra tarea no te obliga a esperar para lo que YA estás haciendo.
Pero es lo de siempre... doble bus y dos memorias... ¿bajo que coste?.
En la snes al menos hubiese tenido un sentido. El spc700 solo puede usar el bus para leer samples de la rom durante un breve espacio de tiempo, y si hubiese tenido su propio bus (ya que el spc700 sustituye al DMA), para leer de la rom, lo podría hacer durante todo el frame, en lugar de durante solo una breve parte de el, y así no habría forma de exceder el ancho de banda incluso aunque transfieras 8 samples con la máxima calidad, y la mínima compresión.
Pero no lo hicieron así. Conectaron físicamente dos patillas de la ROM directamente al DSP (gracias a lo cual inventos como el MSU1 son posibles), pero no al SPC700, cosa que habría permitido tener las dos opciones:
-Leer de la rom solo durante un mínimo espacio de tiempo reservado, o en su defecto durante mas tiempo siempre y cuando el DMA no esté accediendo a la ROM.
-O dividir la ROM en dos memorias (gráficos y programa en una, y sonido en otra), y tener todo el tiempo que dura cada frame para leer de la misma independientemente de lo que haga el DMA.