Señor Ventura escribió:Básicamente, lo peor de la n64 es el ancho del bus de la memoria, el rebaje que sufrió la cpu y el rcp, y por lo que comentáis, parece que además configuraron el rcp para que gestionarse mal los accesos a la memoria. Luego está la caché de 4KB, y a lo mejor alguna que otra cosa por ahí que se me escape.
Eeeeeepa!!! Para el carro que te has emocionado...
Por partes.
El problema no es el ancho del bus de la memoria, sino la latencia al realizar operaciones con esta. El ancho es altísimo si solicitas un bloque grande de datos que se acercan a los conocidos 562MB/s. Pero ese dato no tiene en cuenta el problema de que si haces una operación con apenas un par de bytes el RCP se queda más tiempo esperando que recibiendo datos. Por ejemplo si se pide un solo byte la velocidad de transmisión contando la latencia baja a 33'3MB/s que es claramente insuficiente. Por suerte eso es el caso extremo y la velocidad mínima, a efectos reales podríamos hablar de entre 200 y 300MB/s dependiendo del juego y la cantidad de triángulos que se dibujen.
En cuanto a que se configurase el RCP para que gestionase mal los accesos a memoria eso es un cuento sin ningún fundamento de Urian . Su única "prueba" son las declaraciones de un mandamás de RARE sobre un testeo que hizo en hardware muy tempranero. Pero es que en esa declaración no dice en ningún momento que SGi saboteara la consola, solo dice que hizo una prueba que tenía mal rendimiento, que solventaron el problema y el rendimiento mejoró. Punto. No sé cómo se saca Urian que eso es una prueba de sabotaje de SGi. Pero es que además esa declaración es algo inverosimil ya que dice que creó un código que la propia SGi revisó por si estaba mal o poco optimizado pero no lo estaba. ¿
Perdona? ¿Me estás diciendo que a la primera creaste un código bien optimizado para un prototipo de procesador que no habías tocado nunca?
La cache fue de 4KB porque al estar embebida en el RCP es carísimo aumentarla y además no había espacio en un muy apretado RCP. En la imagen es la parte llamada TMEM (ese es su nombre real). Vease como el monstruo del RDP ocupa casi medio chip.
Señor Ventura escribió:¿Cuanta potencia diríais que se podría estar perdiendo?.
Por motivo de latencia de la RAM se pierde bastante, pero una cifra estimada es muy difícil de dar. El World Driver Championship es posiblemente el juego con más polígonos y mayor trucos de código para optener el mejor rendimiento y alcanza los 100-120 mil polígonos por segundo a 30fps estables. Sobretodo le ayuda mucho el que no usa z-buffer y por tanto el número de accesos a memoria por triángulo dibujado baja considerablemente. Así que para hacerse una idea va muy bien.
Conker64 le dedicó una entrada fascinante en el hilo de curiosidades de la N64:
https://www.elotrolado.net/hilo_hilo-de-detalles-y-curiosidades-de-n64_2171497_s250#p1743683038Échale un ojo al hilo porque hay muchos detalles técnicos de la consola que se aclaran ahí.
Señor Ventura escribió:En el mejor de los escenarios posibles, si todo el proceso de planificación del hardware hubiese optado por la solución más optimizada, ¿a que hardware se habría asemejado en cuanto a gráficos, placas árcade y gráficas de pc incluídas?.
Te gustan las preguntas difíciles y polémicas, ¿eh pillín?
Estoy de acuerdo con Urian y dos chips RAMBUS en paralelo para tener un bus de 18bits habría sido buena solución. Sigue sin arreglar el problema de la latencia, pero la velocidad mínima que he dicho antes ya sube a 66'6MB/s. Eso no significa el doble de mejora efectiva, porque se tarda lo mismo para leer dos bytes tanto si es 9bits como 18bits de ancho de banda debido a que la RAMBUS puede transmitir dos bytes por ciclo de reloj y para leer dos bytes tardas los mismos ciclos con cualquiera de los dos buses. Lo cual significa que si el número de operaciones no baja siga habiendo el problema de la latencia, pero esta se compensa un poco al terminar la transferencia de datos antes cuando son bloques grandes. Al final no sería el doble de mejora, pero de los 200-300MB/s que hablaba antes se pasaría a los 250-400MB/s, que ya se notaría mucho. Como curiosidad la transferencia máxima teórica habría subido a mas de 1GB/s.
![[Alaa!]](/images/smilies/nuevos/sorprendido_ani2.gif "Ala!")
Con esa parte algo arreglada podríamos ver el límite real del RCP. Sabemos que tranquilamente texturiza 100.000 polígonos por segundo sin z-buffer, pero habría que ver cuanto le lastra realizar la comparación de z-buffer pero posiblemente no sea mucho. Sabiendo que es capaz de manejar 60.000 pol/s con z-buffer activo, tal vez con la mejora de memoria alcanzase los 70.000 en las mismas condiciones. Una pista extra que tenemos son los juegos en alta resolución de la N64 donde los fps bajan a 12 en muchos, pero desde el punto vista del uso de la RAM, hay más accesos a memoria pero también se manejan bloques más grandes, por lo que la relación es más favorable que en resolución normal. Es decir, se esta aprovechando más el RCP en alta resolución que en resolución normal y se puede ver que aunque se doblase el ancho de banda, por el límite con el RCP la mejora no habría sido mucho mejor.
Se seguiría pudiendo expandir la RAM, aunque el expansion pak seria el doble de gordo y la ranura más grande y también más cara.
Pero el problema habría sido el RCP, es un chip gigantesco atestado de líneas y meterle las 15 o 16 líneas extra de un chip RAM paralelo habría aumentado su tamaño más, su coste de fabricación y el coste de la placa base. ¿Cuanto más? Pues puede que bastante, quizá 40$ más. Si, ahora con lo que sabemos pagariamos sin dudarlo eso 40$ extra, pero en aquel entonces ni nosotros sabiamos, ni nuestros padres habrían apoquinado 40.000 pesetas por una consola...
En el momento de salir la N64 el RCP estaba muy a la par o casi superando a las aceleradoras 3D de PC. Claro que esto es por los pelos ya que faltaba un mes para la salida de la primera Voodoo que se merendaba todo lo que había. Las placas arcade tenian una potencia bastante bruta. Así que aún con la optimización de memoria la consola estaría por debajo de arcades y PCs con Voodoo, aunque la relación prestaciones/precio habría sido imbatible pese a ser más cara, y tendría algo más de resolución (y con esto me refiero a menos bandas negras arriba y abajo) y mejor framerate.
Igual parece que me he venido arriba con la comparación con las gráficas de PC, pero si buscais vídeos de la primera S3 ViRGE vereis que el rendimiento es bastante lamentable. De hecho se le apoda deceleradora 3D porque era activarla e ir el juego más lento.
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
Urian escribió:Lo que es un sinsentido es que existiendo la corrección de perspectiva que permite utilizar poligonos con un area relativamente grande tengamos solo 4KB como cache de texturas, que vale que es el doble que la PlayStation pero el sistema de Sony utiliza texturizado afín, sin corrección de perspectiva y por tanto compone la escena con polígonos de area más pequeña.
Es por ello que la comparación de poligonos por segundo entre ambos sistemas es absurda. N64 puede mover las mismas texturas que PSX sin problemas, además con Mip Maps de cada una pero va a ir peor pq la tasa de poligonos es peor pero eso si haces un port directo, si adaptas la geometria entonces... Pero si tu juego requiere grandes texturas en N64 tendras un problema por los 4KB de cache, por lo que tendrás que subdivivir en texturas más pequeñas y por tanto aumentar la tasa de poligonos.
Es curioso que digas que la N64 tiene el doble de cache y que por eso es un problema para realizar port de juegos de PS1 que tiene la mitad de cache...
La realidad es que en los juegos pocas texturas se estiran. Se daba sobretodo en suelos, paredes y cielos, y dependiendo del detalle necesario. Por ejemplo no es lo mismo el cesped de Mario 64 que el suelo del castillo.
(Son capturas de emulador, pero es para hacerse una idea.)
Al final aunque la N64 se lleve la fama de las texturas de baja resolución, la realidad es que en general no eran muy diferentes en tamaño entre ambas consolas. Vease ese cartel en Gran Turismo.
(De nuevo emulador, y subido de resolución y con filtros, pero para que se vea que tiene sus píxeles).
Pero vamos, la resolución de texturas es la correcta para resoluciones habituales de 320x240 en televisores CRT. A ver si ahora vamos a juzgarlas 25 años después....
Creo que necesitas pasarte por el hilo de curiosidades de la N64 y verte las comparativas que hace Conker64 entre juegos de N64 y PS1.
Lo que has dicho lo comparo con los datos del WDC que he dicho antes y tu afirmación de que la tasa de polígonos es peor. En las mismas condiciones, es decir, sin usar z-buffer, ambas máquinas se mueven en una tasa de polígonos texturizados similar, o incluso la N64 tiene cierta ventaja. Pero además la consola de Nintendo aplica filtros y precisión subpixel consiguiendo una calidad gráfica final superior (desastre de salida de vídeo aparte) a la consola de Sony.
Pero incluso con z-buffer la tasa de polígonos no es mala. El Ridge Racer de N64 tiene aproximadamente la misma tasa que la del primer Ridge Racer de PS1. Digo yo que si es aceptable en PS1, lo será en N64 también...
Otra cosa distinta es que los problemas para optimizar el juego provoquen una tasa de fps inferior en la consola de Nintendo, pero eso es problema de software, no de hardware. Luego también entra la política de Nintendo de que los juegos debian usar z-buffer para que se vieran mejor que en PS1, unido a que en las librerias de la consola o usabas z-buffer y corrección de perspectiva, o no usabas ninguno. Solo experimentos contados con microcódigos a medida como el de WDC y varios juegos más de Rare aprovechaban mejor el potencial de la consola.
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
![[plas]](/images/smilies/aplauso.gif "Aplausos")
