Hilo de detalles y curiosidades de N64

EMaDeLoC escribió:

Misscelan escribió:El antialiasing no depende tampoco del microcódigo, no estoy muy seguro de cuanto estaba capado en el SDK oficial (ese lo use muy poco hace mucho) pero en Libdragon puedes activar el interno (RDP) o el externo (VI) a tu antojo. Si no recuerdo mal Perfect Dark lo desactivaba en algunas ventanas con luz de edificios para que fuesen más definidas.

Creo que te confundes con el filtro bilineal, que es el que suaviza las texturas y el que está desactivado para las texturas de edificios, para así simular ventanas con la luz encendida. Si el filtro estuviese activado, serian borrones.
El antialiasing es lo que suaviza los bordes de los polígonos.

Sexy MotherFucker escribió:Si no recuerdo mal Quake también te dejaba desactivar el AA en las opciones, aunque si te digo la verdad no recuerdo no recuerdo que influyese directamente en el rendimiento, si bien sí en la nitidez del entorno.

No recuerdas mal, pero el filtro que desactiva es el dedithering. La consola tiene dithering como la PS1, pero como la N64 usa más colores es algo menos notable. Pero para que no se notara del todo, aplica un dedithering después que basicamente es emborronar la imagen menos en los bordes de los polígonos. También evita los moaré de algunas texturas lejanas. Es el que más emborrona la imagen de todos y practicamente todos los juegos lo tienen activo. Si no estuviese o al menos se pudiera desactivar como en el Quake, la consola no tendría tanta fama de borrosa.


Hablando de borrosidades, Kaze Emunar habla de todos los filtros que emborronan la imagen. Lo dejo con la parte que empieza a hablar de dedithering, pero recomiendo verlo entero:

Sobre esto, tengo que decir que ahora que la tengo con RGB y he probado los parches para quitar el AA, prefiero jugar con el AA activado, sin el se nota todo muy "crujiente" me recuerda a Saturn que una textura de tierra por ejemplo ves perfectamente que está formado por montones de pixeles de diferentes tonos rollo cruchet. El problema es que creo que para lanzar la consola con video compuesto sobraba ese AA es una borrosidad excesiva, lo mismo pasa con Saturn que conste, mi opinión de antes es por RGB y estoy seguro que por vídeo compuesto no se notará o no tanto.

Con PS1 también me pasa lo mismo, el RGB en su 2D me la pone dura, pero en 3D nunca termino de estar contento entre elegir dithering notorio o borrosidad con menos dithering. O sea, prefiero en general el RGB porque cuando mis CRT mueran será la mejor opción sin duda, pero teniendo CRT creo que en estas primeras máquinas 3D hemos magnificado el RGB demasiado en sus juegos 3D. N64 al tener la posibilidad de elegir AA o no, hoy en día se salvaría, pero en la época creo que fue un error.



@Sexy MotherFucker me cuesta entender lo que dices porque el GTE es codependiente y el RCP es independiente? Con el RCP y nada más podrías mover un juego en N64 sin pasar por CPU y en el GTE no? Me refiero a un juego ramplón, rollo un pong mismamente, no a los mismos juegos del sistema.

@SuperPadLand hoy en día en Ps5 está la CPU que hace sus cosas, y luego la GPU que hace otras entre ellas toda la transformación de las 3D sin estorbarse.

Nintendo 64 ya hacía eso en 1996, a un nivel mucho más primitivo, si así se quería. Por supuesto el programador podía optar por apoyarse en la CPU y/o FPU de ésta para las transformaciones, pero ya no era obligatorio. N64 tenía un "Reality Co-Procesor" independiente que podía gestionar toda la fase de transformación por si mismo, sin ayudas externas. Y nada de juegos ramplones, podrías un juego 3D como Dios manda si te lo curras.

En PlayStation, y en el Pentium de tu padre de los 90, los cálculos se hacen a través de sus coprocesadores de apoyo en/al "lado" de la CPU, y luego a través de 1 bus mandaban los resultados al chip gráfico/tarjeta aceleradora que los interpretaba y pintaban en pantalla. Dreamcast y PS2 hacían lo mismo, con sus particularidades por supuesto. Nintendo 64 no, estaba 1 paso por delante a nivel conceptual, aunque luego una VODOO se follase al RCP de la N64.

@Misscelan que sabe de asuntos técnicos más que yo de aquí al Himalaya me ha dado 1 like, luego entiendo que no estoy diciendo gilipolleces xD

@SuperPadLand ¿Cual es tu setup habitual? ¿RGB + OSSC + tele plana? ¿O RGB + CRT?
Lo digo porque la filosofía no-escrita de Nintendo con la 64 (o quizá de SGi de forma indirecta) es que no se viera un pixel en un CRT, dando la impresión de tener más resolución. Es decir, nada de los pixeles en texturas, nada de bordes de sierra en los polígonos. Con el filtro bilineal o trilineal y el AA era suficiente, quizá el dedithering se les fué de la mano. El caso es que yo he notado que sin dedithering el Quake se ve más nítido, pero tambien hace los degradados tosquísimos y se nota bastante el moaré en las texturas lejanas. Con CRT un poco menos, no es tan "crispy", pero se nota.

¿Por qué todo el mundo dejaba activado el dedithering? Porque al final en ciertas situaciones como las que he dicho valía la pena. El N64Digital (no confundir con el RetroGEM) tiene salida RGB después de aplicar los filtros de de-blur del mod. Es la salida RGB más nítida que puede poseer una N64. Los pixeles arañan las corneas. Es más o menos lo que iba pidiendo la gente que se queja de borrosidad en la consola.
¿Resultado? En Wave Race, en la animación de inicio, cuando la moto se acerca desde lo lejos, piloto y moto son un pegote de píxeles que no sabes distinguir cual es cual, en un CRT. Pones un RGB normal, sin tanto deblur, y es que la moto a lo lejos te parece de verdad, en comparación.

Y es que se nos olvida que a pesar de estaciones Indy y monitores de ordenador, los juegos se probaban en televisores CRT o quizá PVM, y los artistas podían comprobar ahí su resultado. No es que haya juegos de N64 con texturas realistas, la mayoría son coloridas tipo cartoon, pero estan diseñadas para trabajar bien con los CRT, y también los modelos 3D. Por eso las condiciones ideales para disfrutar de estos juegos es un CRT, o un filtro que imite muy bien un CRT. Otro tipo de pantallas con otra tecnología haran que, aunque la imagen se muestre con mayor fidelidad, se pierdan muchas características propias del CRT al mostrar la imagen.

Además no hay que olvidar que los tamaños más comunes de CRT doméstico eran entre 14 y 20".

Y esto que digo de la N64 se aplica también a la PS1, especialmente en los FMV, que en un CRT parecen de buena definición pero en cualquier otra pantalla parecen pegotes de pixeles moviendose.

Por cierto, lo que comentas de PS1, no aplica ningún filtro borroso si no hay dithering, es más bien al contrario, el dithering es un filtro que aplica la GPU de forma automática cuando hay degradados y el valor de color se pasa de ciertos valores. El filtro se puede desactivar pero entonces crea posterización:


En PS1 es bastante notorio. En N64 no tanto al poder reproducir más colores, pero también se notaba un poco en el Quake al quitar el filtro.

Y de nuevo, el dithering trabaja mejor y se hace menos notorio en un CRT.

Un apunte extra, ahora que me viene a la cabeza: me parece que el dedithering tambiénesta activo en juegos puramente 2D en la N64 como Mischief Makers. Me extrañaría que un artista decidiera que los 2D se viesen más borrosos. Es posible que la posibilidad de desactivar el dedithering solo lo supieran los programadores, o que Nintendo "recomendase encarecidamente" activarlo, de la misma manera que "recomendaba encarecidamente" activar el zbuffer.

@EMaDeLoC los juegos 2D que yo probé en su momento: NBA: Hang Time, MK Trilogy, Yoshi's Story, y el Mifchief Makers que comentas llevaban 1 puto filtro para evitar la pixelación que emborronaba algo la imagen. No me preguntes si era Bilineal, EdgeAA, o dedithering, pero que llevan filtraco llevan.

P.D: También nos alquilamos 1 vez el MK: Mythologies y el fucking Sub-Zero iba ligeramente antipixelado también xD

@EMaDeLoC la N64 la usó en CRT por RGB con tu mod. La enchufé al OSSC y LCD alguna vez para usar la capturadora de vídeo con ella, pero el 99% CRT de los pequeños, el tipico tv secundario para la cocina que empezó a entrar en las casas a finales de los 90 y principios de los 2000.

Edit: Este es uno de los dos CRT que tengo, ambos son del mismo tamaño:

@Sexy MotherFucker Si, eso me sonaba, que el filtro estaba puesto.
Como dije, a saber si era "recomendación encarecida" de Nintendo o simplemente no saber que se podía desactivar el dedithering.

@SuperPadLand Entonces no deberías notarlo tan "crispy" sin el filtro, pero bueno, así a ojo son 14" que aún con la imagen emborronada se ve muy nítido. Sin filtro quizá ya es pasarse de crispy.

EMaDeLoC escribió:@Sexy MotherFucker Si, eso me sonaba, que el filtro estaba puesto.
Como dije, a saber si era "recomendación encarecida" de Nintendo o simplemente no saber que se podía desactivar el dedithering.

@SuperPadLand Entonces no deberías notarlo tan "crispy" sin el filtro, pero bueno, así a ojo son 14" que aún con la imagen emborronada se ve muy nítido. Sin filtro quizá ya es pasarse de crispy.

Esto también ya va para gustos ya sabes, también hay gente que emula Gameboy con scanlines y cosas así

SuperPadLand escribió:

EMaDeLoC escribió:@Sexy MotherFucker Si, eso me sonaba, que el filtro estaba puesto.
Como dije, a saber si era "recomendación encarecida" de Nintendo o simplemente no saber que se podía desactivar el dedithering.

@SuperPadLand Entonces no deberías notarlo tan "crispy" sin el filtro, pero bueno, así a ojo son 14" que aún con la imagen emborronada se ve muy nítido. Sin filtro quizá ya es pasarse de crispy.

Esto también ya va para gustos ya sabes, también hay gente que emula Gameboy con scanlines y cosas así

De hecho hay gente que pone scanlines a todo cuando las scanlines estaban en monitores arcade como mucho, en casa las teles de tubo de consumo no muestran scanlines. Y tienes que leer que así es como se veían en la época en nuestras casas jugando en la Telefunken por RF o compuesto.

Falkiño escribió:

SuperPadLand escribió:

EMaDeLoC escribió:@Sexy MotherFucker Si, eso me sonaba, que el filtro estaba puesto.
Como dije, a saber si era "recomendación encarecida" de Nintendo o simplemente no saber que se podía desactivar el dedithering.

@SuperPadLand Entonces no deberías notarlo tan "crispy" sin el filtro, pero bueno, así a ojo son 14" que aún con la imagen emborronada se ve muy nítido. Sin filtro quizá ya es pasarse de crispy.

Esto también ya va para gustos ya sabes, también hay gente que emula Gameboy con scanlines y cosas así

De hecho hay gente que pone scanlines a todo cuando las scanlines estaban en monitores arcade como mucho, en casa las teles de tubo de consumo no muestran scanlines. Y tienes que leer que así es como se veían en la época en nuestras casas jugando en la Telefunken por RF o compuesto.

Yo en el OSSC las suelo poner (al mínimo) salvo excepciones, pero porque siento que ayudan a mitigar la perdida de nitidez del reescalado no porque sea el "verdader sentir retro". De hecho en mi CRT como bien dices ninguna tiene scanlines, si te pones a un cm de la tele ves la "rejilla", pero sino ni eso.

No sabía que había ports homebrew de los Doom clásicos @N64:



La resolución es 320x240 total, pero respetando el marco de 320x200 del original de PC. Cómo no podía ser de otra forma el juego lo mueve fluido sin problemas la Nintendo 64, nivel Pentium diría yo más que 486, pero habría que comparar in situ para estar seguros.

Tengo curiosidad por como lo habrán hecho; ¿Tirando a pelo de CPU en plan software-render como en PC? Procesador tienen de sobra desde luego. ¿O usando el RCP?

No quería comprar más flashcart para consolas, pero al final voy a tener que hacerme con 1 para estas cosillas en la 64...

Pilla el summer cart 64.

Sexy MotherFucker escribió:Tengo curiosidad por como lo habrán hecho; ¿Tirando a pelo de CPU en plan software-render como en PC? Procesador tienen de sobra desde luego. ¿O usando el RCP?

Tirando de CPU. Que yo sepa las librerias normales de SDK para N64 no soportan el Doom Engine, o al menos la forma de trabajar del Doom Engine no es compatible con la de estas librerias. Y estando el código fuente disponible y teniendo la CPU potencia de sobra, es más fácil portear.

El VR4300 es tan potente como un Pentium 100MHz, en teoría.

@EMaDeLoC

El VR4300 es tan potente como un Pentium 100MHz, en teoría

En teoría en los benchmark de R-4000 (el "padre" del R-4300i) VS Pentium 1 @igualdadefrecuencia para cálculos de enteros llevaba algo de ventaja el Pentium, eso sin tener en cuenta las gigantescas cachés L2 de los x86 del momento. Eso sí en coma flotante el MIPS le pegaba 1 paliza al Pentium, las FPU de esa familia estaban muy avanzadas comparativamente a la de los x86. Lo que no tengo idea es si la FPU capada del R-4300i también sería mejor...

En cualquier caso para mover 1 Doom a pelo igual da una CPU que otra. Y este de Nintendo 64 ya se mueve mejor que los "vainilla" de Saturn y PlayStation, aunque bueno el de Saturn telita por lo infrautilizada que está la consola

O´Neill escribió:Pilla el summer cart 64.

Tomo nota, gracias.

Dije hace unos días que rescataría unas fotografías directas a la TV (de tubo) que hice a las versiones de GoldenEye a diferentes resoluciones y con/sin antialising activado. Son las mejores que pude sacar de una selección de 4 o 5 fotos tiradas para cada caso. El encuadre no es el mismo en todas, pero intenté asemejarlo todo lo que me permitieron mi pulso y mi memoria muscular. La tele es una Philips panorámica de 32" con la consola conectada por compuesto. La tele recorta un poco la imagen a los lados en modo 4:3, mientras que en modo 16:9 parece que no tiene overscan (según pruebas que hice con el emulador de NES de la Wii).

Me faltaría el juego en PAL sin AA, pero creo que no hay parche disponible. Hace mucho tiempo que no miro nada. Y hablando de PAL y del tema de las scanlines (que no recuerdo si ha salido aquí recientemente o fue en otro hilo), la imagen en PAL es mucho más luminosa que en NTSC debido a que hay más líneas horizontales en la misma superficie y hasta hace daño a la vista después de acostumbrarse al NTSC. Y mientras en NTSC sí que se puede entrever un poco el espacio negro entre líneas (te acabas acostumbrando y lo ignoras), en PAL la imagen desde el primer momento parece continua. Desde mi experiencia, ni cuando jugaba a la NES por RF y compuesto en una FirstLine de 20 pulgadas, ni cuando lo hice a la Nintendo 64 por compuesto o la GameCube en RGB en una Trinitron 4:3 de 32 pulgadas notaba esas scanlines. No jugué apenas a recreativas así que no recuerdo si en esos monitores se notaban más (lo que sí recuerdo es que los gráficos se veían la hostia de definidos y coloridos). Recuerdo que cuando activé la opción de scanlines en el emulador ZNES sin saber qué era me pareció horrible el resultado y me preguntaba qué clase de persona jugaría de esa forma. Así que tengo la sensación de que en aquella época y en territorio PAL no había scanlines y que son un producto de la menor densidad de líneas (y por tanto más separación entre ellas y negro más visible) de los monitores NTSC.
Fue precisamente cuando empecé a probar juegos NTSC con el Everdrive 64 cuando más noté las scanlines. Particularmente con el Majora's Mask que la versión PAL aprovecha toda su resolución y la versión del collector's edition en castellano está en NTSC. Los textos y el reloj de la interfaz son enormemente más nítidos en PAL. Eso, junto al rendimiento más constante, hace que prefiera de lejos la versión que nos llegó, incluso si no hubiese estado en castellano.

Volviendo a las imágenes del principio del post; las voy a poner individualmente en secreto porque son grandes y pesadas. Encima del secreto pondré a qué versión corresponden, aunque se puede ver también en el nombre del archivo. Algún tiquismiquis me dirá que la resolución NTSC es 320x239 y alguna otra puede que no sea del todo exacta pero lo pongo así porque es más fácil de entender.

NTSC 320x240 "progresivo" con antialising


NTSC 320x240 "progresivo" SIN antialising


PAL 320x288 "progresivo" con antialising


NTSC 440x330 "progresivo" con antialising


NTSC 440x330 "progresivo" SINantialising


NTSC 640x480 entrelazado con antialising


NTSC 640x480 entrelazado SIN antialising



La resolución "440x330" es extraña porque no es entrelazada, pero tampoco he contado si realmente son 330 líneas verticales (ni lo voy a hacer, jeje). Pero sí que se ve más nítido que las resoluciones inferiores. Quizás renderiza internamente a 440x330 y luego la reescala a 440x240.
Tengo que afinar mis conocimientos del funcionamiento de los CRT, pero si se puede representar en un campo una resolución de 640x240 (como el modo alta resolución de Perfect Dark NTSC, que ya sé que no es esa resolución exacta, pero para que se entienda) que son 153600 "píxeles", una resolución de 440x330 que son 145200 "píxeles" también debería de poder plasmarse en un solo campo. ¿Puede la pistola de electrones variar el número de líneas y mostrar un número arbitrario si todo lo demás está bien sincronizado para tener una imagen estable? ¿No es lo que hacen las TV que permiten PAL y NTSC o los monitores de ordenador (CRT) con sus multiples combinaciones de resolución y refresco? Y ahora me sale un offtopic: ¿Un monitor de ordenador funciona de la misma manera que una TV (ambos CRT)?

@Sogun
Ni yo lo tengo muy claro, pero creo que todas las resoluciones que superan los 240p en 15 Khz se muestran en progresivo siempre que sea a 30 fps o menos, solo son entrelazados cuando van a 60 fps, que en el caso de N64 son todos los juegos comerciales que usaban el EP para subir la resolución.
Las teles de tubo domésticas tienen suficientes líneas horizontales para mostrar esas resoluciones (525) ya que el estándar NTSC y PAL se concibió para emisiones televisivas que no pasaban de 30 fps.
Es a 60 fps cuando tiene que pintar líneas interpoladas por limitación de la propia tecnología, así que en consolas que usan frame buffer puedes pintarlo a 480p y que la propia TV intercale las líneas o sincronizar un frame buffer de 640x240 y ahorrarte la mitad pixeles.

Salud.

Sogun escribió:La resolución "440x330" es extraña porque no es entrelazada, pero tampoco he contado si realmente son 330 líneas verticales (ni lo voy a hacer, jeje). Pero sí que se ve más nítido que las resoluciones inferiores. Quizás renderiza internamente a 440x330 y luego la reescala a 440x240.

Efectivamente, un CRT no puede con 330 líneas ni en progresivo ni en entrelazado. De alguna forma la imagen debe reescalarse verticalmente. Sería interesante saber si es el framebuffer el que está a esa resolución y el VI hace la escala al leerlo, o si el RCP renderiza a esa resolución los triángulos y automaticamente los escala al grabarlos en el framebuffer a 240p.

Sogun escribió:Tengo que afinar mis conocimientos del funcionamiento de los CRT, pero si se puede representar en un campo una resolución de 640x240 (como el modo alta resolución de Perfect Dark NTSC, que ya sé que no es esa resolución exacta, pero para que se entienda) que son 153600 "píxeles", una resolución de 440x330 que son 145200 "píxeles" también debería de poder plasmarse en un solo campo. ¿Puede la pistola de electrones variar el número de líneas y mostrar un número arbitrario si todo lo demás está bien sincronizado para tener una imagen estable? ¿No es lo que hacen las TV que permiten PAL y NTSC o los monitores de ordenador (CRT) con sus multiples combinaciones de resolución y refresco? Y ahora me sale un offtopic: ¿Un monitor de ordenador funciona de la misma manera que una TV (ambos CRT)?

Se viene tocho.

Primero unas cositas básicas para recordarlas o quien no las sepa.
Una señal de vídeo se compone de varias líneas seguidas una tras otra, agrupadas en frames. Son 480 líneas en NTSC y 576 en PAL (en realidad hay más líneas llamadas Vertical Blanking Interval, pero por simplificar nos quedamos con esas líneas). Los frames tienen un conjunto de líneas pares y otro de líneas impares. A esto se le llama campo. La señal de vídeo enviará primero el campo impar al TV, este lo dibujará en pantalla hasta acabar el ciclo del Hz, y a continuación se dibuja el campo par hasta final del ciclo del Hz para completar el frame. Es decir, la señal va a 30fps en NTSC y 25fps en PAL, cada frame se divide en dos campos, dibujandose el campo impar primero y el par el segundo en los dos ciclos de reloj que divide cada frame. Dos campos por cada frame son 30 x 2 = 60Hz en NTSC y 25 x 2 = 50Hz en PAL (en realidad NTSC es 59.94Hz pero de nuevo por simplificar, 60Hz).
De esto vamos a remarcar que la señal estandar es siempre entrelazada, a 480i o 576i, a sus 30 o 25fps.

¿Porqué da igual si la imagen es NTSC o PAL que se llena todo el cuadro del CRT (siempre y cuando se dibujen todas las líneas de cada formato)? Porque el televisor se sincroniza verticalmente. Es decir, el barrido vertical se va a ajustar a la duración del campo, yendo un pelín más rápido en NTSC y un pelín más lento en PAL. Las líneas o frecuencia horizontal es siempre la misma, 15KHz, y de hecho si hacemos mates: 480 x 30fps = 14400 líneas, 576 x 25fps = 14400 líneas. Es decir, reduciendo los fps o los HZ adecuadamente, caben más líneas por frame y el TV solo tiene que ajustar su frecuencia vertical para que quepan exactamente igual dentro del cuadro de la pantalla.

Si la señal es entrelazada, ¿de donde sale el progresivo?
La sincronía vertical y horizontal esta dentro de la señal de vídeo, y antes hemos dicho que hay campos de líneas impares y líneas pares. Si la sincronía vertical fuese siempre la misma, no habría diferencia entre campos impares y pares. Así que la señal de vídeo retrasa solo un pelín la sincronización vertical para que los campos pares queden un poquito por debajo de los impares. De esta forma al dibujar el frame, el campo impar deja huecos entre líneas que son rellenados después por los campos pares. En realidad dejan huecos los dos, pero al ir tan rápido el ojo apenas percibe el parpadeo de estos huecos.
Tanto consolas como arcades se aprovechan de que 240 o 288 líneas pares o impares son muchas líneas en una pantalla normal, incluso de 25", con muy poca separación entre ellas. Así que omiten la diferencia de sincronización vertical de los campos pares para dibujar todas las líneas del frame en el mismo sitio. Y magicamente el frame se divide en dos frames, duplicandose la frecuencia de fps y eliminando el parpadeo de entrelazado, a costa de reducir la resolución vertical. Y entonces tenemos los 240p o 288p famosos.

En progresivo al no rellenarse los huecos entre líneas como en el entrelazado, se forma una línea negra de separación entre las otras, formando el efecto de scanlines. Pero la scanline no es la línea negra, es la línea que se pinta, por eso es la "línea de escaneo" o "línea de barrido". La línea negra es la zona que queda sin scanline, por tanto no es la scanline.

Y ojo, en los CRTs la resolución horizontal no existe. Existe la vertical en forma de líneas, pero la horizontal no. Existen una variación de valores conforme el tiempo, el "estandar" dice que en la señal de vídeo se puede distinguir 640 o incluso 720 diferencias de valor dentro de una línea, considerando cada diferencia como un pixel. Pero en realidad depende de la calidad de la pantalla y de su densidad de celdas de fósforo, y también de la calidad de la circuitería, del flyback... En tecnología doméstica de TV CRTs, no hay tanta calidad o precisión, e igualmente la señal por su frecuencia tampoco puede dar mucho más de sí, así que 640 diferencias es el tope asumido.

¿Puede la pistola de electrones variar el número de líneas y mostrar un número arbitrario si todo lo demás está bien sincronizado para tener una imagen estable? Pues un TV estandar no, pero de otro tipo por supuesto que sí. La máquina Vectrex, arcades como Asteroids, los osciloscopios antiguos, etc, funcionan con monitores de vectores. Estos alteran la posición horizontal y vertical de barrido de electrones para dibujar las líneas hacia cualquier dirección y longitud. Pero estos monitores tienen circuitería específica, y creo que además su refresco varía dependiendo de la cantidad de líneas a dibujar, si hay muchas el framerate disminuye al tardar más el monitor en dibujar estas líneas. Os dejo un vídeo que se ve una pantalla de estas en cámara lenta:


Los monitores de CRT de PC son diferentes. Su construcción es superior a un TV de consumo, aceptando frecuencias de vídeo mucho más altas, sus pantallas de fósforo eran más densas en puntos y el rayo de electrones era capaz de ajustar su tamaño en resoluciones bajas para evitar precisamente líneas negras (si dibujas 640x480 pero con líneas de 1600x1200, te quedan unas líneas negras muy resaltadas). Hay modos de resolución en entrelazado, el problema es que el fósforo de un monitor no dura tanto encendido y el parpadeo es mucho más notable que en una tele, así que los modos entrelazados no los usaba nadie. Yo todavía conservo un monitor de PC CRT de la marca Philips y recuerdo que incluso a 75Hz el entrelazado daba unos parpadeos terribles. Pero por poden, podían.

Espero no haberme equivocado y haber despejado dudas.

Estoy de pasada por aqui y leo un tema famiilar. No me he parado a leer en detalle, pero si: Los menús de GoldenEye renderizan a esa resolución rara que no es 1:1 con la resolución de pantalla y el VI lo escala antes de salir por el cable.
Traté este tema con marshallh hace un porrón de años ya.

Hay muchos casos de resoluciones raras en N64. no se si llegué a ponerlos todos aquí en algún momento o si se recuerda, pero tenemos el extraño caso de Body Harvest que renderiza a alguna resolución rara por debajo incluso de 240 (1XX algo) y el VI lo estira tanto en NTSC como en PAL.
Luego está el Goemon 1 japonés (el 3D free roaming) que renderiza a 240p pero el VI lo reescala a 480i por alguna extraña razón (en USA lo arreglaron y en PAL lo estiraron, como de costumbre)

Saludos, esceneros de N64

@EMaDeLoC
Los CRTs de consumo tienen un componente llamado en inglés (desconozco la terminología española), flyback transformer, que genera el voltaje para los electroimanes de deflección horizontal y vertical. Este componente general una corriente alterna en sierra (sawtooth) ajustada para de un lado al otro de la pantalla en un tiempo determinado (unos 64microsecundos horizontalmente en PAL y NTSC, y algo diferente y mas lento en vertical). Este componente se activa cada vez que la electrónica de la TV detecta el correspondiente pulso de sincronización. En la práctica es un poco mas complejo porque hay que sincronizarse con la cadencia entrante de ese pulso, pero en última instancia la señal manda, y esa es la razón por la que una TV normal no está preparada para sincronizar, digamos, a 20kHz horizontal o 55Hz vertical, por decir algo. En video analógico 15kHz con sincronía en luma (compuesto, svideo, rgb con compuesto como sync), el entrelazado se consigue señalizando un pulso de sincronización horizontal a mitad de linea en vez de junto con el pulso vertical. Debido a que el avance del flyback vertical es continuo y gradual, al sincronizar en horizontal a mitad de una linea horizontal, se consigue que haya un retraso de media linea, lo cual hace caer un conjunto de lineas justo entre las que acaban de trazarse en el ¨campo" anterior. Se van alternando "campos" que empiezan a mitad de linea y campos que empiezan a principio de linea, y eso es lo que produce el entrelazado.
La concepción de campo par e impar no es algo inherente al formato de señal, si no un truco basado en variaciones de temporización. (escribiendo esto se me ocurre que quizá sea posible generar una señal triple entrelazada señalizando Hsync al principio, un tercio y dos tercios de linea, aunque eso quizá rompa la cadencia Hsync... o quizá no, si supiera de electrónica lo pondría a prueba, aunque seguro que se vería fatal). Tanto es una concepción ajena a la señal que cuando se trata de video entrelazado donde cada campo tiene un valor temporal diferente, entra en juego la convención oficial de si es el par o el impar el campo primero de un cuadro entrelazado mostrado en dos campos).
Espero no estarla liando mucho. Pero todo lo que he dicho es verda, lo juro. xD
El caso es que en una señal 240p 60hz o 288p 50Hz (LDTV) como las que emiten las consolas clásicas habitualmente, no hay campos pares e impares, porque todas las sincronías verticales coinciden con una horizontal para que todas las lineas se proyecten sobre la misma área de las anteriores, siendo una señal progresiva a mitad de resolución pero con las "misma" sincronía (CASI la misma) que SDTV. En LDTV yo mas bien hablaría de esos "campos" como frames. Ya no son campos par e impar de un mismo cuadro. son frames por derecho propio. Contienen, idealmente, información visual de un momento difrente de la acción (si la máquina renderiza suficientemente rápido), y la señal no impone ningún concepto de par e impar ya que todos los campo-frames empiezan con un combinado de H y V sync.

par e impar solo existen de manera interpretativa por la coincidencia o no de pulsos H y V

EMaDeLoC escribió:¿Puede la pistola de electrones variar el número de líneas y mostrar un número arbitrario si todo lo demás está bien sincronizado para tener una imagen estable? Pues un TV estandar no, pero de otro tipo por supuesto que sí.

El motivo es que las TVs, pensadas como aparatos relativamente baratos, usan un flyback porque hace lo que se necesita de forma eficiente: voltajes AC en sierra, con cada cresta activada por un pulso entrante y una duración y rampa de bajada ajustada en fábrica o por un técnico. Pero existen circuitos que permiten mucho mas control y variabilidad. Los monitores de vectores que mencionas usan Tubos y rollos de deflección similares a un CRT normal, pero varia la electrónica de control y los voltajes que puede generar. De la misma forma, los flybacks de monitor de PC son de mas calidad y mas facilmente configurables, incluso de forma electrónica mediante un menú en pantalla, para ajustar tiempos, caidas, etc, para el ajuste de la geometría. Y luego están los osciloscopios analógicos, claro, que amplifican señales entrantes a los altísimos voltajes necesarios para controlar la deflección electromagnética, y permiten control total.

Los devs de los 90 ayudados por las revistar se marcaban unos “invents” bastante simpaticones.
-Yu Suzuki diciendo que había conseguido usar al 100% los dos SH2… en primer VF de Saturn, los devs de Vagrant Story diciendo que movía 4000 polys por frame, Polyphony diciendo que gracias el Performance Analyzer GT2 sería un mundo aparte…

En aquella época, molaba hasta oír estas cosas y montarte tus películas, pero hoy en día es bastante fácil desmitificar todo eso. Cuando un dev de los 90 decía que había conseguido algo que era significativamente mejor que la competencia (aunque fuese dentro de la misma consola) era generalmente, por lo que he podido comprar, falso.

Uno de esos mitos, siempre fue el número de polígonos por segundo de WDC, con gente llegando a hablar de unos 180000/s, y esto es algo de lo que siempre he tenido ganas de comprobar su veracidad.

Hace algún tiempo que encontré una herramienta para hacer rip de los coches desde la ROM ( World Driver Championship Butcher - https://www.romhacking.net/utilities/1269).
Con esta herramienta puedes sacar los modelos a .obj para luego importarlos en Blender. No tiene para exportar los escenarios pero los renderiza en OpenGL para que les puedas dar un ojo, pero al renderizarse en OpenGL puedes capturar el output con RenderDoc.

Con esto tenemos lo necesario para generar un escenario similar y tener una idea de la carga poligonal.
Primero saqué este coche. El chasis de la versión high poly son 222 Tris y cada rueda 24. La versión LowPoly son 97 tris.





Para el escenario intenté coger el que me pareció que tenía más carga poligonal (Las Vegas A).
Todo el escenario de las vegas son como 17k triángulos.


Intenté coger la parte que me parece más densa, que es a la salida del túnel y juzgando por este video (https://youtu.be/1Nad81HCar0?t=3700), el far clip plane llega más o menos hasta el segundo puente. Seleccionando esta geometría tenemos unos 2k triángulos.



Pero ahora vamos a poner 3 coches highpoly con todas sus ruedas y 3 lowpoly. Dada la resolución del juego posiblemente la transición high-low pase antes, y las 4 ruedas tampoco serían necesarias ya que no se deberían ver las 4 durante el gameplay, pero las dejamos. Eso nos da unos 3k polígonos.



Ahora queda la última fase, hacer el backface culling y quitar los polígonos que queden fuera del viewport. Movemos la cámara al sitio que queramos y ejecutamos este script (https://pastebin.com/j96T0bSF) para seleccionar solo los que cumplan lo anterior.




Como veis nos quedan seleccionados unos 2200 triángulos, lo que se traduce en 66000 (vamos a rendondear a 75k por cosas como partículas, o lo mejor un FOV distinto, o algún pequeño error al exportar etc...) triángulos por segundo si el juego mantiene los 30fps. He intentado coger el escenario con la carga más alta pero si pensáis que hay otros escenarios o puntos con más carga podemos probar esos.

El juego al final parece tener unos polígonajes parecidos a RR64 o SFR2049. No sé como se comparan los 3 en términos de resoluciones internas y/o framerate.

De los escenarios no puedo sacar texturas, pero de los coches sí, y parecen usar bastantes, el modelos que saqué usa 19 texturas (entre high y low), un número que me parece bastante alto. Dada la alta penalización de un cambio de textura en n64, lo mismo los esfuerzos de limitar el uso del z-buffer no iban por el camino de aumentar la carga polígonal sino para añadir variedad de texturas.

@Misscelan
Interesante lo que dices, pero creo que a los datos que das le falta el cielo y los reflejos de los coches que si no me equivoco es una malla similar a la carrocería con enviroment, también puede que falte objetos que cargue y descargue en tiempo real como arboles, señales y similares.
Aún así es difícil saber cuánto puede dibujar sin herramientas en el propio juego, porque puede que aguante más tralla, por ejemplo hay una rama de Decomp del OoT, que trae muchas herramientas para medir el rendimiento, y por ejemplo en la campiña de Hyrule hay partes que marca que podría dibujar 50 fps y en otros 23, aunque siempre esté ejecutándose en 20.

Salud.

@Misscelan
Muy bueno

Sobre lo que comentas de las revistas y tal, en el caso de WDC uno de los programadores dijo sobre los 100K al ser preguntado en los foros de beyond3D, años después de la generación, entre 2004-2007, donde andaba explicando otras cosas, creo que no ganaba nada si mintiera en las cifras, normalmente siempre se ha dicho 100-120K por posibles fluctuaciones, no me suena haber leído 180K, aunque bueno en internet ya se sabe.

Creo que el escenario está bien elegido y es de los que más carga vi a ojo, el de Las Vegas por la parte de las palmeras y edificios, la distancia de dibujado ya sería más difícil de deducir.

Faltaría el globo del cielo, OSD/marcadores, sombras y algunos efectos, fuera o dentro del vehículo.

El rendimiento no suele decaer, en base a pruebas, salvo que levantes mucho polvo cerca de la cámara (falta fillrate), creo que es fiable hacer el cálculo sobre 30.

Me sorprende el bajo polycount de los coches, incluyendo ruedas, en base a otros juegos de la consola, si no recuerdo mal son 8 por carrera y llegan a verse, por lo menos de inicio, lo que yo me pregunto ahora es si el programador se refería a que probaron escenarios con picos de geometría y todos los coches con detalle razonable colocados a mano, y de ahí sacaron los 100K y garantizas un rendimiento estable en el resto del juego, pero en el mundo real, esas cifras serían solo el pico y quedando por debajo.

Misscelan escribió:Uno de esos mitos, siempre fue el número de polígonos por segundo de WDC, con gente llegando a hablar de unos 180000/s, y esto es algo de lo que siempre he tenido ganas de comprobar su veracidad.

No me suena haber oido esa cifra de 180.000, pero tampoco he leido mucho sobre el juego en revistas. Siempre he leido más la cifra de 100.000/s.

Misscelan escribió:Con esto tenemos lo necesario para generar un escenario similar y tener una idea de la carga poligonal.
Primero saqué este coche. El chasis de la versión high poly son 222 Tris y cada rueda 24. La versión LowPoly son 97 tris.

Parece pocos polígonos, pero en Gran Turismo la cifra es más o menos similar.

In GT and specifically in CARCADE.DAT cars main body have 136~244 polygons(triangles + quads) not counting LOD models(theres two more LOD models in car beside of the main model) I also don't counting bottom of the car as it use different type of face and the wheels(they are stored elsewhere anyway), theres also shadow model which I don't counting neither. As about texture GT use 256x256 4bit each car color can use 16 palette max.

https://polycount.com/discussion/133462/gran-turismo-1-car-model-specs

Que ciertamente como dices, la prensa exagera bastante las cifras:

The cars in GT2 are said to have about 1000 to 2000 polygons per vehicle, which would suggest that the ones in GT2000 are made up of between 10000 and 20000 polygons.

https://www.ign.com/articles/2000/02/24/polygons-smolygons

Si hubiese 1000 polígonos por coche en GT2, la PS1 entraría en fusión del núcleo...
Supongo que la "trampa" para no mentir es sumar los polígonos de todos los modelos LoD, reflejos, ruedas (las 4), sombras, etc para llegar a esas cifras. Aún así con todo me parece que siguen exagerando mucho...

Misscelan escribió:Como veis nos quedan seleccionados unos 2200 triángulos, lo que se traduce en 66000 (vamos a rendondear a 75k por cosas como partículas, o lo mejor un FOV distinto, o algún pequeño error al exportar etc...) triángulos por segundo si el juego mantiene los 30fps. He intentado coger el escenario con la carga más alta pero si pensáis que hay otros escenarios o puntos con más carga podemos probar esos.

El cálculo parece bastante correcto, aunque como dicen los compis, faltan otros modelos y polígonos como cielo, HUD, etc. También habría que ver cuantos polígonos de humo/polvo puede dibujar antes de bajar de los 30fps. Además de añadir más polígonos, como dice @Conker64 al ser transparentes se comen el fillrate y el ancho de banda de la memoria (3 quads transparentes son 3 lecturas y escrituras por pixel, más el trabajo de renderizado previo).
Además todos los coches pueden coincidir en un punto y por tanto estar en high-poly en cámara, lo que son 300 polys más a sumar a tus cálculos. A fin de cuentas el motor del juego ha de soportar el peor escenario posible (todos los coches cerca en high-poly, en un escenario denso, con polvo/humo, etc) y a partir de ahí diseñas todo para que ese escenario se cumpla o rebase muy puntualmente.

Otro detalle que igual se te ha pasado, es que en el modo hi-res el PoV es más amplio que en modo low-res. Es verdad que se pone en letterbox y por las mediciones que hizo Conker64 hace años no sube mucho la resolución, pero sí que en hi-res el PoV se amplia y por tanto el polycount sube.

Yo creo que añadiendo esas cosillas sube a 2.600polys por frame y ronda los 80.000polys/s. Quizá en ciertas condiciones sube hasta 100.000. El circuito elegido no es mal ejemplo, pero hay otros que creo que tienen más distancia de dibujado al situarse de día (y por tanto no poder disimularlo tanto), tienen sombras (lo que subdivide el escenario un poco más) y hacen curva con lo que se muestra más escenario, como Rome A o Hawaai A.

Podrías echarle un ojo, aunque este cálculo ya es lo bastante bueno.

@Conker64 @dirtymagic
Sí, alguna cosa más se me habrá olvidado. Los árboles (en el caso de las Vegas, palmeras) son esos triángulos invertido y estirados. Los reflejos creo que vienen ya dentro de los modelos porque hay cierto número de polígonos superpuestos justo en la parte donde refleja.

Había un par de detalles como los retrovisores y una parte del spoiler que se los había puesto al low poly, así que la versión high tiene un poco más y la low poly un poco menos.
He añadido un Skybox y 8 coches, aunque ya es un escenario un poco improbable, justo en la recta con más carga poligonal encontrarte todavía a los 8 coches, 3 de ellos (siendo high poly ( y aquí podéis ver https://youtu.be/1Nad81HCar0?t=3708 usando “,” y “.” Que el lowpoly salta bastante cerca)
Con estos cambios da, 2358 tris. Faltaría el HUD y lo que queráis asignar como sombra a los high poly, los low poly me imagino que si tienen será un cuadrado, pero creo que todavía está bastante lejos de 120k.

Pero sí queréis cacharrear con el archivo Blender aquí lo tenéis:
https://blend-exchange.com/b/sA2Wapvx/

Podéis mover el viewport donde queráis y al darle al botón de Play en el lado del script y os debería seleccionar los polys visibles.

@EMaDeLoC
Sí, de Gran Turismo lo hablé una vez con Conker y puse una extracción de un modelo en este hilo creo y los números estaban por ahí. Gran Turismo me parece otro caso de humo bastante gordo, el mérito de los modelos es más de los artistas. En las repeticiones lucen bastante bien, pero la carga poligonal es baja y además los escenarios son flat-shaded. Técnicamente dentro de PSX me quedo con RRType4 de lejos.

@Misscelan
Tenía por aquí un wireframe del punto exacto del que estamos hablando con el escenario de Las Vegas:


Lastima que no lo sacara a mejor resolución en su momento, porque no se ven bien las líneas, incluso las luces de la carretera, pero bueno, sirve para ver como funciona el HUD, siempre y cuando la emulación fuera buena, parece que en los letreros agrupa y en los contadores dinámicos lo hace individual, un carácter/rectángulo.

La toma es del modo contrarreloj, en carrera son más datos, así que sabiendo eso he contado a mano y me salen unos 76 rectángulos para el HUD, digo rectángulos pero es probable que use triángulos en algunos casos, como en la aguja del medidor de velocidad. (otra cosa es que el wireframe de DirectX lo saque todo como triángulos, yo tengo mis dudas y confío en que se usaran rectángulos, es una primitiva más rápida para 2D sin rotación y estos eran expertos)

Cuando terminas una carrera, por encima de todo lo anterior se pintan los resultados durante un corto periodo de tiempo, podrían ser otros 60 o más, dependiendo de como dibuje.

Hay que no entiendo por lo que he entendido del impacto que tiene el z-buffer en el rendimiento.

¿Como es posible que con z-buffer 60 mil polígonos por segundo no sean ninguna quimera, pero sin z-buffer este juego tenga un conteo de unos 60 mil a 70 mil, exactamente igual que otros títulos que no prescindan de estos post procesos?.

@Señor Ventura
Es que el secreto al final está en el equilibrio.

Si pintas por poner un ejemplo: 20 paredes del tamaño de la pantalla (320x240) vas a empezar a perder rendimiento, 40 triángulos, y ya empezarías a ahogar a la consola para que saque 60fps, sin nada más que eso.

El encargado de rellenar el Z-Buffer es el RDP, a efectos prácticos es como si pintaras 2 veces, pintas el color (el framebuffer) y la profundidad (el Z-Buffer), ambos a 16bits.

Las ventajas del Z-Buffer es que no tienes que ordenar por primitiva, pero si lo usas, úsalo bien con un motor inteligente que compare y descarte superficies innecesarias, al final hay motores que ponen y sacan objetos, superficies algunas, pero tan avanzados, pocos.

Volviendo al ejemplo anterior, si tienes 20 paredes del tamaño de la pantalla solo vas a ver la primera de todas, ahora imagina un motor que sepa descartar las 19 restantes, lo que queda en pantalla que es a su vez tapado por otra cosa de la pantalla, no es tan fácil, porque ese sería el escenario ideal, pero esa es la idea.

Sin el Z-Buffer tienes más fillrate, ordenas los polígonos de forma manual y tienes más control (aunque eso tampoco sale gratis), no es lo mismo un juego que alcance picos de 60K fluctuando entre 15 y 30fps, que uno que te alcanzará 30fps con 60K o más (si 100K es la cifra que ellos analizaron, fuera del juego en sus tests de prueba, es algo que también podría ser posible)

Tienes los nuevos tests de libdragon con contador de poly/fps, tienes Mario 64 corriendo con el framerate desbloqueado en consola nativa, y otros ejemplos donde esas cifras de 100K son alcanzables, incluso con Z-Buffer podrías si las superficies son muy pequeñas, porque en esta consola todo afecta y hay que encontrar un equilibrio.

Conker64 escribió:Sin el Z-Buffer tienes más fillrate, ordenas los polígonos de forma manual y tienes más control (aunque eso tampoco sale gratis)

No sale gratis, pero tanto no debe costar si la PS1 con CPU de 33Mhz lo consigue.
Claro que también puede ser que al ser los escenarios de menos carga poligonal no sea tan costoso en cálculo, aparte de cálculos previos como los que hicieron con los Crash Bandicot, que estaba precalculado el orden de los polígonos para maximizar el fillrate. No me extrañaría que en otros juegos de PS1 hubiese trucos y optimizaciones de display list.

@EMaDeLoC
Bueno yo tendría en cuenta que PSX fue diseñada para funcionar de esa forma.

Te dejo un fragmento, del programador de WDC hablando sobre el tema, y sobre eso en particular:

Anyone know the actual fillrate of the N64? I couldn't find it.

- Wouldn't be of much use, the theoretical numbers were much higher than what you'd see in practice since it was bandwidth limited for the most part. Plus you have to take into account things like stalls while loading the texture into the cache which the PS1 never had to deal with.
Turning off Z made a considerable difference, World Driver runs without a Z buffer for this reason, but it was a significant risk when we made that decision, because it was unclear if Nintendo would bounce a title for excessive Z fighting.

And the only Nintendo supplied uCode that made it practical to omit the ZBuffer didn't come until very late and was feature incomplete.

At a hardware level you build command lists in memory and DMA them to the local memory on the RSP, the RSP runs arbitrary code on the command list and eventually you output rendering primitives to the RDP. Most uCode writes this back out to memory into a circular buffer for the RDP to read (increasing the load on main memory), although it was technically possible for the RDP to read directly from RSP memory RAM was so restricted, the RDP tended to starve.

Reordering is certainly not as simple as on PS1, but you could run sets of static display lists in arbitrary orders pretty easilly.

I think most people used the Zbuffer because it was there.

Y ya de paso otros textos, del Top Gear Rally y el audio:

It's actually an Amiga style tracker, channels are left or right, I can't remember how many channels we supported off the top of my head. N64 really didn't have good audio.

Audio like our later titles was a tracker, because that's what our sound guy (Barry Leech at the time) wanted given the very significant constraints. At the time the Nintendo libraries used the RSP for the mixing, but we measured a significant performance penalty for this, so I wrote a mixer on the main CPU, which balanced load a bit better. For WDC we moved the mixing back to the RSP because we had access to the uCode and it wasn't really the bottleneck.

Físicas y otros detalles de desarrollos:

TGR happened because we were located just up the road from Kemco's US office. They were looking for a dev to do a Top Gear racing game on Nintendos upcoming platform, and several of us wanted to do a racing title.

The prerendered sequence we did back then was largely to convince Nintendo to get devkits, it wasn't a common sales tactic in those day, but since it's become common practice.

The physics engine went in very late in TGR, There were actually two developed and the first prooved to be unusable. I wrote the second one to dig us out of a dev hole. In terms of what's modelled it's similar in principle to the WDC one, the tire model is simpler and it has some bonus bugs in it. The WDC one is also about 10x faster (which gives you how an idea of how much implementation can change performance) mostly due to improvements in the collsion representation.

The Snow tracks came about because an artist volunteered to do it in a meeting with Kemco. Everyone loves the Jungle in the Snow...

The paintshop was an idea that had been thrown around internally, and I always fought against (I lost) because it hurt the graphics quality of the cars significantly.

Supongo que si sigo buscando daré con el texto que hablaba de los polys de WDC.

¿Que no se sabe la tasa de relleno de n64?, sería entonces, imagino.

¿Se han hecho pruebas de geometria sin los postpricedos, mas allá de ejemplos en 2D?.

La PSX tiene una opción de DMA que va recorriendo los paquetes de la bucket list a una FIFO de la GPU, trabaja al margen de la CPU. La inserción si que se hace en la CPU, al no tener cache de datos el coste de acceder al elemento de la bucket list son 4 ciclos.

En Saturn ordenar 1400 paquetes me cuesta un par de ms. El coste de inserción no llegué a medir pero eran 2 o 3 instrucciones, tienes al coste que traer una línea de cache 16 bytes (son 12 ciclos).

En n64 no llegué a medir esto, pero no creo que tardase mucho tampoco. Probé a ordenar los paquetes sin zbuffer de atrás para adelante, y luego con zbuffer de adelante para atrás y luego sin ordenar con zbuffer. Creo que la opción que ganó por 2ms fue ordenar de adelante para atrás con zbuffer, pero como comenta Conker depende mucho del proyecto, incluso puede variar de un nivel a otro dentro del mismo proyecto.

Iba a comentar que en el caso de WDC podrías traer las listas pre ordenadas, parecido a Crash para el escenario, y luego para los coches preordenar en 4 direcciones y luego coger la que más se alinee, pero veo según lo que ha puesto Conker parece que hacían ya algo precalculado.

@Conker una pena que no se vea bien las sombras, tenía curiosidad por ver si era una proyección u otra cosa.

Otra cosa que no tuve en cuenta fueron las marcas de derrapes, aunque por el otro lado también veo que hay geometría dentro del frustum y del far-plane que se descarta de manera diferente como los tejados del edificio que tienen unas partes como pirámides (a la izquierda):

No me acordaba pero Kaze Emanuar hizo hace un tiempo una prueba pintando 10.000 triángulos a más de 30fps en la consola:


En realidad no todo el frame pilla los 10.000 tris a la vez, pero aunque fuese solo la mitad (que es más, seguro), hablamos de 150.000 tris por segundo.

Evidentemente no esta usando z-buffer y seguramente alguna otra cosa más, y la textura es la misma por lo que dispone de todo el ancho de banda de la RAM.
De todas formas demuestra que con ciertas optimizaciones se puede llegar a 100.000 con cierta variedad de texturas.

Mi intención con el post no era demostrar si n64 podía renderizar 120k o no, era comentar como en aquella época se podían engordar números y esa información no se podía contrarrestar.
Yo juraría que había visto en foros (no devs oficiales) hablar de cifras más altas que 120k, pero bueno en cualquier caso me parece que la creencia popular era que WDC estaba ligas por encima del resto de títulos de n64 y no parece ser el caso.

Si queremos tener una idea un poco más moderna de hasta donde puede llegar n64 podemos, usar RenderDoc y extraer una captura de la demo de Kaze, y eso he hecho


El extracto de RenderDoc ya hace algunos cortes. Lo que me da es una escena de más de 4000 polys. El juego genera unas 400 DrawCalls (agrupaciones de polígonos), esto sucede cada vez que se cambia de material (textura o cambiar de textura a sin textura y viceversa) o cuando se tiene que partir porque no entra en la memoria del RSP, creo que con el microcódigo que usa eso pasa con 201 vértices (67 triángulos).
Agrupando por material permite dar un mejor uso de TMEM. El juego casi con total seguriad usa z-buffer porque algunas DrawCalls tiene objetos a distancias muy dispares unos de los otros.
Quizas desactiva el z-buffer en algún objecto específico como el Skybox.


Por alguna razón no me ha exportado las monedas, pero sí la sombra que son 6 polígonos.


Movemos la pantalla a la zona donde normalmente hace las pruebas (el FOV es un poco diferente) y ejecutamos el script de ayer.


Eso nos da 2374 triángulos (vamos a redondear a 2500 por cosas como las monedas) y multiplicamos por el framerate que consigue en esa zona, creo que ahora está en 56. Ósea esta escena está funcionando a unos 140k poly/sec.

Si que es verdad que este proyecto es un poco particular porque Kaze lleva haciendo modificaciones al motor desde hace unos 10 años y buena parte de esos años ha sido ya con el código fuente descompilado, estás circunstancias son difíciles de dar en otros proyectos. Y además desde esta vista se da el caso de que hay un porrón de triángulos minúsculos que le vienen de perlas a la consola, en otras zonas de ese nivel no se da esa circunstancia el framerate baja cerca de 15 fps. Pero en cualquier caso, es un escenario real de un juego donde a falta de mejoras, que seguro que habrá, la n64 llega a los 140k.

@Misscelan
Está quedando una página muy apañada

Nintendo siempre ha sido comedida dando ese tipo de cifras, para N64 siempre se dijo 100-150K en cuanto a cifras "abultadas", mirando los documentos técnicos a mi me parecieron honestos con el resto de cifras, muchas las he podido contrastar a mano, porque tenía mis dudas del rendimiento de la libdragon.

En cuanto a las cifras de internet de esa generación pondría más el punto de mira en Saturn y sobretodo en PSX, tengo curiosidad, llegaste a analizar más a fondo algunos de sus títulos? Que te parecen estas cifras?

Te pongo lo típico que suele verse:

SATURN (segaretro)

Polygon rendering performance: Lighting

800,000 polygons/s: Flat shading, 32-pixel polygons
500,000 polygons/s: Flat shading, 50-pixel polygons
200,000 polygons/s: Gouraud shading, 32-pixel polygons

Texture mapping performance: Lighting

300,000 polygons/s: 32-texel textures
200,000 polygons/s: 70-texel textures
140,000 polygons/s: Gouraud shading, 32-texel textures

PSX (wiki)

the GPU can also generate a total of 4,000 sprites and 180,000 polygons per second, in addition to 360,000 per second flat-shaded

Y de hecho en internet siempre ha existido ese consenso, de que N64 es la que menos polígonos pone de las 3, hasta alguna vez escuché al de DF decirlo.

Así que en su día miré bastante PSX, porque en Saturn era más difícil hacer debug, y lo que vi es:
- Juegos en la franja de los 60K o por debajo (habitual)
- Juegos buenos técnicamente en la franja de los 90K (pocos)
- Juegos cercanos a los 120K o algo por encima (géneros muy concretos)

Tobal n1 me pareció de los mejores ejemplos, con unos 120-140K, claro que, casi todo era flat shaded (personajes) o goraud, en Tobal 2 pasaron a renderizar los personajes a goraud, con más texturizado en los escenarios y las cifras ya bajaron a 90K.

Tiene una resolución elevada, de ser 320x240 igual podrían haber rascado un poco más, pero yo creo que estaban tocando techo en algunos apartados y subieron en otros, por lo menos, cuando comparas como abarcaron el 1 y el 2.

Por supuesto pueden ser datos obsoletos, haría falta una revisión con herramientas actuales, por eso pregunto.

Incluso en Cube se dijo oficialmente entre 6-12 Millones, con la competencia vendiendo los ¿66M?...y bueno ahora con modelados en mano, se puede ver cierta tendencia a un salto 10x, 20x como mucho con respecto a los 32/64 bit, sumando mejores efectos, mejores texturas, más resolución y muchos más juegos a 60fps, que no es poca cosa.

Por ejemplo vemos una extracción cualquiera, como el Haunting Ground (2005) de PS2, en una sala bastante compleja, falta el perro y Daniela, pero a lo sumo y revisando otras áreas, vi que es un juego que ronda un 1M quizás?, a ciertos niveles ya es difícil tener una cuenta precisa, siendo muy bueno técnicamente.

La sala


Un viaje (la extracción apunta al lado contrario de la sala, supongo que de todas las tomas me quedé con la de mayor peso)

Yo leyendo revistas retro me quedo con una entrevista a dos de Psygnoises de la época, sino recuerdo mal acababan de lanzar Colony Wars y entre las muchas perslas soltadas estaba que hasta ese momento sólo habían usado el 40% de la consola y que todavía quedaba mucho margen.

Yo no he llegado a tanto tecnicismo como vosotros porque no controlo, pero sí que pillé el excel de datos técnicos de juegos de Saturn y ya señalé que desde su lanzamiento ya tuvo juegos que rozaron su máximo polycount y de hecho, solían ser de los peores, los juegos que visualmente parecieron mejorar y empujar el sistema más que al comienzo usan menos geometría. De hecho sino me falla la memoria el mejor ejemplo eran VF, VF Remix y VF2 cada uno mejor "graficamente" que el anterior y sin embargo con menos geometría.

Yo creo que la bola o leyenda urbana que nos comimos es que por algún motivo hacían juegos con "underclock" voluntariamente pese a que casi ninguno de esos juegos iba a 60fps por ejemplo que sería lo más fácil de mejorar sin rediseñar geometría y texturas por ejemplo. Y la realidad era que se las veían y sudaban para terminar los juegos y que funcionasen "bien" en el hardware patata que teníamos al 90-100% y con los años iban aprendiendo a optimizar y mejorar para que ese 90-100% se usase mejor y ya.

Edit: Y por eso no me creo nada de lo que dice Yu Suzuki. De hecho me gustaría saber si la geometría de los ports de GTAIII y VC de Dreamcast es igual o mayor a la de los Shenmue por ejemplo.

@Conker64
Nunca me he fiado de esos test si no te dicen las condiciones completas, qué tamaño tienen esos polígonos? que tamaño tienen las texturas? Se han calculado esos polys o se han dado unas coordenadas fijas en pantalla? Esa textura estaba en cache? Etc…

Para mí, para considerarles “top” dentro de la categoría de “mover polígonos” la camera tiene que poder moverse. Por ejemplo en Tobal ya sabes que todos los polys de los personajes están dentro del Frustum o no tienes que hacer backface culling de los escenarios y eso te ahorra una cantidad considerable de ciclos. Si los juegos no ofrecen esa libertad, los resultados son poco extrapolables a cualquier otro genero de la plataforma.

Creo que en general, en ps1 es mucho más fácil desmentir bulos a día de hoy porque los emuladores te ofrecen un montón de posibilidades, por ejemplo en psx-redux puedes ver la etapa de renderizado polígono a polígono como lo hace la GPU (https://youtu.be/EwpFdMJlVP4?t=118).

Dentro de ps1 el motor que más me impresionó ha sido el de Spyro que mueve unos 2000 polys (algo más de 3000 triángulos), algunos son sin textura pero a una resolución horizontal de 512px. Dentro de esos polígonos, algunos son creados por la necesidad de teselar y luego por la necesidad de tapar las “T-Junctions” como resultado de la teselación, que eso no pasaría en n64 (salvo que quisieses teselar para simular texturas de más resolución).

En Saturn sería el Sonic R que mueve unos 2800 tris, aparte iría el suelo y el skybox generado por VDP2. Hay algo de teselación también y algún triangulo puro cuenta como quad, pero respecto a ps1 se compensa con el hecho de que el VDP2 tiene corrección de perspectiva así que esos trozos del suelo no tesela. Saturn es otra consola a la que los emuladores no acompañan y desmentir cosas es bastante difícil, para contar los polys de Sonic R tuve que abrir Yabause y contar los paquetes uno a uno, no sé cuantas veces perdí la cuenta y volví a empezar, menos mal que hubo otro idiota como yo que los contó y los resultados dieron parecidos.

Pero, sí, en general estoy de acuerdo que entre 60 y 75k tris era la normal de los juegos respetables para PS1, con algunas excepciones. Para Saturn un poco por debajo en general pero más que por incapacidad de la consola por la complejidad de sacarle jugo.

Sobre la 6 generación estoy bastante perdido, una vez porté el homebrew que tenía a Dreamcast y mientras me iba a 30 fps en ps1 me costó que llegase a 60 en Dreamcast, pero también es verdad que usé una versión de KOS bastante antigua y que no le metí ni de cerca el mismo tiempo que le metí a ps1. Así que no sé, he leído a gente decir que Dreamcast llega a los 3M pero ya dejo a otro que lo desmienta o lo confirme

@SuperPadLand
Siempre me ha resultado gracioso cuando dicen “solo hemos usado el X%”, no sé, si fuese su jefe diría “porque no lo habéis usado todo?, para quién se lo guardáis?”

Otro que me decepcionó fue Messiah, prometían una tecnología que permitiría modelos con polígonos similares a los de las cinemáticas en tiempo real (https://youtu.be/Ab6asTadPx0?t=969) y al final se canceló en ps1 y lo que salió en PC me pareció bastante normalito.

Misscelan escribió:@Conker64
Nunca me he fiado de esos test si no te dicen las condiciones completas, qué tamaño tienen esos polígonos? que tamaño tienen las texturas? Se han calculado esos polys o se han dado unas coordenadas fijas en pantalla? Esa textura estaba en cache? Etc…

Para mí, para considerarles “top” dentro de la categoría de “mover polígonos” la camera tiene que poder moverse. Por ejemplo en Tobal ya sabes que todos los polys de los personajes están dentro del Frustum o no tienes que hacer backface culling de los escenarios y eso te ahorra una cantidad considerable de ciclos. Si los juegos no ofrecen esa libertad, los resultados son poco extrapolables a cualquier otro genero de la plataforma.

Creo que en general, en ps1 es mucho más fácil desmentir bulos a día de hoy porque los emuladores te ofrecen un montón de posibilidades, por ejemplo en psx-redux puedes ver la etapa de renderizado polígono a polígono como lo hace la GPU (https://youtu.be/EwpFdMJlVP4?t=118).

Dentro de ps1 el motor que más me impresionó ha sido el de Spyro que mueve unos 2000 polys (algo más de 3000 triángulos), algunos son sin textura pero a una resolución horizontal de 512px. Dentro de esos polígonos, algunos son creados por la necesidad de teselar y luego por la necesidad de tapar las “T-Junctions” como resultado de la teselación, que eso no pasaría en n64 (salvo que quisieses teselar para simular texturas de más resolución).

En Saturn sería el Sonic R que mueve unos 2800 tris, aparte iría el suelo y el skybox generado por VDP2. Hay algo de teselación también y algún triangulo puro cuenta como quad, pero respecto a ps1 se compensa con el hecho de que el VDP2 tiene corrección de perspectiva así que esos trozos del suelo no tesela. Saturn es otra consola a la que los emuladores no acompañan y desmentir cosas es bastante difícil, para contar los polys de Sonic R tuve que abrir Yabause y contar los paquetes uno a uno, no sé cuantas veces perdí la cuenta y volví a empezar, menos mal que hubo otro idiota como yo que los contó y los resultados dieron parecidos.

Pero, sí, en general estoy de acuerdo que entre 60 y 75k tris era la normal de los juegos respetables para PS1, con algunas excepciones. Para Saturn un poco por debajo en general pero más que por incapacidad de la consola por la complejidad de sacarle jugo.

Sobre la 6 generación estoy bastante perdido, una vez porté el homebrew que tenía a Dreamcast y mientras me iba a 30 fps en ps1 me costó que llegase a 60 en Dreamcast, pero también es verdad que usé una versión de KOS bastante antigua y que no le metí ni de cerca el mismo tiempo que le metí a ps1. Así que no sé, he leído a gente decir que Dreamcast llega a los 3M pero ya dejo a otro que lo desmienta o lo confirme

@SuperPadLand
Siempre me ha resultado gracioso cuando dicen “solo hemos usado el X%”, no sé, si fuese su jefe diría “porque no lo habéis usado todo?, para quién se lo guardáis?”

Otro que me decepcionó fue Messiah, prometían una tecnología que permitiría modelos con polígonos similares a los de las cinemáticas en tiempo real (https://youtu.be/Ab6asTadPx0?t=969) y al final se canceló en ps1 y lo que salió en PC me pareció bastante normalito.

Es que es eso, si tu juego no va a 60fps, tiene popping, etc. Y dices que has usado solo el 40%... ¿Eres tonto o te lo haces? Es que vamos si no quieres meter más cosas en el juego pues vale, pero sube la resolución y el framerate entonces.

@Misscelan
Si, claro, sin saber las condiciones todos esos números no valen para nada, era más para entrar en el juego de la publicidad engañosa, de lo que se suele decir por internet, la maquina de los 100K la N64, la de 140K la Saturn y la de 180K la PSX, en el sentido dame un dato de "mundo real".

Aunque como ya hemos visto, luego la mayoría del catálogo suele estar sobre 60K, en muchos casos siendo picos de geometría, porque he llegado a ver cosas a 2K con bajadas de rendimiento.

Por otro lado tenemos los modelados, que yo creo que es un buen indicativo y un dato más fiable que una escena 3D, en algunos juegos el protagonista puede ser de 276 tri como Lara Croft o 752 como Mario, siendo 1000 en juegos con escenarios prerrenderizados como Resident Evil, o más cerca de 2000 en los modelados de Turok 2 (intro controlada), la demo del T-Rex (demo controlada), etc.

La gen 128bit es todavía más confusa, si que he llegado a ver 4 Millones en algún juego, pero también muchos a 250K, 300K, 500K o el ejemplo que puse antes que igual ronda 500-750K según el caso.

Ahí las cifras comerciales eran unos 3M Dreamcast como comentas, entre 6-12M Cube, en PS2 usaron erróneamente el dato de ¿66M? en la misma comparativa, creo que fue en Hobby Consolas, luego decían por foros y diversos sitios que con "todo activado" eran 20M, y Xbox ya era un desfase que no recuerdo.

Por lo que vi, Dreamcast no llegaría a esos 3M (la suelo ver por debajo de 1M, a veces muy por debajo), PS2 quedaría extremadamente lejos de la marca 20M (entre 0,5 y 3-4 quizás?, necesito ver más), y Cube no queda tan lejos de los teóricos 6M (RE4 en algunos puntos, cuando se lía de gente y tal, era bastante denso, y por supuesto otros juegos exclusivos del sistema), Xbox me parece una incógnita la verdad, pero a suponer debería estar por encima si no se lía a usar efectos avanzados.

En cuanto a modelados es lo comentado, normalmente 10x o 20x sobre la anterior generación, donde un muñeco era de 200 ahora podría ser de 2000, los NPC suelen ser 1000-2000, los protagonistas de algunas aventuras, entre 4000 y 8000, siempre hablando de modelado completo.

Y en los casos que pueden centrar más detalle por usar escenarios prerrenderizados como RE Remake, las cifras ya se elevan a casi 15000, creo que es de los máximos exponentes de esa generación:

@Conker64
Interesante lo de la 6ª generación. Creo que refleja como de rápido se movía todo, parece indicar que casi hubo el mismo salto de PS1 a Dreamcast – Que de Dreamcast a Xbox.

Con los límites de polígonos, tú querrías analizar esos datos, primero dando a entender que nacieron de manera consciente y con la intención de engañar desde los creadores de las consolas y que luego eso ha transpirado a la cultura popular y muchos usuarios las usan como armas arrojadizas? Tipo la “Saturn puede hacer 140k y la Nintendo 100k, así que la Saturn es mejor”, algo así?

En gran parte concuerdo contigo, puede que en la cultura general exista esta idea de que PS1 y Saturn mueven más polígonos. También creo que el posicionamiento de marketing de Nintendo no iba con la idea de defenestrar el poly count de la competencia, si no de darles en la calidad por pixel. Es muy difícil ver en una review de n64 la época el supuesto límite teórico de polígonos (de hecho es que no he encontrado ninguna), pero todas hacían mención a la corrección de perspectiva, el filtrado de texturas, el z-buffer etc..., pero creo que ese debate sobre coger con puntillas algunos datos y usarlos sin contexto se usa en todas las consolas y todos los aspectos de su parte técnica.

En el caso de los polígonos por segundo, por ejemplo, Nintendo si menciono ese dato de forma claro en los documentos a los que tenían acceso los desarrolladores:
“Before focusing on the graphics microcode, it is useful to review the global RCP graphics features: several thousand polygons per frame. (> 100K polys/second)” (también es una cifra que parece más realista hoy que cuando salió la N64 con los microcódigos originales)

Para PS1, dentro de los documentos técnicos no encuentro mención a esta información. Pero se puede encontrar dentro del bulleting board interno que usaban los dev y donde gente de Sony también se mostraba y aclaraba alguna info (esta es la respuesta de alguien que trabajaba en Sony):

Aquí parece hablar de que en un escenario real el límite estaría en 80/90k, y que a medida que las herramientas mejoran y demás, se podrían ir acercando al supuesto límite teórico de 120k. (GT3 es Gouraud Textured Triangle).

Los datos que salen en la Wikipedia vienen de revistas, que seguramente vengan de algún documento que Sony sacó en algún momento, pero son difíciles de interpretar (en el ejemplo de ps1 habla por ejemplo de GPU y de Sprites y es de un extracto de Electronic Monthly Magazine).

Para Saturn no he encontrado nada dentro de su documentación oficial, y los datos de Sega Retro, son también de revistas, y puede ser un caso similar al de Sony, de qué se habla aquí, de lo que puede hacer la GPU, la CPU+GPU, etc?

De dudosas referencias tampoco se libra Nintendo, en la página de la Wikipedia en español (https://es.wikipedia.org/wiki/Nintendo_64). Por ejemplo te pone que renderizando como si fuese una ps1 la cifra teórica era de 500k, me imagino que se refieren a usar gspTurbo3D, que según los documentos internos debería andar por los 300K (otras referencias como Beyond3d o NeoGAF le dan incluso más: 600k). Esto también forma parte debate sobre la calidad de los pixels.

No ya los 500k que se mencionan en la Wiki, los 300k en turbo, como los 180k en ps1 o los 140k en Saturn, me despiertan dudas y me huelen muy mal, pero no puede desmentir eso categóricamente porque no sé realmente sobre qué condiciones se habla. Lo mismo en los tres casos tenían internamente un clon de un mahjong sin texturas

Esto desgraciadamente no se limita a los polígonos por segundo, siempre se sacan de contexto los aspectos técnicos: mhz, número de procesadores, RAM, caches, resoluciones, etc… pero esto nos daría para un hilo separado.

En el ejemplo que puse sobre Vagrant Story, en los foros de Beyond3d se decía que el desarrollador dijo que eran 3k por frame. Lo abres con un emulador, lo juegas un poco con las estadísticas activadas y ves que era mentira cochina.
Si tú por ejemplo has oído de algún juego de Saturn o Ps1 que te despierte sospechas podemos darle un análisis más en profundidad aquí entre todos. Porque yo por ejemplo no puedo hacer análisis del framerate.

Respecto a lo de los niveles, ahí concuerdo un poco menos. Todo aporta, en algún momento de la vida de PS1 se empezó a usar teselado adaptativo (ósea en vez de decir subdividir cada quad en, por ejemplo, 4x4, se estimaba el área del polígono en pantalla y se dividía en base a eso) con eso podías poner polys más grandes sin afectar demasiado al warping, pero su uso no fue muy adoptado porque al final un nivel adecuadamente teselado y uniforme puede aportar varias cosas:
-Los entornos orgánicos como por ejemplo una loma quedarán mejor representados:


-Los efectos de iluminación quedarán mejor y serán más rápidos sin la necesidad de teselar en tiempo real:


-Y la más importante de todas, podrás implementar con facilidad una de las palabras más usadas por Señor Ventura: Ambient Oclussion (así como hacer un bake de los lightmaps a los vertex colors):


Por cierto tenemos que actualizar esas herramientas eh Conker https://i.imgur.com/qIuCcki.png

600 mil poligonos sin postprocesos no se lo puede creer nadie... 300 mil estaría bien que ocurriese, pero por lo que os leo, solo si hay muchos polígonos pequeños (siempre podría estar bien para precisamente dibujar mas lejos el horizonte, no sería una mala cosa).

Algún día veremos tests en "modo ps1".

Misscelan escribió:Con los límites de polígonos, tú querrías analizar esos datos, primero dando a entender que nacieron de manera consciente y con la intención de engañar desde los creadores de las consolas y que luego eso ha transpirado a la cultura popular y muchos usuarios las usan como armas arrojadizas? Tipo la “Saturn puede hacer 140k y la Nintendo 100k, así que la Saturn es mejor”, algo así?

Así es, era por el simple hecho de debatir esos números de revistas y compararlos con el mundo real.

Misscelan escribió:Por cierto tenemos que actualizar esas herramientas eh Conker https://i.imgur.com/qIuCcki.png

Mea culpa, últimamente tengo la cabeza como un bombo y todo este material me queda muy antiguo, ahora ando con Android y otras plataformas, lo que me sorprende de esa cifra que di... es que es de un test real:


El debug si mal no recuerdo eran poly/s en escena, máximos alcanzados en la sesión y el límite, a partir de 2000 los más lejanos se eliminaban, lo cual cerca el limite sobre los 60K.

Misscelan escribió:Esto desgraciadamente no se limita a los polígonos por segundo, siempre se sacan de contexto los aspectos técnicos: mhz, número de procesadores, RAM, caches, resoluciones, etc… pero esto nos daría para un hilo separado.

Sí, cuando no eran los bits, eran el números de colores en pantalla, el blast processing, el cerebro de la bestia.. con la llegada del 3D, que si número de polys, de efectos, más tarde los flops y ahora a saber.. supongo que compiten por ver quién pone los juegos más caros.

Señor Ventura escribió:600 mil poligonos sin postprocesos no se lo puede creer nadie... 300 mil estaría bien que ocurriese, pero por lo que os leo, solo si hay muchos polígonos pequeños (siempre podría estar bien para precisamente dibujar mas lejos el horizonte, no sería una mala cosa).

Algún día veremos tests en "modo ps1".

En la documentación hay gráficas de rendimiento de los chips VS atenuantes, como el tamaño del triángulo, aquí puedes ver un ejemplo (se puso hace tiempo):



Un triángulo de 2x2 casi ni llega a punto de la pantalla, no tendría mucha gracia tener muchos de esos si no van acompañados de otros más grandes.

En cuanto a los 300K, si cuentas rectángulo como polígono, ya en las primeras demos que hice como en esta pongo copitos 6450x50 = 322500 (y no era el límite), los monté de 4x4, luego empecé a subir a 8x8, 16x16, para analizar donde decaía el rendimiento, la info la tendrás por las primeras páginas del hilo.


Luego a nivel de optimización ese test no era nada, ni había empezado a limpiar la libdragon, ni a revisar las funciones, ni crear nuevas, ni a usar el hardware más a fondo, los rectángulos son más rápidos que los triángulos, pero te haces la idea.

En un escenario real y fuera de un test, que supongo que es a lo que te refieres todo esto ya es más alejado de conseguir, si revisas la gráfica verás como decae el rendimiento dependiendo de la superficie, pero eso no es lo único, añade el programa: las colisiones, físicas, el audio, etc si optimizas todo eso, estarás un poco más cerca del pico teórico, pero prepara tiempo, como hemos visto en el caso de Mario 64, el tipo vive de ello?

Lo que tendría que hacer es reinstalar todo de nuevo, como sugiere Misscelan y ahí ya podrías ver rendimiento mucho más actualizado, pero toma bastante tiempo actualizarlo todo sin romper compatibilidad o todo lo que cambie a mano a bajo nivel, la verdad.

Muy buenos los últimos mensajes.

Siempre es un placer leer a @Misscelan por sus conocimientos técnicos aplicados a casos reales y a @Conker64 por su recopilación de datos exhaustiva y tan clara. Gracias de verdad por tomaros el tiempo de desarrollar la información de la forma más objetiva y precisa posible.

Yo no compraba revistas en la época ni tampoco tenía internet esos años, así que no sé qué cifras de triángulos por segundo se publicitaban. Años después y ya con internet en casa sí que recuerdo muy claramente la cifra de 360.000 polígonos por segundo de PS1 y para Nintendo 64 las cifras eran más bajas, desde 60.000 a 10.000 polígonos por segundo. No sé dónde las vi. Seguramente comentarios de foros o algún artículo de alguna web o blog que ya no se podrá consultar. También recuerdo el comentario de que N64 con polígonos del tipo PS1 alcanzaba los 500.000~600.000 polígonos por segundo.
Creo que estas características no se publicitaban mucho en esa época, y se centraban más en la tecnología CD en el caso de PS1 y en los filtros y efectos gráficos en N64.
En la siguiente generación sí que se hizo bastante hincapié en la velocidad de renderizado. No recuerdo la cifra que se dio para DreamCast (quizás 1.8 o 2 millones) pero sí que me suena que para PS2 dijeron la burrada 20 millones, que era una mejora x10 veces para un hardware que estaba "a la vuelta de la esquina" (luego tardó más). Lo que mostraba DreamCast era impresionante, pero PS2 prometía algo enormemente superior y la sensación era que había que esperar (esta historia me suena). No recuerdo las cifras que se dieron para GameCube y XBOX, pero seguro que oficialmente también salió algo.

En su momento, para PS1 y N64 tampoco era algo que se discutiera. Al menos a nivel de usuario en mi círculo cercano. Saturn ni la menciono porque no conocí a nadie que la tuviera. El consenso era que N64 tenía gráficos generacionalmente superiores por los escenarios sólidos y más grandes, texturas sin pixelizar, dientes de sierra disimulados, degradados más suaves y algunos efectos gráficos como las texturas con envmapping. Jugablemente también estaba un paso por encima gracias al stick analógico que permitía mayor libertad de movimientos. Ya digo que entre mis compañeros de clase y mi grupo de amigos sí que caló que una consola era de la generación de 32 bits y la otra de la generación de 64 bits, porque lo veíamos reflejado en lo que se veía en pantalla y en lo que jugábamos. Aún así la mayoría tenía PS1. A la N64 sí que le penalizaba no tener CD, ya en ese momento se veía como un paso atrás. Y todos queríamos jugar a todos los juegos porque era una época donde casi todo sorprendía, o mcuhos juegos tenían cosas chulas que los diferenciaban del resto. Tanto en PS1, como en N64, como en PC. Fueron unos años de locura en el mejor de los sentidos.

Con el paso de los años te vas interesando más en el catálogo de estos sistemas, en intentar comprender cómo funcionan, en cómo se veía limitado el diseño del juego por motivos técnicos y qué soluciones encontraban los desarrolladores para disimularlas o incluso superarlas. Incluso si encuentras las herramientas adecuadas a veces puedes probar las cosas tú mismo.
Volviendo al tema de los polígonos por segundo. En su momento no era algo que conociéramos ni le diéramos importancia. Incluso aunque sí que detectábamos problemas de rendimiento (decíamos que el juego se ralentizaba o que pegaba tirones) lo veíamos como algo inevitable porque pasaba en todos los juegos (o la inmensa mayoría) sin importar el sistema. Fijándome muchos años después, sí que se me queda la sensación de que PS1 mueve más polígonos que N64 (comparando juegos punteros) porque el rendimiento de entrada suele ser superior, los modelados de los personajes también parecen más elaborados en la mayoría de los casos (Perfect Dark sería lo más burro en este sentido) y está el tema de que deben de subdividir polígonos cercanos a la cámara para disimular la falta de corrección de perspectiva de las texturas (que es gastar polígonos "a lo tonto" y reduce el impacto visual que podría tener frente a un juego de N64). Luego con cifras en la mano parece que esa diferencia es mínima cuando hablamos de desarrollos punteros como habéis estado mostrando en estos últimos mensajes.

Leyendo ahora para ver si Gran Turismo 1 tenía o no vibración de lanzamiento he visto en la wiki esto:

Yamauchi estimated that Gran Turismo utilized around 75% of the PlayStation's maximum performance.[17]

Indica en las fuentes el nombre y página de la revista así por si alguno quiere consultarlo.


@Conker64 hace unos años me dijiste que quizás te era posible editar el alt64 para los flashcard chinorros para que usaran aceleración gráfica y que no fuera a pedales por los menús ¿Al final llegaste a hacer algo?

SuperPadLand escribió:Leyendo ahora para ver si Gran Turismo 1 tenía o no vibración de lanzamiento he visto en la wiki esto:

Yamauchi estimated that Gran Turismo utilized around 75% of the PlayStation's maximum performance.[17]

Indica en las fuentes el nombre y página de la revista así por si alguno quiere consultarlo.

Claro, porque solo le falta usar el decodificador de FMV como fondo para las carreras.

Habría que ver qué entiende esta gente por el 100% de cada consola.

Supongo que cuando se hablaba de porcentajes de esa manera era porque estaban seguros de que el código se podía optimizar y rascar algo más de rendimiento, pero al final creo que tampoco hubo mucha mejora en Gran Turismo 2. A éste no he jugado mucho, pero por lo que he leído desde siempre es que hay ralentizaciones que en GT1 era raro ver.
Hay que reconocer que hicieron un juegazo en una consola tan limitada... Es de los que siempre echo una partida cuando monto mi Psx.

@EMaDeLoC

Entonces el Tony Hawks de PSX usa el 100%, que proyecta videoclips en la pantalla del escenario School, xD

Salud,

Conker64 escribió:lo que me sorprende de esa cifra que di... es que es de un test real:

El debug si mal no recuerdo eran poly/s en escena, máximos alcanzados en la sesión y el límite, a partir de 2000 los más lejanos se eliminaban, lo cual cerca el limite sobre los 60K.

Tiene pinta de que esos números son correctos, solo que ahí ya se está aplicando el frustum y el backface culling, así que no te está contando nada de los polys de la parte frontal del modelo. Además normalmente si en el entorno de ps1 se habla de “polys” se pueden referir a cualquiera de los dos tipos (quads o triángulos).

Por ejemplo, esto es una captura de casi el principio de TR3. Primitives (polys) da 1611 pero triángulos da 2358. En este ejemplo más o menos la mitad son quads y la mitad triángulos.



El pico de 2000 con esta misma proporción se trasladaría a 90k, siempre y cuando funcionase a 30 fps en ese momento, cosa de la que tengo dudas. Al final, Tomb Raider era un FIFA de aventuras, tenías uno cada año, los pobres de Core estaban sujetos a bastante estrés y presión, sus juegos no son muy referentes en el tema de la optimización, uno de los casos más flagrantes es como manejan la subdivisión.
Cuando tú subdivides se genera esto (está un poco exagerado para que se entienda mejor, en realidad es una línea que suele no ser más de un pixel de alta):



Esto es lo que se conoce el argot de 3d como una “T-Junction”, si el punto medio se queda por encima del otro polígono pues no pasa nada, pero si queda como en la foto se crea un agujero. Esto pasa en todas las consolas (incluso en las actuales). En la quinta generación es un problema solo para PS1, Saturn tiene un raster horrible que pinta demás por todos los lados y con eso se tapa, y en el caso de N64 se camufla con el subpíxel y el antialiasing.
En la PS1 lo que se recomendaba hacer era crear un triángulo muy finito que tapase ese agujero. Pero si levantas uno de los polígonos subdivididos se ve lo que se hacía en TR:


Dibujaban el polígono entero sin subdividir por debajo, una forma muy rápida de tapar agujeros, pero eso significaba que todos los polys cercanos a la pantalla (los más grandes) se dibujaban enteros 2 veces, desperdiciando fillrate a lo loco.

Y para explicar porque existe un límite de polígonos.



Esto es un extracto del código fuente de TR3 que se filtró hace mucho tiempo:
Hay principalmente dos cosas interesantes ahí:
-ot[OTSIZE] representa un array donde se almacena el primer elemento con esa profundidad (lejanía a la cámara). Tomb Raider tiene 2560 niveles de profundidad. El juego deja de renderizar cuando la Z es mayor que 20480 unidades. Osea tú cojes por ejemplo un quad calculas la media de su Z y en este caso la divides entre 8 (20480/8 = 2560) y almacenas ese poly en esa posición (si hay otro ya, haces que el nuevo tenga un link al viejo). Podrías tener la mitad de niveles de profundidad (1280) y si quieres tener el mismo nivel máximo de Z (20480) entonces tendrías que dividir entre 16 antes de insertar en el ot[].
Si quisiese podrías crear 65536 niveles de profundidad (el número máximo de 16 bits, y el límite para ambas Ps1 y N64 si se usa el GTE y microcódigos estándar), pero en el caso de PS1 esto sería un despilfarro porque no almacenas la profundidad de cada vértice sino una media del polígono.
Como anécdota, Hyrule Field de punta a punta casi llega el límite máximo de los 65536. Me imagino que quisiesen hacerlo todo lo largo que el microcódigo actual daba.
-El otro valor polyGT4[NUM_POLYS], define un array con el número máximo de polígonos que quieres almacenar en un frame, en este caso 2048. El límite que se muestra en el juego es un poco menor porque se pueden mandar otros paquetes que no son polys para activar tilling, masking, cambiar resoluciones, etc…

Hay una copia de ot y polyGT4 por cada frame buffer. Todos los juegos de PS1 tienen que tener un límite de polys por esta razón. Cuantos más pequeños sean esos dos valores, menos tiempo tardarás en enviarlos a la GPU y limpiarlos después (y menos memoria usas), así que normalmente se empiezan con valores altos y vas midiendo el número máximo de polys que tienes y vas ajustando. Y lo mismo con la ot, vas reduciendo hasta que algún polígono salta encima de otro de manera muy obvia.

SuperPadLand escribió:Leyendo ahora para ver si Gran Turismo 1 tenía o no vibración de lanzamiento he visto en la wiki esto:

Yamauchi estimated that Gran Turismo utilized around 75% of the PlayStation's maximum performance.[17]

Indica en las fuentes el nombre y página de la revista así por si alguno quiere consultarlo.

Sí, esa es la razón por la que puse lo de GT2 arriba. Esos comentarios los hizo como propaganda del segundo, diciendo que en GT2 intentaría sacar el 25% restante (son de este número de Edge https://retrocdn.net/images/a/ae/Edge_UK_068.pdf)

Y creo que nacen también como una propaganda al Performance Analyzer (https://archive.org/details/SCE-PerformanceUser-Aug1998/mode/2up) , un devkit que daba información de accesos a todos los componentes del sistema, cache misses, buses etc…

Con ese devkit “supuestamente” determinaron que Tekken 2 usaba entre el 30 y 40% y que Tobal 2 el 90% (https://www.timeextension.com/features/the-playstation-performance-analyser-ken-kutaragis-secret-weapon-in-the-32-bit-war)

Al final, era una ayuda sobre todo si acababas de empezar con ps1, pero los que llevasen un tiempo seguro que ya tenían formas manuales de saber principalmente donde se les iba el mojo. Al final un nuevo o mejor algoritmo suele marcar más la diferencia y eso no te lo da el Analyzer.

@Misscelan
Muy interesante , si, el debug no es código inyectado o datos de emulador sobre el juego, es un debug que dejaron los desarrolladores, como mucho podríamos tratar de deducir si es lo que comentas de los polys o si realmente funciona bien, a veces me he encontrado herramientas rotas, los análisis que hacía al principio eran basándome en datos que sacaba de debugs que habían dejado a escondidas los desarrolladores, luego los comparaba con las extracciones para interpretar mejor.

A veces sacaba los códigos de TCRF, otras veces tocaba esforzarse un poco más.

Hay una web bastante conocida que supongo que ya conocerás, models resource , ahí tienen un puñado de modelados de personajes y escenarios extraídos normalmente en OBJ, a suponer con las herramientas que suelen verse en rom hacking u otros lugares, y de bastantes plataformas distintas, entre ellas de las 128bit, o incluso más modernas.

Si te apetece analizar más geometría con tu entorno, la taberna del Conker Bad Fur Day (el menú) es un sitio bastante interesante, tiene más puntos a lo largo del juego, pero ahí se llega nada más empezar.

@SuperPadLand
Conseguí todas las portadas de las cajas de los juegos, las convertí a texturas de N64 pero creo que nunca llegue a ponerme a montar el menú.

Mi idea era hacer un menú de 0, y montar proyectos separados, para que fuera compatible con la lectura SD del Everdrive, el chino, la Summercart, etc según el z64 generado, para ello es más que probable que necesitara una muestra de cada uno.

A veces pienso que si tuviera un Patreon y me dedicara solo a esto la de cosas que habría sacado

Alt64 creo que sería bastante trabajo para poco resultado, un menú moderno y dinámico con portadas creo que podría lucir más.

Sogun escribió:Fijándome muchos años después, sí que se me queda la sensación de que PS1 mueve más polígonos que N64 (comparando juegos punteros) porque el rendimiento de entrada suele ser superior, los modelados de los personajes también parecen más elaborados en la mayoría de los casos (Perfect Dark sería lo más burro en este sentido)

A mi esa impresión solo me la da en casos concretos, como el Misión imposible, donde aprovecharon que PSX necesita más geometría en los escenarios para redondear detalles o incluso añadir efectos que no estaban en N64, como un cristal que refleja en un cuarto de baño.

Perfect Dark tiene buenos modelados como comentas, demasiado para lo que se suele ver en esa generación, en Goldeneye son más simples y los mueve mejor.

@Conker64
Es que en Perfect Dark cada enemigo con su arma tiene la carga poligonal de un personaje de un juego de lucha.

Hice una prueba hace tiempo vaciando los niveles de enemigos y objetos y comprobé que las "coronas" penalizan una barbaridad el rendimiento. Si hay una o dos en pantalla y son muy pequeñas no baja el rendimiento; pero cuando hay varias y son grandes te puede bajar el framerate a la mitad. Así que hice otra prueba eliminando también las coronas y la mayor parte del tiempo el juego corría a 30 fps salvo en zonas muy grandes y abiertas (Villa y el nivel donde se estrella el Air Force One).

Pero lo que me sorprendió para mal era cómo se arrastraba el nivel del Air Force One. Extraje la geometría en un emulador a ver si estaba cargando partes del nivel que quedaban fuera de la vista de la cámara pero no era así. Luego me puse a portear el nivel al GoldenEye que por la forma que tiene de cargar los niveles quizás podría moverse mejor, pero era demasiado curro y lo dejé a medias. Igual lo retomo ahora que estoy volviendo a hacer cosillas.

Otra prueba que hice fue comparar el rendimiento de los niveles vacíos de GoldenEye en ambos motores gráficos. Se movían básicamente igual, normalmente a 30 fps y bajando a 20 en los mismos sitios. Había zonas en las que en GE bajaba a 20 pero PD se mantenía a 30, y otras zonas donde pasaba al revés. Especialmente curioso el caso del final del nivel de Bunker, la zona exterior donde acaba el nivel. En GE se mueve a 60 fps si no miras a la puerta del bunker, pero en PD en todo momento funciona a 30 fps. Es como si GE sólo tuviera en memoria los trozos de nivel que se ven directamente (y está cargando y descargando parte del escenario constantemente) mientras que PD además gestiona trozos del escenario cercanos aprovechando que usa más RAM (se ve que para ayudar en la descompresión de datos).

---

Ya que comentáis acerca del funcionamiento de juegos de PS1. ¿Habéis echado un vistazo alguna vez a Crash Team Racing? Es un juego en el que me he fijado últimamente y su motor me parece una pasada. Usa teselación de verdad de la buena, nada de subdividir cuadrados planos. Aquí los nuevos vertices modifican sus coordenadas para suavizar las curvas. El escenario es más simple a lo lejos y se va haciendo más complejo sin transiciones según se acerca a la cámara. También usa una suerte de mipmapping. Las texturas pueden ser enormes, de hasta 256x256 y tienen otros dos niveles más pequeños de 64x64 y 12x12. Luego durante la carrera transicionan de forma suave de unas a otras usando semitransparencias. Y el juego renderiza a una resolución de 512x240 y se mueve a 30 fps (no lo he jugado en hardware real, así que no sé si se ralentiza a menudo, pero creo que no).
-Se pueden descargar las extracciones de los circuitos de aquí. Yo me fijaría en Coco Park que es donde he visto las texturas más grandes y los casos de teselación más claros.
-Vídeo de Coco Park en emulador en alta resolución. Mirad los árboles de la derecha nada más empezar o las filas de estructuras rosas con espirales a la izquierda en varios puntos del circuito. Los elementos más alejados tienen picos muy pronunciados, pero todo se redondea según se acercan. Aquí el circuito jugado en wireframe, aunque hay tantos artefactos de compresión que no se aprecia mucho (el primer nivel del vídeo sí que se ve nitido).
-El mismo nivel en hardware real. Aunque están jugando en una PS2, que supongo que mejora la imagen pero no se sí mejora otras cosas. Se puede apreciar lo que digo del mipmapping en las texturas de flores de las laderas. En la distancia están borrosas, pero luego transicionan suavemente a las texturas de alta resolución. Y por último el mismo circuito en calidad guarra, éste sí que parece capturado de una PS1 por video compuesto, que sería como lo jugó la mayoría en su momento. Aunque el video tiene el aspect ratio desajustado. Se ve muy sólido para ser un juego de PS1.

Supongo que que sea un juego de carreras, con escenarios controlados y donde se sabe en todo momento la posición del personaje relativa a los objetos lejanos ayuda mucho a hacer funcionar al motor gráfico de la forma en que lo hace.
Rogue Squadron en N64 también usa teselación para redondear la forma de las montañas, aunque no aprovechó la subdivisión para tener texturas de diferentes resoluciones. El juego usa texturas de 64x64 a 16 colores que no pueden usar mipmaps y esto hace que haya mucho aliasing en la distancia. En el modo de baja resolución hay aliasing en toda la pantalla y parece un juego de PS1. Podrían haber aprovechado y cambiar a texturas de 32x32 con sus mipmaps y así eliminar el aliasing por completo.

Yo lo tengo reciente (en un crt) y se ve con mejor definicion en la tele
El framerate va a 30 estable no baja nunca excepto cuando usas reloj que se nota algo

@Conker64 podéis hacer un hilo con ese tipo de información (cantidad de polígonos que sacaban estás consolas ps1,Saturn,n64, dreamcast,etc)?

Me parece interesante ver lo que realmente sacaban estás máquinas y lo que nos vendían las compañías, aún recuerdo la publi de ps2 y sus 75 millones de polígonos xD

bluedark escribió:Supongo que cuando se hablaba de porcentajes de esa manera era porque estaban seguros de que el código se podía optimizar y rascar algo más de rendimiento, pero al final creo que tampoco hubo mucha mejora en Gran Turismo 2. A éste no he jugado mucho, pero por lo que he leído desde siempre es que hay ralentizaciones que en GT1 era raro ver.

¿Pero sí estaban seguros de que podían optimizar el código, porqué no lo optimizaban desde el principio?
A mí me suena más a marketing. En plan "mira el juego que hemos hecho en PS1 y solo hemos explotado 3/4 de su potencial!! eh! eh! mira aquí, a la PS1!! no, no mires la N64!! Aquí, la PS1!"

Es que además lo del 100% no puedes conseguirlo. Por ejemplo, para que la memoria RDRAM rindiese al 100% habría que leer y escribir paquetes de 512 bytes siempre. Aún si pudieras mandarle montones de triángulos o texturas en paquetes de 512bytes, rara vez el RCP te va a pintar 512bytes de pantalla seguidos de una vez. Para que el RCP rindiese al 100%, tendría que estar dibujando continuamente en condiciones especiales que no son viables para un juego, etc. Y así pasa igual en todos los sistemas.

Kaze consiguió optimizar todo hasta llevarlo casi al 100% todo, pero sigue con cuello de botella en la memoria por lo que todavía se le quedan tiempos muertos en CPU o RCP. Al final la consola va tan rápido como le deje su parte más lenta, que paradojicamente en la N64 es la memoría más rápida que existía en 1996...