Hilo de detalles y curiosidades de N64

@Conker64
Esto es una extracción de la caverna que aparece en el menú. Hay otras habitaciones que no están conectadas físicamente. Unos 9k polys tiene el export.


Aquí se puede ver el clásico efecto de reflejo antes de que los cubemap y el raytracing vinieran a atormentarnos.


Dentro de la taberna si tomamos, si posicionamos la cámara en la entrada y descartamos los polys que no tocan, se nos quedan en unos 4200:


Después hice una captura nada más empezar el juego, en esta posición:


Prácticamente todo el nivel se manda al RSP, no parece haber mucho o ningún culling antes (la escena entera son unos 3600 triángulos):


El modelo de Conker son 844:


El modelo utilizado para su sombra son 131:


La sombra parece funcionar proyectando un cubo sobre el escenario (desde el foco de luz en dirección a la posición de Conker) y generando nueva geometría en los puntos de corte, una cámara renderizará el modelo de la sombra desde la posición desde donde se proyecta ese cubo a una textura que luego se aplica sobre esa nueva geometría generada.

La escena inicial parece renderizar unos 1900 polys:


@Sogun Curiosamente implementé ese método en mi homebrew aquí lo explico brevemente (https://youtu.be/BvG-71v-b0o?t=30) También funciona en N64 aunque el video es de la versión de hace un año (https://youtu.be/NFK9DnI3cPk?t=53).

Básicamente funciona como has mencionado, puedes agrupar texturas en filas, columnas o ambas siempre que el número de estas sea 1 o una potencia de 2. Por ejemplo puedes agrupar 4x4 quads, el sistema generará una única textura para la 4x4, cuatro texturas para el primer agrupamiento (2x2) y luego 16 texturas individuales (en el caso de que fuesen todas diferentes). Después el sistema morphea del de 4x4 al de 4x(2x2) y luego al de 16x1 dependiendo de la distancia a la cámara, el morphing se hace en screen space y también se hace morphing de los colores de los vértices. En Jak & Daxter esas agrupaciones se pueden hacer por triángulos también, en el caso de CTR solo para quads y con la única combinación de 2x2.

Como comentaste te quita la gestión manual de los mipmaps (en 64 lo gestiona el sistema solo, pero así tampoco tienes que usar ningún bloque de la cache con eso).

También te permite descartar grandes polígonos de golpe (puedes determinar si por ejemplo un 4x4 no está mirando la cámara y hacer backface culling de 16 polígonos de golpe, lo mismo para el frustum culling)

Aunque hay también un gasto extra por el morphing que en otros juegos no se haría.

En cuanto a datos del CTR, al parecer lo que más consume del juego es la IA de los enemigos. En el modo free-roaming he capturado unos 2500 triángulos:


Dentro de carrera solo he llegado a ver 2000. Una cosa interanste es que la gente que está trabajando en el dcomp al parecer tienen una versión que corre a 60 en hardware real: https://www.youtube.com/watch?v=d9psliWJ0es&ab_channel=Darkaiser pero no he podido comprobar su veracidad.

Misscelan escribió:Esto es una extracción de la caverna que aparece en el menú. Hay otras habitaciones que no están conectadas físicamente. Unos 9k polys tiene el export.

Ah sí, la habitación de arriba creo que es la de Berri, Conker llama desde la taberna en la intro, siempre me ha encantado eso de poner diferentes estancias y luego desplazar la cámara para hacer el cambio de escena.


La entrada que pones de la taberna, creo que era uno de los picos de geometría de esa escena, en su momento jugué con el debug activado durante largo y tendido (aunque se colgaba), y si mal no recuerdo ese momento funcionaba sobre los 17-20, 20 es bastante común en los puntos de estrés, aunque fluctúa como una montaña rusa.

EMaDeLoC escribió:¿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!"

No sé, puede ser lo que comentas pero yo lo veo bastante común, mis códigos a lo largo de los años cada vez han ido a mejor, más pequeños, más flexibles, más rápidos.. si tengo que montar ej. un plataformas normalmente me leo algo que ya haya hecho, como hice el motor de tiles, como interactúan los sprites con esos tiles para hacer las colisiones, las cuestas e inclinaciones.. y normalmente es en ese momento cuando me pongo a retocar.

Luego por otro lado si tienes fechas que hay que cumplir, se te puede encender la bombilla, pero muchas optimizaciones requieren cambios en muchas partes, como no estés fino y te olvides de algo viene la catástrofe, a veces es mejor eso de que si algo funciona no lo toques.

Suena raro, porque ahora te sacan los juegos rotos sin optimizar y lo hacen al final, pero antes no podías cargarte toda la producción de cartuchos o CDs por ello, optimizar puede traer errores.

Yo creo que cuando hablan pueden referirse a esto, o ser puro humo como comentas, a veces es en los siguientes juegos de la misma plataforma cuando se aplican esas mejoras y deberían ir mejor / verse mejor, o similar, aunque no siempre es el caso, o no siempre son el mismo equipo y la cosa se cae.

O´Neill escribió:@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

No sería mala idea, en su momento tenía pensado algo así, en models resource se pueden conseguir muchos modelados y visualizarlos con blender, para escenas y datos reales ya haría falta más análisis, más gente que participe.

Los modelados a partir de cierto nivel dejan de tener sentido, de 1000 a 10000 las diferencias son enormes, de 10000 a 20000, ya se reducen y así, pero de la generación 32bit a la 128bit es cuando se produjo todo ese maravilloso salto. (esta imagen es un clásico de internet, como gol de señor, pero sirve)


Lo de los 75 millones también me suena haberlo leído, ahora no recuerdo que Hobby Consolas fue, pero era entre el 2001 y el 2002, con una comparativa de todas las "128bit".

De hecho llevé la revista al instituto y todos quedaron maravillados con PS2 y esos números, se acompañaba una captura del Tekken Tag, en un escenario lleno de césped, que comparado con las 4 hojas que te ponían las 32/64bit parecían trillones, nadie dudaría de esas cifras.

Sogun escribió: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).

Me suena que vi un vídeo donde se eliminaban muchos elementos de las fases de Goldeneye, se dejaba solo el escenario y luego se medía el rendimiento, no sé si se puso aquí o lo vi yo por casualidad en Youtube.

Pero esa parte del Búnker que comentas salía y iba a 60.

@Misscelan

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

Hay muchos juegos cañeros @512x240 en PlayStation; los Spyro que comentas, los Tobal, Crash Racing Team, Rapid Racer, incluso Soul Edge:



Éste además es 1 portento en todos los campos; transparencias, fuentes de luz, polycount, texturas, etc.

Saturn cuando se pone tonta te planta entrelazados de hasta 704x448i, la mayor parte de veces en juegos de lucha eso sí, entornos que como tú bien has dicho son más controlables para el programador. Astra SuperStar (2D) te planta hasta 640x224 en progresivo si no recuerdo mal:



También me consta que a la Saturn conviene más ponerla @352 horizontales que @320 porque en este último se underclockean los SH-2 de 28 a 26 Mhz, sabe Dios porqué.

En cambio Nintendo 64 es aún un misterio para mí. O sea me consta que al igual que las otras su resolución "de confort" es 320x240p (352 en Saturn), pero más allá de ese ratio estoy perdido, y además me rayan cosas como ésta:

@Sogun

NTSC 440x330 "progresivo" con antialising

En referencia a la resolución intermedia en GoldenEye: 007.

Sí de verdad es cierto, entonces sería imposible de ver en los CRT de consumo en la época, ya 440x330p sería un rango de 24khz, y por ello necesitaría mínimo de un monitor trifrecuencia para poder visionarse, similar los que calzan las placas MODEL de SEGA (496x384).

¿Alguien me da un tour rápido de resoluciones en N64?

Nadie dice que saturn y playstation no metan 640x224, pero n64 lo hizo con todo un perfect dark.

Y la ampliación de memoria... pues bueno, la podias dejar en 8MB porque la podías dejar en 8MB, si no pudiera ampliarse si que sería una pega.

@Sexy MotherFucker
A nivel de código que es lo que yo controlo, te puedo decir que 440x330 sería el framebuffer y luego eso lo envías a VI (Video Interface), que se hace allí? Bueno basándome en los datos que hay (ultra64.ca):

42 Video Display Modes
The VI is responsible for displaying the RDP-rendered images in different video modes. Currently, VI supports 42 video display modes -- 14 for NTSC, 14 for PAL, and 14 for MPAL. Each mode contains different settings to handle attributes such as interlaced and non- interlaced, 16-bit and 32-bit color pixel, and low and high resolution. Furthermore, a mode can be configured to rescale the image to sacrifice resolution for rendering speed.

These supported modes can be represented by 5 switches:

high/low resolution
16-/32-bit color pixel
anti-aliased/point-sampled
filtered/not filtered
NTSC/PAL/MPAL format

Yo aquí veo 2 modos de vídeo, high y low resolution, según el documento:

Low

In low resolution (320 pixels by 240 lines), you have a choice between non-interlaced and interlaced mode. Non-interlaced mode repeats the same frame each field. Interlaced mode interpolates between adjacent lines, weighting 75% of the line above plus 25% of the line below in the first field, and then weighting 25% of the line above plus 75% of the line below in the second field. Note that there is no flicker because there are no high spatial frequencies.

High

In high resolution (640 pixels by 480 lines), you have a choice between normal interlace and deflickered interlace. Normal interlace uses just the data rendered in one field to display that field. This mode can use one high resolution frame buffer without additional double buffering because one field can be displayed while the next is being rendered without stepping on each other. However, any single pixel with high detail will flicker because it is only displayed in one field. Deflickered interlace averages adjacent lines to filter out the high frequency vertical detail, but at the cost of requiring double buffering of the entire high resolution frame because both rendered fields are used to display each field.

Da la impresión de 240p y 480i, luego configuras la interfaz para redimensionar el framebuffer o dejarlo tal cual si llena la pantalla, o con marcos negros si no queda muy lejos del target, además puedes establecer su posición, a partir de donde empieza a pintarse, para centrar imagen como hacen los Quake desde el menú.

Más info, de una entrevista de Nintendolife:

"The N64 has two possible output formats: 240p and 480i," Bartmann explains. "The most common rumour is that 240p is 320x240 pixels and 480i is 640x480, but that’s not true for 240p. If you take a look at Perfect Dark (NTSC version), in the menu you have the option to switch between high resolution mode and low resolution mode. However, the output is always 240p. So, what changes? Just the horizontal resolution, or not? The N64 has a constant pixel clock of about 12.5MHz in each possible resolution. So what’s going on here is 240p low resolution mode is 320x240, 240p high resolution mode is 640x240, and 480i is 640x480 – the horizontal resolution split in two frames, each frame with 640x240 – even and odd; that’s interlaced."

That's where Deblur comes into play. "What the N64 simply does in the 240p low res mode is that the console outputs 640x240, where in the horizontal direction every second pixel is a 'true' or 'useful' pixel and every other one just an interpolated version of the neighboured pixels," continues Bartmann. "This results into a blurry picture. However, if one blanks these interpolated pixels and simply holds the previous 'true' pixel, you can effectively "deblur" the image. The true challenge is to detect whether the 240p content is low res or high res.

Si hay más dudas (o errores en lo que pongo) creo que @radorn y @EMaDeLoC controlaban sobre este tema.

--
@Señor Ventura
No preocupare, estás en el hilo correcto

@Señor Ventura pero no son los 640x480i que tú decías, sólo quise corregirte éso. Bueno y también decir que en modo "hi-res" Perfect Dark se asfixia en muchísimas zonas, yo habiéndolo jugado en hardware real no sacaría pecho por ello...

En cambio @320x240 (218 en realidad) va decentemente.

Nintendo 64 es una máquina de 240p, asúmelo de una vez. Puede hacer sus "pinitos" en pseudo-hires como PlayStation con los Spyro, o Saturn con sus juegos de lucha 3D, pero enseguida la realidad las golpea diciéndoles que están volando demasiado lejos de casa, que aterricen antes de quedarse sin combustible. Lógicamente al ser más potente que las otras logra surcar un par de KM más, pero sigue sin ser capaz de cruzar el océano entero sin agotarse. N64 es una máquina de la misma generación que PlayStation, de la misma forma que Neo Geo era de la misma que SNES, MD, o PCE.

Ésta:



Sí es una máquina de 480p.
Sí pertenece a otra generación distinta.
Dreamcast hace realidad con creces todo lo que tú sueñas que a lo mejor puede hacer Nintendo 64; da la vuelta al mundo volando más alto.

Cómprate una N64 y JUEGA por Dios. Opina en base al planeta Tierra 🌍 No opines desde Marte xD

Y la ampliación de memoria... pues bueno, la podias dejar en 8MB porque la podías dejar en 8MB, si no pudiera ampliarse si que sería una pega.

Pero no se si pillas que no es algo opcional: sin Expansión no hay campaña en PD. Tú no puedes jugarla en una N64 de stock, tal cual. Tienes que doparla, al igual que pasa con ciertos títulos de Saturn.

Zelda Majora's Mask y DK64 directamente no encienden sin élla. En la época te obligaban a invertir en el pack de memoria si querías jugarlos.

@Conker64 gracias por responder tan rápido.

Según esos documentos... ¿Lo que haría el VI sería escalar y estabilizar un ratio a priori incompatible, haciéndolo compatible con los viejos CRT?

Eh, eh, yo soy un usuario de ultra 64, igual que todos los demás: tengo derecho a soñar.

Si, tendré mi n64 en un mueblecito, hay consolas que hay que probar, como la 3ds. No te lo pueden explicar, lo tienes que experimentar.

...pero es que no he dicho que 480i sea lo justo para perfect dark, solo he dicho en que contextos estas máquinas se atrevían con resoluciones mayores. No le pones un perfect dark a 640 vertical a cualquiera (¿640 entonces, pero menos resolución horizontal?).


No se, los pies los mantengo en el suelo, pero no queremos ser realistas, queremos pushing.

Me gustaría saber como rendiría una n64 sin postprocesos a 480i reales y 30fps estables, ¿con que tralla en pantalla?. ¿Ves?, no tiene nada de malo pensar estas cosas... es FE, si, pero también es sano.

No se muy bien qué puedo aportar aqui. Pero comentaré alguna cosilla a ver qué sale.

Como alguna vez expliqué, la N64 tiene un bus de audio y video con una frecuencia fija cercana a los 50MHz que es ligeramente diferente en las tres "regiones' de la consola (NTSC, MPAL y PAL). Digo bus AV porque tanto el bus de audio como el de video están alimentados por el mismo reloj. En cuanto al bus de video, se transmite un pixel cada cuatro ciclos de reloj (R G B y uno extra para sincronización y otras señales auxiliares que nunca llegué a entender). Esto resulta en un pixel clock cercano a 12.5Mhz. Calculando desde esa cifra redondeada, dividiéndola entre el refresco horizontal nominal de PAL y NTSC, no saldrían unos 800 y 794 pixels por linea. Tendría que ponerme a hacer calculos mas precisos con las frecuencias reales y datos a los que no tengo acceso, pero el concepto sería el mismo.
De todos esos pixels, según me dijo marshallh en su día, autor del 64drive y UltraHDMI, 640 pixels son visibles.
Eso es lo que se transmite ente el VI dentro del RCP al DAC SIEMPRE. Obviamente, cómo rellene esos pixels el VI según esté programado ya es otra cosa.

Yo nunca había oído eso de los 42 modos de video soportados por el VI. Yo entendía que era programable. Quizá esos 42 modos de video son las combinaciones documentadas, y que no está necesariamente limitado a ellas ni es que las tenga integradas dentro.
Como comprobamos por estos lares hace unos años, las configuraciones del VI que traían los juegos NTSC que al aplicarse a una consola NTSC producían 60Hz, en una consola PAL acababan produciendo unos 61.X Hz, y viceversa, las configuraciones PAL en hardware NTSC resultaban en 59.x, o algo así. Y esas cifras eran consistentes con las diferencias de velocidad del bus en las distintas variantes regionales de la consola (existentes porque de ellas también se derivaba luego la frecuencia de la portadora de color para compuesto y s-video en el DAC). Eso me dió a entender que el VI era totalmente configurable por software y que de alguna manera, teniendo un pixel clock fijo, podía "cortarlo" en lineas y cuadros a placer (lo que no quiere decir que el DAC lo fuera aceptar, o que aún aceptándolo, la TV pudiera tragar con el resultado, pero esas son otras cuestiones)

Cuando tenía el hardware e investiqué estas cosas, nunca vi un solo juego que tuviese 640x480 (o 640x576 para PAL) "reales" o sea, que el framebuffer no era de ese tamaño si no menor y luego el VI lo estiraba.
Y al colación de esto mencionto también que si que creo que el VI puede estirar cualquier resolución de freimbúfer arbitraria a la pantalla, y no está limitada a "algunos modos fijos", y lo deduzco por mi esperiencia usando una funcionalidad que tiene el ActionReplay / GameShark v3.3. SI alguno lo teneis probad esto: Al cargar un juego, con o sin trucos activos, activad el cheat generator. Esta funcion carga un loader trainer que se engacha al loop general de libultra para ejecutar su propio código. Una de sus funciones es que al presionar el botón del cartucho, se congela la ejecución del juego y se abre un menú con herramentas de visualización de memoria y comparación de valores para hackear trucos. Pero además, tiene una funcion extra para visualizar la memoria de la consola como si fueran gráficos del framebufer. Lo que hace es pasar una sección de la memoria al VI para que la muestre con la misma configuración gráfica que tenga el juego. y permite avanzar y retrocder por toda la memoria, aplicando incluso los bit extra de la RDRAM para la segunda capa de antialiasing, lo cual refuerza mi teoría de que esta funcionalidad simplemente pasa la sección de memoria que le indiques al VI de forma directa. La otra alternativa sería escalado por software, y creo que eso iría lentísimo.
Con esta funcion, se pueden visualizar todos los framebufers que haya en memoria (tipicamente 2, el que ya está completo y el que se está dibujando, que, dependiendo de en qué momento detengais la ejecución al presionar el botón, encontrareis a medio dibujar, e incluso podeis ver el z-buffer como imagen, resultando en un mapa de profundidad un poco extraño, al interpretarse como RGB15 siendo internamente valores monocromáticos de 16bits. pero se reconoce la escena claramente.

La cosa es que este visualizador de "gráficos" permite variar la ventana grafica no recuerdo si usando qué botones del mando, pero efectivamente cambiabas el punto de inicio, la longitud de linea (o sea, cuantos bytes/pixels de la memoria encajas por linea visible del VI) y la escala vertical, y era totalmente lineal y sin retrasos, totalmente 60Hz, lo cual me sugiere que realmente se limitaba a cambiar los parámetros del VI para pasar memoria a este como si fuera framebufer.

Lamentablemente no os puedo hacer una demostración al no disponer de nada de aquello ya. Quizá haya en youtube algo. Buscad ActionReplay o GameShark "code generator" e igual encontrais algo. O compraos uno y trastead.
Si ademas disponeis de un PC viejo con puerto paralelo con Windows 98, Me, 2000 o XP (estos últimos con algún programa de apertura de puertos legacy, porque los cierran por defecto), podreis incluso durante la ejecución del juego, mandar un comando con las utilidades del aparato (si las podeis encontrar) o puede que hasta ucon64, capturar un dump del framebufer como un BMP (aunque solo el RGB15, sin la segunda capa de antialiasing del VI porque dpende del bit extra de la RDRAM y ese no lo lee el software de la CPU, o no sin procedimientos extraños que KazeEmanuar recientemente documentó y no entendí)

En fin, además de eso, como ya he dicho alguna vez, hay juegos que hacen cosas muy raras con las resoluciones.
Primeramente no recuerdo ver un solo juego que en su modo de video entrelzadao tenga una relación 1:1 entre el framebufer y la pantalla (o quizá uno raro de ajedrez con personajes feísimos en las animaciones de cada movimiento), en "todos" los que investigué puede apreciar "artefactos" del re-escalado, como los que se ve en la mayoría de juegos PAL a pantalla completa sin barras negras, que son mas borrosos que NTSC porque reescalan en bufer que en NTSC es 1:1 con la salida 240p, pero en PAL se estiran a 288p con una relación 5 a 6, o sea, que cada 5 lineas originales, se producen 6 en pantalla y se puede ver un patrón de colores mezclados con esa cadencia si haces una buena captura de video.
Ni siquiera los juegos NTSC con modos 480i tienen un búfer 640x480. Creo que hasta el libro de los bomber de Majora's Mask renderizaba a una resolución inferior, aunque quizá me equivoque en ese caso y solo sea la versión PAL...
AProvecho para recordar la breve lista de juegos PAL con auténtica resolucion 288p: GoldenEye, Perfect Dark, Diddy Kong Racing, y el prototipo de 40 Winks. No pude encontrar ninguno mas, ni si quiera de Rare o EuroCom. Todos los demás a pantalla completa reescalan.
Y un par de curiosidades: El primer juego de Goemon en la consola, la aventura 3d de mundo abierto, en su versión europea PAL, observamos el tipico reescalado de 240 a 288, lo normal. La versión americana NTSC es 240p 1:1, lo normal. Pero la versión NTSC Japonesa original... por alguna razón incomprensible, renderiza a 240p, pero lo reescala a 480i en VI, introduciendo borrosidad innecesaria sin ganar nada. Como nota a pie de esto, a veces me preguntosi hubiera sido beneficioso en algún juego PAL reescalar los 240p originales a 576i en vez de a 288p. Quizá hubiese sido menos borroso el resultado, aunque de un cierto flicker no nos libraba nadie. La otra curiosidad es que Body Harvest, ya sea PAL o NTSC, ni siquiera usa tiene unframebuffer 240p, si no inferior, y todas las regiones reescalan... bueno, nunca se me dió por probar la japonesa, si es que la hubo, pero la EuroPAL y la USANTSC reescalan las dos, así que no es ni 240p internamente.

Conker64 escribió:In high resolution (640 pixels by 480 lines), you have a choice between normal interlace and deflickered interlace. Normal interlace uses just the data rendered in one field to display that field. This mode can use one high resolution frame buffer without additional double buffering because one field can be displayed while the next is being rendered without stepping on each other. However, any single pixel with high detail will flicker because it is only displayed in one field. Deflickered interlace averages adjacent lines to filter out the high frequency vertical detail, but at the cost of requiring double buffering of the entire high resolution frame because both rendered fields are used to display each field.

Recientemente Kaze Emanuar me respondió a esta misma cuestión en los comentarios de YouTube
https://www.youtube.com/watch?v=BA_HMsz ... IX4AnOePJA


Intenté encontrar a esa persona que menciona y esa técnica maravillosa, sin éxito. No tengo ni idea de qué forma se puede renderizar en entrelazado 1:1 en un sistema que ni de coña va a rendir a 60Hz 480i (campos de 640x240) o 50Hz 576i (campos de 640x288) sin perder ni un frame/field. Por que en el momento en que pierdas un paso se va a notar graficamente. No se cómo se "soluciona" eso. No lo veo ni lo he podido encontrar.

Bueno, en definitiva. Desconozco el aspecto programático de cómo se hacen estas cosas en la consola, pero mi experiencia de mucho trastear con la consola durante años es que el VI lo aguanta todo.

Sexy MotherFucker escribió:Según esos documentos... ¿Lo que haría el VI sería escalar y estabilizar un ratio a priori incompatible, haciéndolo compatible con los viejos CRT?

Espero que lo que he relatado te aclare algo

radorn escribió:Intenté encontrar a esa persona que menciona y esa técnica maravillosa, sin éxito. No tengo ni idea de qué forma se puede renderizar en entrelazado 1:1 en un sistema que ni de coña va a rendir a 60Hz 480i (campos de 640x240) o 50Hz 576i (campos de 640x288) sin perder ni un frame/field. Por que en el momento en que pierdas un paso se va a notar graficamente. No se cómo se "soluciona" eso. No lo veo ni lo he podido encontrar.

¿Es posible que se trate del Driving Strikers que salió hace poco?



Según asegura su GitHub:

Full 480i TrueColor graphics at high framerates of up to 60 FPS without the expansion pak, extremely rare in N64 titles

@EMaDeLoC Madre mía... si que funcionan bien los buscadores. Kaze me dió bien el nombre, lo busqué tal cual, y no logré encontrar NADA. Que le diste al buscador para que te diera el resultado? xD

En fin, pues, viendo lo que dicen Kaze y el video ese, será ese juego, supongo. Si tuviera lo que solía tener, haría unas cuantas comprobaciones en hardware.
Lo que no tengo claro es si todo esto se debe a una técnica secreta que escapa a mi comprensión o simplemente ha optimizado el juego lo suficiente para garantizar no perder ni un solo refresco con un campo nuevo de forma consistente.

Normalmente, para garantizar consistencia en la secuencia de fotogramas cuando tu salida de video es entrelazada, lo que se hace es renderizar la imagen completa, y solo mostrar la parte correspondiente al campoo actual en pantalla que avanza y alterna campos sin compasión ni consideración hacia tus problemas de rendimiento. Si lograses renderizar a 480p o 576p a 60 o 50fps por segundo estarías perdiendo detalle en cada frame porque solo se mostrarían la mitad de las lineas. En N64 eso es casi imposible a no ser para un menú sencillo o algo así... Todos los juegos que ofrecen "alta resolución" en modo entrelazado renderizan muy por debajo de 480 o 576 y reescalan, pero en definitiva, hay una imagen progresiva detrás del refresco entrelazado, así que incluso si la imagen ha de estar en pantalla durante do o mas refrescos mientras se termina de renderizar el siguiente cuadro, siempre hay datos de imagen disponibles que son apropiados para ya sea el campo par o el impar. Pero si renderizas exclusivamente par o impar y pierdes un refresco de pantalla, que siempre conlleva cambio de campo, tienes un problema porque no dispones de información de imagen apropiada para el campo opuesto, y eso va a resultar en un renqueo de la imagen.

Ahora bien, si realmente puedes GARANTIZAR que siempre vas a tener un nuevo campo listo para el siguiente refresco de pantalla, entonces no hay problema... pero claro, en una plataforma como N64 eso es mucho decir.
O sea, por repetir: 640x240 @ 60Hz o 640x288 @ 50Hz... quizá la resolución horizontal puede ser menor.
Estará optimizadísimo el juego este para conserguir hacer algo así. Otra cosa no se me ocurre.

Kaze Emanuar en su respuesta parece dar a entender como que es una técnica especial, pero por mas vueltas que le doy no se me ocurre que podría ser, mas que optimización salvaje.

Sería interesante si alguien puede capturar video en bruto sin desntrelazar ni nada, por ver si incluso este juego en algún momento pierde el ritmo y se ve alguno de los tipos de renqueo que esperaría ver en ese supuesto.

Si renderizas en entrelazado esperando no perder nunca un refresco de pantalla, y resulta que si que lo pierdes, existen las siguientes posibilidades de cómo se podría proceder. Digamos que acabas de renderizar el cuadro-campo para lineas impares y no llegas a tiempo al refresco de pares:

1) No tienes Vsync y muestras las lineas del campo impar que ya tienes hasta que se completa el cuadro de pares y lo empiezas a mostrar a mitad de refresco, provocando efecto tearing, renqueo en la parte superior de la imagen e imagen correcta en la inferior.
2) Tienes Vsync y muestras las lineas del campo impar que ya tienes directamente, provocando un renqueo temporal en toda la pantalla.
3) Tienes Vsync y muestras una interppolación de las impares como si fuera campo de impares. Sería la opción mas optima dada la situación, pero tendría aspecto borroso y quizá un tanto extraño
4) Tienes Vsync y doble búfer y decides usar el cuadro-campo anterior, correspondiente a un momento temporal previo, pero que encaja en la zona de pantalla. Dependiendo de cuanto movimiento haya en ese momento puede no notarse o notarse y molestar muchísimo, con un renqueo aún mas brutal, con movimiento de avance y retroceso.
5) se podría combinar la omisión de Vsync con la interpolación de la opción 3.
6) dejar ese campo en negro o en blanco o en gris y darlo por perdido. Probablemente la peor opción, aunque me gustaría ver el resultado, en un CRT especialmente.

Alguna combinación mas se podría hacer, pero os dejo que os lo imagineis vosotros.

Igual lo que hace este juego es alguna de estas cosas, no lo se. No se me ocurre qué mas podría ser.

Aunque tiene efectos de partículas y todo, el entorno se ve bastante sencillote y las físicas algo "floaty", quizá sea ahí donde radica la optimización que le permite el rendimiento necesario para mantener los 60fps.

AÑADO: Le he dejado un comentario al autor del juego este preguntándole qué hace cuando se retrasa en un refresco de pantalla. A ver si nos aclara el tema
https://www.youtube.com/watch?v=xQ2lsyH ... ZGt4AaABAg


Quizá ni siquiera renderize con un framebuffer 1:1 y haga escalado de campos...

radorn escribió:@EMaDeLoC Madre mía... si que funcionan bien los buscadores. Kaze me dió bien el nombre, lo busqué tal cual, y no logré encontrar NADA. Que le diste al buscador para que te diera el resultado? xD

Me acuerdo que vi el juego en un vídeo que mencionaban los 60fps en entrelazado, pero no recuerdo cual vídeo era ni tampoco me quedé con el nombre del juego... Pero como era de coches y fúbol, busqué "Rocket League n64" y me salió.


Sobre como puede funcionar el 480i a 60fps o casi, no lo tengo nada claro.
No sé si mirando el código fuente se puede saber, supongo que si.

@radorn gusto en volver a leerte por estos lares

Tu sugerencia de coger nuestras consolas, atarlas en palos con alambre de espino, y después quedar en un descampado para darnos de hostias entre los foreros sigue inmortal en mi memoria

Respecto al tema, por más que os leo, lo que sigo interpretando es que el VI de la N64 es una "movida" que coge cualquier resolución entre 240 y 480, sea compatible o no con el monitor, sea real o estirada, y le pone un "parche" para que de el pego en pantalla.

Como cuando se te está acabando el gel de la ducha y tú lo que haces es echarle más agua a la botella haciendo espuma para poder seguir lavándote. Sabes que no es la misma calidad del gel original, pero da el pego.

Más o menos éso, o yo que sé

mmm... yo lo que he entendido es que cuanto mas te acerques a dibujar los 640 pixeles horizontales, menos va a emborronar. No es por el número de líneas.

El VI saca 640x480i o 320x240p.
Cuando es una resolución horizontal menor de 640, el VI puede meter una fusión leve entre un pixel horizontal y el siguiente, lo que da un efecto de desenfoque. Los cacharros que hacen deblur como el RGB de Tim alargan el primer pixel hasta el segundo, quitando esa fusión o desenfoque. Eso hace la imagen nítida.
Si no me equivoco esa fusión se puede desactivar, y creo que la información que ha aportado Conker64 lo respalda.

De todas lo que repito siempre: estos filtros de desenfoque funcionan estupendamente en un CRT. Elimina dientes de sierra y suaviza mucho el dithering de la consola. Quitar los filtros puede ir bien en una pantalla plana y los juegos 2D y algunos 3D, pero en otras ocasiones van fatal. Por ejemplos, los textos de los Zeldas te los cargas de esa manera.

Tengo una consola con el N64Digital, antes de pasar al RetroGEM. Tiene salida RGB, directa de digital, la más nítida que existe para la consola. Es un desastre. Vuelve un CRT en un monitor CGA de PC.

Si teneis CRT para la N64, aprovechadlo.

@EMaDeLoC ¿Consume recursos esa interpolación de la interfaz?.

@Señor Ventura Que yo sepa todo lo que hace el VI es inmediato y sin gastar recursos.
Piensa que hacer una fusión o media entre dos pixeles es muy sencillo matematicamente: sumas el valor de cada color y lo divides entre dos. En binario es aún más sencillo: sumas el valor y luego haces shift hacia la derecha (shift es desplazar los bits a un lado, descartando el último).
El VI es bastante tocho dentro del RCP, no me extrañaría que tuviese un pequeño circuito que hiciera esta operación directamente, además de cualquier otra como reescalar.

Sexy MotherFucker escribió:@radorn gusto en volver a leerte por estos lares

Tu sugerencia de coger nuestras consolas, atarlas en palos con alambre de espino, y después quedar en un descampado para darnos de hostias entre los foreros sigue inmortal en mi memoria

JUAS Bueno, yo ahora no tendría nada que llevar a ese épico enfrentamiento.

Sexy MotherFucker escribió:Respecto al tema, por más que os leo, lo que sigo interpretando es que el VI de la N64 es una "movida" que coge cualquier resolución entre 240 y 480, sea compatible o no con el monitor, sea real o estirada, y le pone un "parche" para que de el pego en pantalla.

EL VI, siglas de Video Interface, es el componente dentro del RCP que se encarga de coger la imagen terminada del framebuffer y generar la señal de video digital que luego consume el DAC para hacer su compuesto, s-video o RGB.
Es un componente programable y que puede hacer diversas operaciones por su cuenta CASI gratis, pero no del todo, si no por otra cosa, al menos por acceso a la RAM unificada. Debido precisamente a la RAM unificada, al VI se le tiene que decir dónde esta el Framebuffer en RAM, y, como me demostró mi experiencia con el Action Replay, puedes pasarle cualquier región de RAM, con su punto de inicio, formato de color, longitud de linea y número de lineas, parámetros de escalado, y lo sacará por la pantalla en el modo de video configurado.

Imagino que otros sistemas son mas rígidos y requieren una relación directa 1:1 entre el framebufer y el pixel clock de la interfaz digital de video, donde cada pixel del framebufer es un pixel en pantalla. Pero el VI de N64 puede hacer, hasta donde yo he podido ver, cualquier escalado arbitrario sin problema (si, incluso el framebufer puede ser inferior a 240p y el VI lo puede estirar, con o sin suavizado, sin problema... no es que sea algo recomendable, claro, por calidad visual)

La grandísima mayoría de juegos PAL que llenan la pantalla y no tienen barras negras usan el VI para estirar el framebufer pensado para 1:1 240p (que puede ser una resolución menor, pero con una relación 1;1 con la pantalla a 240p, o sea, alguna barrita negra, pero que también está en el original, como mario 64, que renderiza 237 lineas y deja 3 en negro incluso en NTSC) y las escalan a 288p, lo cual es una relación 5:6, o sea, que la mayoría de juegos NTSC 240p, en sus versiones PAL el VI estira cada 5 lineas del framebufer a 6 lineas de pantalla, con suavizado/emborronamiento... o lo que técnicamente se llama INTERPOLACIÓN: Es posible que en este hilo aún esté alguna imagen que quizá postease detallando este efecto. Por ejemplo, una comparativa de Smash Bros en la arena de Star Fox, que tiene el perfil inclinado del lomo del great fox superpuesto al fondo negro espacial, permitiendo ver claramente la escalera. En NTSC, que muestra el framebufer en pantalla en relación directa 1:1, se ve una escalera con antialiasing normal, regular. Pero en PAL, que toma ese mismo resultado del framebufer y lo reescala con el VI, cada 6 lineas se repite un patron bastante claro cuando lo ves, y puedes ver que algunas lineas son muy claras y otras un tanto mas borrosas, donde se nota que las lineas PAL son una mezcla de la anterior y la siguiente, en diversa proporción, en una progresión que se repite cada 6 lineas.

Una excepción que encontré en su dia era Body Harvest, donde se podía ver este mismo tipo de fenómeno incluso en NTSC. No se me ocurrió ponerme a contar lineas para discernir el patron y calcular la resolucón origianl del framebufer, pero es inferior a 240 tanto en NTSC como PAL, lo cual, pone a ambas en igualdad de condiciones y claro, de puestos a escalar y emborronar, gana PAL porque escala a una rejilla de mayor resolución, igual que pasa con muchos juegos hi-res entrelazados, que no renderizan a 480 internamente, si no algo inferior, y por no mover el mapa de memoria, renderizan a la misma resolución interna tanto en PAL como NTSC, y siendo ambos escalados, gana PAL en nitidez por ofrecer mayor resolución de salida, dando mas granularidad al proceso de escalado.
Ni Turok 2, ni ningún STAR WARS, incluído el Ep1 Racer, que yo recuerde, ofrecían 480p 1:1 sin reescalado por VI en NTSC.

Mientras que casi todos los PAL a pantalla completa 288p estiran y emborronan un poco el framebufer interno 240p (SI, INCLUíDOS LOS DE NINTENDO, como en los Zeldas), y es una desventaja, los juegos PAL en alta resolución entrelazada, dado que ni los NTSC tienen relación 1:1 entre framebufer y salida de video, los PAL ganan algo en nitidez comparados con NTSC, al menos teóricamente, pero probablemente se note poco. Luego está la comparación de si se hizo bien la adaptación a 50Hz para mantener el rítmo temporal del juego o no, pero eso ya es otro tema.

Y luego están los juegos milagrosos que mencioné ya mil veces: GoldenEye, Perfect Dark, Diddy Kong Racing y la beta de 40 WInks, los únicos ejemplos que encontré donde los desarrolladores (británicos en ambos casos, claro, Rare y EUROCOM) se preocuparon de hacer una adaptación PAL con renderizado interno a 288p para tener relación 1:1 con la salida de video PAL 50Hz y no tener que escalar y emborronar con el VI.

No recuerdo si investigué bien los juegos de Factor 5, que son también de tierra PAL, en Alemania (no?), para ver si renderizaban a 288p o no. Tras darme cuenta de que GoldenEye no mostraba el emborronamiento del reescalado 240p a 288p, me puse a buscar mas juegos desarrollados por grupos europeos, que tenían mas posibilidad de que los programadores se hubieran preocupado de darnos amor a los PALetos. No se si por entonces era consciente de que Fator 5 eran alemanes. De todas formas tengo un vago recuerdo de que esos también escalaban en PAL, pero ahora no estoy seguro.

EMaDeLoC escribió:El VI saca 640x480i o 320x240p.
Cuando es una resolución horizontal menor de 640, el VI puede meter una fusión leve entre un pixel horizontal y el siguiente, lo que da un efecto de desenfoque. Los cacharros que hacen deblur como el RGB de Tim alargan el primer pixel hasta el segundo, quitando esa fusión o desenfoque. Eso hace la imagen nítida.
Si no me equivoco esa fusión se puede desactivar, y creo que la información que ha aportado Conker64 lo respalda.

El VI siempre genera lineas con area visible de 640 horizontal. Cuando el framebuffer es de 320, o, en cualquier caso, inferior a 640, obviamente hace interpolación de valores, a lo que llamas "fusión leve". O sea, que los valores de color del pixel 1 y 2 en el frambufer pasan a ser los pixels 1 y 3 en la salida digital, y el VI genera un nuevo pixel 2 con un valor de color calculado como la media de los valores del 1 y el 3.
O sea, que cuando está estirando los 320 horizontales a los 640 fijos del bus de video, hace lo siguiente:
-Para el pixel 1 de la pantalla, cojo el valor del pixel 1 del framebufer y lo pongo tal cual
-para el pixel 2 de la pantalla cojo el valor del pixel 1 y el pixel 2 del framebufer, calculo la media y lo saco como pixel 2 de pantalla
-para el pixel 3 de pantalla cojo el pixel 2 del framebufer y lo paso tal cual.
Y así sigue hasta el final
Obviamente el proceso no es tan facil de descibir para "encajar", digamos, 400 de framebufer en los 640 de pantalla.

La cosa se complica cuando hay que hacer escalado vertical también, porque entonces hay que calcular combinaciones de colores entre lineas para generar los nuevos pixels de pantalla a partir del framebufer.

Mientras escribo esto me acabo de acordar de otra curiosidad que os animo a comprobar:
Uno de los ejemplos mas raros de salida de video que vi en N64 es la versión PAL de Automobili Lamborghini: El juego saca 288p a pantalla completa con estirado... Pero en vez de escalar con suavizado hace escalado INTEGER.
La relación sigue siendo 5:6, o sea, que cada 5 lineas renderizadas salen 6 en pantalla, pero en vez de hacer interpolación gradual como la mayoría de juegos, saca las 5 lineas originales en 5 lineas PAL directamente y para la 6 repite la 5 y punto pelota.
Eso se puede apreciar facilmente en pantalla como que cada pocas lineas hay una mas gruesa, doble.

EMaDeLoC escribió:@Señor Ventura Que yo sepa todo lo que hace el VI es inmediato y sin gastar recursos.
Piensa que hacer una fusión o media entre dos pixeles es muy sencillo matematicamente: sumas el valor de cada color y lo divides entre dos. En binario es aún más sencillo: sumas el valor y luego haces shift hacia la derecha (shift es desplazar los bits a un lado, descartando el último).
El VI es bastante tocho dentro del RCP, no me extrañaría que tuviese un pequeño circuito que hiciera esta operación directamente, además de cualquier otra como reescalar.

Come un poquito de tiempo extra porque tiene que interpolar entre lineas, lo cual supone aumentar el acceso a memoria, que ya sabemos que es un tanto... cabrona la RDRAM esta.

EL VI va leyendo de la RAM y serializando los datos e interpolando según sea necesario. Mientras que la interpolación horizontal la hace casi al vuelo porque ya tiene el pixel anterior y el siguiente en el registro interno, interpolar verticalmente implica leer de dos lineas del framebufer para generar la actual, y eso implica aumentar el número de accesos a RAM. Lamentablemente no es totalmente gratis. Aunque bueno, la diferencia de rendimiento es mínima
Lo que si es indudable es que al ser un componente independiente que funciona en paralelo, no depende de la CPU ni del RDP para sus procesos internos, O sea, no es escalado por software, que sería lentísimo, pero 100% gratis no es por culpa de los accesos a memoria unificada. Otra cosa sería si fuese un framebufer de RAM dedicada. Pero bueno,el impacto es muy pequeño

Entonces, se pueden obtener los postprocesos sin emborronamiento, a costa de:

-Resolución horizontal.
-Menos polígonos en pantalla, y menos texturización.


¿He entendido que la interpolación son solo pixels de cada scanline, y no scanlines entre si?.

Señor Ventura escribió:Entonces, se pueden obtener los postprocesos sin emborronamiento, a costa de:

-Resolución horizontal.
-Menos polígonos en pantalla, y menos texturización.


¿He entendido que la interpolación son solo pixels de cada scanline, y no scanlines entre si?.

No acabo de entender lo que planteas ni lo que preguntas. perdona.

radorn escribió:

Señor Ventura escribió:Entonces, se pueden obtener los postprocesos sin emborronamiento, a costa de:

-Resolución horizontal.
-Menos polígonos en pantalla, y menos texturización.


¿He entendido que la interpolación son solo pixels de cada scanline, y no scanlines entre si?.

No acabo de entender lo que planteas ni lo que preguntas. perdona.

Que a pesar de aplicar postprocesos, no obtienes emborronamiento de imagen si renderizas a 640 pixeles porque no hay interpolación.

¿Y que la interpolación es solo dentro de los píxeles de cada scaline, y no entre scanlines? (si renderizas usando solo 100 scanlines, ¿que pasa con la imagen?, ¿se estira e interpola?, o quedan bandas negras y ya).

@Señor Ventura Como digo, el VI es configurable, programable. Puedes decirle qué región de memoria leer y de qué manera, si usar interpolación o no, o, mas correctamente, qué tipo de interpolación (la técnica de poner un valor entre otros dos valores) usar. Porque interpolación de enteros es simplemente volver a usar el mismo valor anterior para el siguiente pixel, mientras que otros tipos calculan el valor que se "interpola" a partir de los valores adyacentes.

Cuando conviertes una linea de 320 a los 640 necesarios para llenar el bus de video, lo habitual que se hace es calcular el valor intermedio entre los dos, como explicó EMaDeLoC. Pero igualmente que haces eso puedes simplemente repetir el mismo valor durante 2 pixels en vez de solo uno y eso también es "interpolación" de tipo INTEGER / ENTERO, también llamado zero-hold o nearest-neighbor. Obviamente esto requiere muchos menos pasos y da una imagen con un aspecto mucho mas nítido a costa de la suavidad. Aquí ya cada uno decide qué le gusta mas en cada situación.

En el caso de los famosos parches anti-AA, de una misma pasada se cargaban dos o tres procesos de la consola.
El Antialiasing de la N64 se hace en dos pasadas: una pasada para los aristas "internas", que son donde dos triángulos adyacentes comparten vértices a nivel de modelo (no solo que estén en el mismo lugar, si no que sean el mismo vértice, usado para dos triángulos adyacentes). Este antialiasing lo calcula el RDP y lo dibuja al framebuffer, y una segunda pasada para aristas externas, que se habrían de "anti-aliasear" (aliasinar? aliasianar? hmmmm...) contra el entorno que tengan detrás. Esta segunda pasada la calcula el RDP en forma de 2 bits por pixel (4 posibles valores de 0 a 3) almacenados en el bit extra de la RDRAM de 9 bits porque normalmente los juegos renderizan en color de 16 bits, o sea 2 bytes de 8 bits por pixel, que nos da esos 2 bits extra. Estos valores representan una proporción de mezcla de color con el/los pixels adyacentes (nunca acabé de entender el proceso exacto). O sea, que cuando el VI está pasando por ese pixel, lee los bits extra y según el valor, mezcla la cantidad de color correspondiente de el/los pixel/s que rodean a ese en el actual, logrando un efecto antialiasing un tanto cutre a costa de mas borrosidad.
Si alguna vez os habeis preguntado por qué cuando se cruzan cosas en pantalla, hay una especie de hormigueo raro al rededor, es por esto. Por ejemplo, cuando algo queda cortado por el limite negro de la pantalla y parece que hay un hormigueo ahí, es por esta segunda mano de antialiasing..
Toda esta explicación viene a cuenta de que los parches anti-AA se basan en desactivar una configuración que desactiva a la vez, si no recuerdo mal, TODO el antialiasing (interno y externo) y la interpolación de video
A diferencia del de-blur de los mods de video digital actuales, que toman la imagen con AA interno y externo y substituyen los pixels impares resultado de la interpolación del VI con el color del pixel anterior.

Pero de vuelta a ese tema. Como te digo, tu puedes interpolar o no (o, como expliqué, interpolar de una forma o de otra), según programes el VI. No es una función fija del VI. No tengo confirmación de esto que voy a decir ahora, pero creo que puedes seleccionar independientemente el proceso de interpolado para la dimensión vertical y la horizontal.

En esta configuración también entra de donde hasta donde "proyectas" el framebuffer en pantalla, y como interpolas y qué haces el resto de las lineas... SI las dejas en negro, pues quedan las famosas barras. Imagino que se podrían llenar de algún color, o incluso crear marcos como los del SuperGameBoy. Pero esto ya es especulación por mi parte.

Con el VI puedes especificar el origen de los datos que toma de cualquier región de memoria. Cuantos pixels de origen por linea, como escalarlos/interpolarlos a los 640. Desde qué linea y pixel de pantalla empezar y donde terminar, Todo.
Es muy flexible, aunque posiblemente dificil de configurar. Recuerdo interesarme por los parámetros del VI para tratar de conseguir in efecto determinado y no logré deducir cómo funcionaban

Señor Ventura escribió:si renderizas usando solo 100 scanlines, ¿que pasa con la imagen?, ¿se estira e interpola?, o quedan bandas negras y ya

Por responder específicamente a esto. Puedes mapear esas cien lineas en la región que quieras de la pantalla y escalarla como quieras. El VI es flexible
El VI no impone una relación directa entre el framebuffer y la pantalla. Puede hacer lo que te de la gana. Algún límite habrá, imagino, pero en principio, lo que quieras. Podrías renderizar 123 x 456 y mapearlo a una región de 150x69 en la esquina inferior derecha de una pantalla entrelazada, por ejemplo. Por qué querrías hacer algo así? NO TENGO NI IDEA, pero creo que poder se puede.

AÑADO: Creo que otro ejemplo de uso del VI para escalar el framebuffer sobre la pantalla es cuando suenan las campanadas del Majora's Mask y se va reduciendo la imagen en pantalla. Creo que el juego sigue renderizando la escena 3D a un framebuffer 240p y usan el VI para hacer el efecto zoom. Una pista de que esto es lo que está pasando es que el aspecto de la imagen va cambiando con cada nivel de zoom ganando en nitidez pero con algunos defectillos raros. No es que cambie el tamaño de la ventana de renderizado.

radorn escribió:Yo nunca había oído eso de los 42 modos de video soportados por el VI. Yo entendía que era programable. Quizá esos 42 modos de video son las combinaciones documentadas, y que no está necesariamente limitado a ellas ni es que las tenga integradas dentro.

Sí, eso es, se refieren a presets disponibles en la librería en el momento de ese documento, luego a partir de ahí podrías tomarlo como referencia y crear uno que se adapte al juego.

radorn escribió:Cuando tenía el hardware e investiqué estas cosas, nunca vi un solo juego que tuviese 640x480 (o 640x576 para PAL) "reales" o sea, que el framebuffer no era de ese tamaño si no menor y luego el VI lo estiraba.
Y al colación de esto mencionto también que si que creo que el VI puede estirar cualquier resolución de freimbúfer arbitraria a la pantalla, y no está limitada a "algunos modos fijos", y lo deduzco por mi esperiencia usando una funcionalidad que tiene el ActionReplay / GameShark v3.3.

También es cierto, a VI de hecho le podrías mandar un framebuffer de 2x2 como de 1024x1024 (entero), que también sería capaz de adaptarlo a la salida de imagen, puede estirar como estrechar.

Hace unos años estuvimos tratando el tema para libdragon, resoluciones y el bug del modo NTSC al quitar el AA resample:


Al final lo dejé, porque no tenía las herramientas para trabajar de forma segura, quizás en la nueva todo eso esté actualizado.

@Conker64 gracias por las confirmaciones

¿Sabrías decir si con el VI se puede hacer un mosaico en pantalla repitiendo el framebuffer? es una tontería que se me acaba de ocurrir, pero hasta podría tener utilidad para algún efecto
¿Y la idea del marco? Se puede definir un relleno para las áreas de pantalla que no quedan cubiertas por el mapeado del framebuffer, digamos que un color sólido diferente al negro, o quizá algo mas elaborado como un marco? Imagino que lo segundo será que no porque añadiría demasiada complegidad al VI y a la configuración para hacerlo funcionar, y requiriendo doble acceso a memoria para el marco y el FB.

¿Nadie tiene un GameShark Pro / Action Replay Pro (v3.3) para mostrar lo del visor de graficos?
Molaría ver la demostración de los framebufers, el zbufer y el escaladoextremo en tiempo real.

radorn escribió:¿Sabrías decir si con el VI se puede hacer un mosaico en pantalla repitiendo el framebuffer? es una tontería que se me acaba de ocurrir, pero hasta podría tener utilidad para algún efecto

Creo que el problema sería horizontal, verticalmente puedes hacer cambios a mitad de frame, con algunas limitaciones.

He encontrado un texto en n64brew sobre el bug de arriba (que repite horizontalmente):

If AA_MODE = 11 (resampling disabled), TYPE = 10 (16-bit), X_SCALE is 0x200 or lower, and H_START is less than 128, the VI generates invalid output, consisting of the first 64 pixels from the framebuffer from the current line, then 64 pixels of garbage, and these two repeat for the rest of each scanline. A common case where this can happen is NTSC units (where H_START is usually 96) with a standard framebuffer of 320x240 (X_SCALE=0x200). For this very common situation, the simplest workaround is to activate resampling.

No sabría decirte si trabajando con esos valores podrías conseguir el efecto, o si se me ha pasado por alto cualquier otro registro, hay todo tipo de detalles imprevisibles según como combinen los valores, pero lo dejo como duda.

radorn escribió:¿Y la idea del marco? Se puede definir un relleno para las áreas de pantalla que no quedan cubiertas por el mapeado del framebuffer, digamos que un color sólido diferente al negro, o quizá algo mas elaborado como un marco? Imagino que lo segundo será que no porque añadiría demasiada complegidad al VI y a la configuración para hacerlo funcionar, y requiriendo doble acceso a memoria para el marco y el FB.

Podrías dibujar bandas arriba y abajo, un marco completo no creo, según parece puedes cambiar de origen en pantalla activa, pero mantendría el incremento del scanline, hay que jugar con la posición de memoria del siguiente frame buffer.

bit 23-0 ORIGIN[23:0]: RDRAM base address of the video output Frame Buffer. This can be changed as needed to implement double or triple buffering.

Extra Details:

ORIGIN must be a multiple of 8 (i.e. ORIGIN[2:0] must be 0). Otherwise the VI output may be noisy, shifted, or weirdly interleaved.
You can change ORIGIN mid-frame during horizontal blank. Notice however that VI internally keeps the running offset in the framebuffer since the frame started (accumulating VI_V_SCALE for each scanline) and that offset is *not* reset when ORIGIN changes. So the new framebuffer will be sampled starting from the same byte offset that the previous framebuffer would have sampled at.

Igual lo mejor sería hacerlo directamente desde el RDP, con la escena 3D recortada en el centro.

@radorn Que barbaridad, me va a costar asimilar todo eso. Por el motivo que sea, nunca me empapo sobre nada de n64.

Es todavía mas compleja de lo que pensaba.

@Señor Ventura la versión simplificada del VI es que puede mapear el framebufer a una región de la pantalla con total libertad de dimensiones, posición, modos de escalado, etc...
No puedo hablar con total conocimiento de causa de cómo funcionaban otros sistemas contemporáneos como PS1, SAT, 3DO, etc, pero imagino que operaban de una forma bastante mas directa, donde el homólogo del par VI-DAC tendría una serie de modos fijos de funcionamiento y un lugar específico de una memoria de video dedicada donde poner el framebufer que tendría que ser de las dimensiones exactas para el modo de video seleccionado.
Repito que en estos casos tengo muy poca información y tengo que especular bastante y ante mi falta de hardware no me voy a poner a investigarlo, pero lo mas probable es que no sean tan flexibles como el VI de N64.

@radorn a ver si termino de pillarlo: el VI es una suerte de escalador del Framebuffer, y otras movidas, pero principalmente "agrandador" o "achicador" con precisión por pixel de la imagen que la N64 escupe en pantalla, totalmente bajo el control del programador, aunque también puede ir en modo "automático".

¿Progreso adecuadamente, profe?

Señor Ventura escribió:Es todavía mas compleja de lo que pensaba.

Pues el día que te metas a estudiar la CPU de Ps2 te da 1 yeyo xD

@Sexy MotherFucker El VI es el encargado de producir la señal digital de video a partir del contenido de la memoria (preferentemente el framebuffer actual ), y siempre tiene que estar configurado/programado para leer de donde sea que el juego almacene el FB en la memoria unificada, ya que se puede poner en cualquier lugar y no hay una localización por defecto definida por el hardware.
Teniendo en cuenta además que la mayoría de juegos usan double-buffering (y se supone que alguno triple?) algún mecanismo tiene que haber para que el VI lea del FB terminado y no del que aún se está cocinando. No se si es que hay que darle configuración nueva encada refresco o se puede informar al VI de donde están ambos FBs y simplemente indicarle cuando cambiar de uno a otro. Quizá @Conker64 tenga la respuesta.

El escalado (estirar y achicar) se hace al vuelo durante cada "escupitajo" (por usar tu terminología xD). No se almacena el resultado otra vez en RAM para luego ser leido otra vez para salir por pantalla, si no que va saliendo directamente al DAC a medida que el VI procesa el FB.

Las funciones de escalado siempre están en uso, incluso cuando parecería que no hace falta. Consideremos el caso del tipico juego 320x240 NTSC (no PAL, para saltarnos el escalado vertical de 240 a 288). Aún en este caso, en la gran mayoría de juegos, el escalado suavizado está activo para adaptar los 320 horizontales del FB a los 640 visibles del bus de video, INTERPOLANDO pixels nuevos entre los originales, haciendo la media entre ellos.
También se podría hacer interpolación de enteros y simplemente repetir un miso pixel dos veces, sin hacer medias ni suavizados ni nada (interpolación "sin interpolación", por usar lenguage de andar por casa), pero la mayoríade juegos hacen lo primero, y por eso los mods de video modernos incluyen el famoso DeBlur, pensado para juegos con 320 horizontales que hacen interpolación, que son la mayoría.
En otras situaciones hace tareas de escalado mas cercanas a lo que tipicamente se considera escalar, como es el caso de estirar los 240p de framebuffer de la gran mayoría de juegos PAL a los 288p necesarios para la pantalla (un paso que no sucede en las versiones NTSC, claro). O como Body Harvest, que como ya dije varias veces, renderiza bastante por debajo de 240 tanto en NTSC como PAL y encarga al VI que llene la pantalla con eso.

Viendo cómo os está costando asimilar esto, ahora entiendo porque a pesar de que muchas veces señalé lo de los juegos PAL superadaptados (GE, PD, DKR, 40W), a casi nadie parecía importarle xD

O sea, que el VI no es que sea un escalador: Es la Video Interface, Interfaz de Video, se encarga de producir la señal de video en digita que luego el DAC la "analogiza". Como parte de ese proceso, tiene la capacidad de hacer escalado al vuelo con parámetros arbitrarios a elección del programador. Estira, achica, interpola... trocea, pica, muele, bate...

Con lo de "ir en modo automático" no tengo claro del todo qué quieres decir. Si te refieres a que si el hardware tiene una configuración por defecto si no le das una tu, lo dudo. Asumo que el hardware siempre va a requerir que se le de una configuración de manera explicita. El único "automatismo" que se me ocurre sería que el SDK con el que programes la consola traiga una configuración por defecto para el VI sin que tengas que definir una nueva. Pero en este caso estaríamos hablando de un atajo práctico para el programador, no de algo inherente al hardware.

Es curioso y vídeo lo que habéis explicado que algún juego no ocupe pantalla completa, como por ejemplo el Beetle aventure, salvo por o bien desconocimiento de los desarrolladores o bien problemas de rendimiento.

No es que sea inabarcable entenderlo, pero que van saliendo detalles con los que no contaba.

sgonzalez escribió:Es curioso y vídeo lo que habéis explicado que algún juego no ocupe pantalla completa, como por ejemplo el Beetle aventure, salvo por o bien desconocimiento de los desarrolladores o bien problemas de rendimiento.

Si pudiera le echaría un vistazo, pero solo puedo hablar de lo que recuerdo. El BAR tenía un área visible con marco negro todo al rededor, verdad? Seguramente los desarrolladores redujeron el area de pantalla por rendimiento, y no quisieron llenar la pantalla mediante escalado por VI para no indicir en la borrosidad. Si hubieran reducido mas las dimensiones de renderizado probablemente habrían hecho lo mismo que Body Harvest, estirando a pantalla completa desde un framebuffer tan reducido que sería inaceptable usarlo a escala 1:1 en pantalla porque dejaría mucho espacio vacío
Yo diría que encontraron un punto medio para obtener un rendimiento aceptable sin reducir la resolución tanto como para tener que recurrir a estirados borrosos por VI.

Por cierto que el BH no hace estirado para todo. La intro y la pantalla de título van a 320x240 nativos sin escalado extra (bueno, al menos la versión NTSC... no recuerdo si la PAL hacía 288p nativos o 240p estirados), pero une vez inicias el juego, la resolución de renderizado se reduce considerable y el VI la estira a pantalla completa. Es un juego muy borroso gracias a esto. Si además usase el extraño estilo de renderizado de StarFox y MIssion:Impossible (y algún otro) ya sería el acabose.


-----------------------------------------------------------------------------------------

@Conker64 @EMaDeLoC @Sexy Motherfuker @Señor Ventura
Spooky Illuha respondió: https://www.youtube.com/watch?v=xQ2lsyH ... ZGt4AaABAg

@radornkeldam
What do you do when you miss a screen refresh? Reuse the last field-frame corresponding to the other group of lines causing spatial judder? Reuse the previous field-frame that matches the odd or even field that's currently on screen, avoiding special judder, but causing temporal judder? You interpolate the previous field-frame to fill the current field to simulate a progressive frame? Something else?

@Spooky Iluha
It uses the previous field frame that matches the oddness, I haven't seen any issues with it on CRT

@radornkeldam
Thanks for taking the time to answer
I guess it may not be too bad for such a small playfield and more or less 60fps. Did you try interpolating between lines to create a false opposite-oddness field? I don't know how the VI is programmed, so I don't know if it will easily acommodate this, or at all, but sounds like it might be the best solution. But if nobody has noticed any judder, I guess it's OK, at least for this particular game.
It might have been more noticeable in a game with more sweeping camera movements and ampler playfields.

-------

This just occurred to me:
Let's say you are trying to render the next field-frame for the odd lines, and you miss the vsync, so you drop that and display the previous odd-line buffer you had from before (I guess this means you keep double buffer odd and even separatelly too? four buffers overall? or maybe three: one of last odd, another for last even, and one for rendering). Now you've wasted the whole last refresh trying to render a field-frame that won't fit the next refresh because the screen will be asking for the even-line field-frame again. What if you also miss that vsync? I guess at some point you have to preemptively skip rendering for the next field-frame and go for the one after to try not to miss it again? Do you do that right away the first time you miss a vsync? Or something else entirely?

Así que básicamente renderiza campos de XXXx240 y si se retrasa y pierde la ventana de vsync antes de completar el nuevo cuadro-campo, usa el buffer anterior que corresponda al campoo par o impar que haya de ser mostrado en pantalla en ese momento... Supongo que eso significa que mantiene al menos tres bufers en memoria, uno para cada campo (dos en total) y uno donde renderiza, y el rol de cada búfer va rotando según sea necesario.

También me pregunto, como le cuento a Spooky Illuha, qué pasa si pierde dos vsync consecutivos. con un framebuffer progresivo, si pierdes un vsync, o dos, o tres, lo único que pasa es que acumulas retraso, pero no tienes problema en mostrar el framebuffer en cualquier refresco de pantalla una vez termines de renderizar, porque es progresivo. Pero si pierdes un vsync en renderizado entrelazado... la cosa se complica.
Digamos que se está mostrando en pantalla el campo par, mientras renderizas un cuadropara el campo impar, pero no llegas a tiempo. Ahora el cuadro que estabas renderizando ya no te vale para el siguiente refresco porque es para el campo opuesto. OK Spooky Illuha dice que reusa el framebuffer anterior para ese campo, que asumo por contexto que aún conserva en RAM y, según él dice, no supone ningun problema apreciable en un CRT. OK... pero entonces qué hace con el campo que estaba renderizando? sigue renderizándolo y lo muestra en el siguiente refresco aunque no corresponda con el tipo de campo? lo deshecha y vuelve a empezar con un campo que corresponda al siguiente refresco? y si pierde ese también? Quizá si pierde un refresco, desista de intentarlo para el siguiente y apunte directamente al de después?
Renderizar en entrelazado es una complicación...
Quizá me esté liando y no sea capaz de ver la obvia solución sencilla con precio aceptable, pero por lo pronto, el padre de la criatura ya me ha confirmado que, efectivamente, no tiene una solución perfectamente limpia para el supuesto de perder un refresco de pantalla.

@radorn Si que es bastante lioso, pero tiene pinta que precisamente se busca el objetivo de 30fps mínimo para evitar problemas.
El juego parece tener la geometría bien medida para evitar exceso de polígonos y de fillrate, aprovechando al máximo el ancho de banda de la memoria. Por ejemplo si varios polígonos comparten textura, se envía todos esos polígonos de una vez, cargando así la textura en la TMEM solo una vez. Por supuesto eso requiere de maña diseñando el escenario de forma que los polígonos de textura compartida se puedan agrupar (suelo, pared, etc).
Si procuras que tu peor escenario de renderizado, es decir ver todo el mapa más los jugadores más efectos, etc, te permita renderizar un poco por encima de 30fps, en teoría te puedes olvidar de perder la vsync dos veces (equivaldría a ir a 15fps).

Lo he probado un poco, va muy fluido. Excepto un momento puntual al principio rinde los 60fps. El entrelazado es notorio por HDMI, no me he puesto a toquetear opciones del mod ni tampoco conectarlo a un CRT, que seguro que lo disimulan mucho.
El sistema de ajuste de exposición me parece que no funciona bien o falta algún ajuste. Va saltando un poco según el contenido del frame. Cuando acaba de cargar el mapa todo se ve blanco hasta que lo ajusta. A veces el suelo, de roca negra, parece brillar. Yo no me habría complicado tanto poniendolo para obtener resultados irregulares, pero claramente esto es más una demostración técnica más que un juego completamente pulido.
La verdad que es bastante impresionante el resultado. Le falta algo de complejidad poligonal pero es normal para poder trabajar a 60fps.

@radorn

Gracias por tu esfuerzo trayendo información de calidad. Con el tiempo me estoy planteando hasta coger apuntes de todo este hilo y hacerme una carpeta.

Realmente de los mejores hilos del subforo en toda la vida de EOL.

@Sexy MotherFucker Estas informaciones era bueno ordenarlas y ponerlas en el wiki, este o algún otro, pero yo no se editar wikis y la verdad es que da pereza. No se tampoco si el wiki de EOL recibe mucho uso.

radorn escribió:@Sexy MotherFucker Estas informaciones era bueno ordenarlas y ponerlas en el wiki, este o algún otro, pero yo no se editar wikis y la verdad es que da pereza. No se tampoco si el wiki de EOL recibe mucho uso.

¿Y si se acude a la IA?, ¿esas cosas leer un hilo entero página a página?.

@Señor Ventura Ni se cómo ni tengo ganas de meterme en algo así. Si tu sabes del tema, adelante y a ver qué sale, pero sospecho que el resultado dejará bastante que desear, con alucinaciones y conclusiones dudosas por todas partes, y habrá que revisarlo de arriba a abajo. Quizá me equivoque, pero en fin, esa es mi predicción.

radorn escribió:@Señor Ventura Ni se cómo ni tengo ganas de meterme en algo así. Si tu sabes del tema, adelante y a ver qué sale, pero sospecho que el resultado dejará bastante que desear, con alucinaciones y conclusiones dudosas por todas partes, y habrá que revisarlo de arriba a abajo. Quizá me equivoque, pero en fin, esa es mi predicción.

Es que no todas las ias sirven para lo mismo, yo ni idea tampoco... pero de momento la información ahí está, que no es poco.

Ya que está reunida bastante gente que conoce el sistema y/o programó para él tengo una cuestión - what if?

Hace unas semanas vi en twitter en uno de los muchos comentarios del autor del port de GTAIII a Dreamcast a otro usuario que programaba en N64 decir algo así de mirar cuanto habría que recortar para hacer una adaptación a N64.

El caso, suponiendo un tamaño de ROM infinito (aunque igual sin FMV y sin las emisoras de radio ya cogería todo en 64 megas) ¿Sería factible un juego como GTAIII o similar? Entiendo que algo similar se podrá por el mero hecho de que Driver 2 existe en PS1 así que un escenario similar, pero con tiroteos en la calle ya sería un acercamiento a GTA 3D.

No digo que sea un GTAIII fiel al clásico sino si sería factible que el primer GTA 3D hubiera sido en N64 después de los dos primeros en 2D en PS1 y hasta donde podría haber sido.

Pues solo hay que mirar lo que salió de verdad en la N64:



No es exactamente un GTA3, pero el juego tiene mapas bastante grandes y abiertos. Dividiendolo en zonas que se vayan cargando en memoria, aprovechando el expansion pak y con algunos ajustes, un mapa como el de GTA3 podría funcionar.
Hay que tener en cuenta que el Carmageddon 64 directamente no está optimizado, así que con los conocimientos actuales de hardware y de las técnicas que funcionan, se debería poder mover bastante bien y tener bastante detalle. Aunque obviamente no tanto detalle como la versión de Dreamcast, y mucho menos la versión PC/PS2.

@EMaDeLoC habría que añadirle tráfico y más peatones y tener en cuenta las persecuciones policiales que podemos recortar muchas cosas en un GTA, pero la mecánica de delitos y estrellitas según el rango de busqueda es pilar básico.

@SuperPadLand tienes el body harvest, mundo abierto, vehículos para aburrir, y creo recordar que edificios destruibles también.

@SuperPadLand Pues imagino que habría que reducir considerablemente la complegidad arquitectónica del entorno, y bastantes ajustes a la baja de la simulación física y la lógica del entorno (control de peatones y vehículos, etc)... La verdad, no se qué responder.
Aunque no lo parezca estoy bastante desconectado de todo esto aunque aún veo alguna novedad de desarrolladores como Kaze Emanuar, con sus super optimizaciones e investigaciones del hardware, desarrollando su motor de alto rendimiento.

No controlo mucho el hardware de Dreamcast, y no se qué diferencias hay entre su SH-4 (?) a 200MHz, y el R4300i modificado de SGi/Nintendo a 93.75MHz, y qué diferencias concretas hay en el sistema de memoria. Entiendo que DC una memorias dedicadas tradicionales y no la estructura de memoria semi-unificada (no particionada, pero sin control de conflictos por hardware) de N64, aparte de tener mas y seguramente más rápida.

Respecto a almacenamiento, recordemos que el mapa de memoria de la N64 reserva un rango de direcciones de memoria de 256MB para el PI, la ranura de cartucho, de los cuales el 64drive V2 ofreció 240 accesibles como ROM y 16MB reservados en exceso para dar acceso a los registros internos del cartucho para controlar cosas como la tarjeta SD, el USB y, si, el módulo Wifi integrado. Yo no tuve este modelo, si no el V1, con 64MB de RAM para ROMs, sin wifi, y con ranura para tarjetas CompactFlash aparte de microSD. Si estos 256MB no son suficientes, los cartuchos de ROMs modernos permiten acceso directo a una tarjeta SD en modo lectura y escritura sin pasar por ROM. Un desarrollo nuevo pensado para aprovechar esto podría usar el espacio ROM como RAM secundaria (ya que funciona en modo RW, salvo que algún cartucho concreto lo limite, al menos el 64drive no lo hacía, que yo sepa.
Por otro lado está la RDRAM interna que oficialmente nos da hasta 8MB con un EP, pero quizá se pueda tener una N64 de hasta 16MB modificando una consola de las primeras, las de 2 chips de 2MB, reemplazandolos por 2 de 4MB sacados de EPs, y añadiendo un EP de terceros de los que llevaban también 2 chips de 2MB y reemplazarlos con 2 de 4MB. Y ya para abusar, creo que teóricamente el mapa de memoria aguanta hasta 32MB, pero para eso harían falta chips de 8MB que no se si existen, suponiendo que el RCP aceptase el trato, que una cosa es el mapa de memoria y otro la compatiblidad del controlador de memoria que hay dentro del RCP.

Así que tenemos 8-16 (o 32) de RAM, 256 de ROM-RAM en el PI (Parallel Interface), SD "ilimitada" en tercer plano a través del PI, y quiźa acceso por WiFi o USB a alguna cosa mas, si nos esforzamos mucho.

En ese sentido, no debería haber mucha limitación en cuanto a espacio. Hasta se podrían incluír las voces.
El problema es la rapidez de acceso a todas esas cosas. Por lo que recuerdo que se comentó aquí y en otros lugares, el PI, aunque suficiente para cargar casi instantáneamente un mapa típico de un juego de N64, no se si sería suficientemente rápido para cargar dinámicamente los trozos de los mapas de un GTA3. Sin duda habría que recortar bastante muchas cosas. No lo se. Aquí ya entran conocimientos mas prácticos a nivel de programación que yo no domino.

Una cosa que he ido aprendiendo a valorar es que aunque normalmente se piensa en la complejidad gráfica de un entorno tridimensional como lo mas pesado de mover, en muchas ocasiones la lógica del juego puede resultar mucho mas pesada, o por lo menos mas determinante del rendimiento de un juego. Los gráficos, a fin de cuentas, siempre vienen precocinados y solo hay que hacerles unas cuantas transformaciones y pasarselos al renderizador, con el texturado, iluminación y otros efectos ya predefinidos en ROM. Pero decidir y calcular las acciones de los elementos interactivos puede llegar a ser mucho mas pesado, un problema mas abierto y complejo, especialmente en un entorno abierto. lleno de variabilidad. Hay que usar muchos algoritmos de búsqueda, decidir si gira a la izquierda o derecha, etc, a cada frame o sub-frame.
En mi breve experiencia en la comunidad de mods de GoldenEye y Perfect Dark, vi situaciones donde el simple hecho de no tener bien hecha la red de navegación que permite a los enemigos viajar por el mapa, generaba tremendísimas ralentizaciones con framerates de 0.x fps, simplemente porque los enemigos estaban intentando averiguar por dónde ir para encontrar al jugador. Podías ver cómo un personaje viajaba de nodo a nodo de la red de navegación facilmente, pero luego, si había alguna conexión mal hecha, o inexistente, podías ver como al intentar volver a encontrar el camino, se paraba todo porque la CPU estaba intentando buscar una ruta. O podías ver al guarda/enemigo acometer una acción como dispararte, a rendimiento normal, y luego, al levantarse e intentar dar unos pasos, se paraba todo por debajo de un frame por segundo. Incluso en un nivel correctamente construido, el hecho de tener varios enemigos en pantalla actuando ralentizaba mas el sistema no tanto por la carga gráfica si no por la carga lógica de calcular las acciones de estos enemigos.
Sospecho que esta problemática se vería exacerbada en un entorno tan abierto como un GTA3.

En todo caso: @EMaDeLoC , si hablamos de ejemplos existentes en N64 que sean comparables a GTA3, ¿qué mejor que su precursor, Body Harvest? Hecho por DMA Design, luego renombrados Rockstar. Misma gente, concepto similar: mundo abierto con combate vehicular y libre acceso a vehículos encontrados en el terreno. De hecho, aunque Body Harvest no salió hasta 1998, ya fue mostrado como beta en 1995, mientras que los dos primeros GTAs para PC y otras plataformas usaban técnicas 2D para produdir un efecto pseudo-3D, siendo publicado el primero en 1997.
BH es el abuelo de GTA3. Retrasado mil veces, aunque salió en el 98, realmente es un juego de primera generación.

AÑADO: Se me dió por buscar un poco y me salió esta retrospectiva sobre GTA y mencionan algo interesante:
IGN Presents: The History of Grand Theft Auto

After completing small but admired Uniracers for the SNES, DMA accepted an invite to join Midway, LucasArts and Rare on Nintendo's content "Dream Team" for the upcoming Ultra 64 console. Jones had a new home. He went to work on an exclusive launch title, Body Harvest, DMA's first 3D effort, and it did things a little differently from those other Nintendo games. You played an armed and armored soldier in a free-roaming mission to save humanity from hungry alien carnivores, able to jump into any vehicle you found. Less fortunate humans, whether they fell to invaders, careless driving or over-aggressive marksmanship, died screaming in a haze of 64-bit blood.

It didn't get a pass from Nintendo EAD lead Shigeru Miyamoto. Mario's creator wanted more puzzles, less gore.

Jones' opinion differed. The aggressively over-the-top gameplay and open-world environments fit like personally tailored brass knuckles. It needed more, not different. Body Harvest fell off Nintendo's schedule (to be picked up years later by Midway), but DMA was already moving on a newer, better project. Programming had an engine that simulated a top-down cityscape, and centering the camera on a moving object gave it a incredible sense of speed. Jones quickly dreamed up a cops-and-robbers chase game around that dynamic, set in a living, breathing city where the player could go anywhere and do anything. Then he got bold: The player wouldn't be the cop.

Yo si que creo que la violencia virtual/simulada es problemática y desensibiliza, facilitando mas violencia, Pero el mundo del entretenimiento siempre está con el rollo este de "solo la puntita", que me parece enórmemente hipócrita. Pero no quiero iniciar un debate, simplemente que yo solía tener mejor opinion de estas vacas sagradas de la industria, pero a medida que veo cosas no paro de pensar que no pararon de cagarla por cabezones. Tontendo, Chony, MocoSoft. Siempre jodiendo algo, de verdad.

Mas puzles, menos sangre... ¿y por eso anunciasteis el juego en 1995 para luego darle la patada hasta que lo rescató otra editora? Vete a rascarla, Shiguero Miyamoto. Hay que ser cabrón. Historias como esta y lo de el aparente Robo (y perfeccionamiento, no lo niego) del plataformas 3D de Yoshi de los de Argonaut como inspiración para Mario 64... la verdad, da la impresión de que este hombre es bastante cabrón, por ponerlo suavemente.
Yo puedo entender hasta cierto punto lo de querer mantener una linea editorial y todo eso, pero da la impresión de que el niño Shigeru, sin quitarle sus méritos, se tomaba unas libertades y un enseñoreamiento que son dificiles de justificar.

Pero volviendo a tu referencia a Carmageddon 64, quiero comentar que, dentro de lo oscura que es, la banda sonora tiene algunas pistas que siempre me fascinaron. Entre ellas, está una que recientemente llamó mucho mi atención tras familiarizarme con la banda sonora de Dirty Harry (Harry el Sucio en España). La pista de CM64 se llama "Scorpio", y en Dirty Harry el psicópata asesino se hace llamar así también, y cuando está intentando cepillarse a su segunda víctima desde una azotea y le interrumpe un helicóptero de la policía, suena esta pista, que, en la parte aquí señalada, considero que tiene mucha similitud a esta otra parte de la pista de CM64.

Dirty Harry - Scorpio's View
https://youtu.be/yp8DGoaDZ5k?t=110s

Carmageddon 64 - SCORPIO
https://youtu.be/p_2SAfX3CBU?t=145

Lista de reproducción de YouTube con toda la banda sonora de Carmageddon 64
Sorprendentemente buena, y, por culpa de la mala calidad del juego que la contiene, poco apreciada.

---------------------------------------

Por cierto que Spooky Iluha volvió a responder, pero por circunstancias personales aún no me he puesto a analizar su respuesta, pero os la dejo aqui por ahora si quereis:
https://www.youtube.com/watch?v=xQ2lsyHd-xs&lc=Ugy_7gstvlQCEY-PZGt4AaABAg.AKIBNtrp2QTAKZxQ0huNbYd

The algorithm always renders consecutive fields for the VI to output, odd then even then odd and so on.
If the system takes too long to render a frame, VI spins the previous two available fields until its rendered and shows it on the next matching vblank. That way no rendered frame is wasted at all

I keep three 640x480 buffers to fit all the needed info for it to work. Technically it can fit in just two buffers, but it has noticeable artifacts with AA and dedithering. These use adjacent lines in the buffer for their inner workings, so we can't be rendering a new frame there while showing the neighbor field.

The VI does have some bilinear interpolation to its output, but I doubt its usefulness for smoothing out any jutter

ACTUALIZO: Bueno, pues vamos a ver qué nos está diciendo el amigo Spooky aquí.
Parece que tal como sospechaba, cuando su proceso de renderizado por campos entrelazados llega tarde a un refresco de pantalla, no se molesta en intentar el siguiente campo, que implica desechar el actual por que ya no encajaría en el siguiente. En vez de eso, directamente se salta el campo al que ha llegado tarde y también el siguiente, y así continua renderizando el actual en vez de desecharlo, y lo muestra en el siguiente refresco que corresponda con el tipo de campo. Mientras hace eso, vuelve a mostrar en pantalla los dos últimos campos que ya estaban renderizados. Esto necesariamente produce un renqueo en la acción, aunque el autor asegura no notar ningún problema "en un CRT". Seguramente sea un problema menor, pero a mi mente obsesiva le molesta xD.

Dice una serie de cosas respecto a cómo se almacenan los campos que no me quedan claras del todo. Tendré que ver de darle un poco mas la barrila para ver si me lo explica. Dice que tiene 3 búfers de 640x480, no de 640x240, y no se si es que almacena ambos campos en un mismo búfer o esos 480 están intercalados con lineas vacías. Dado que habla de problemas con AA (antialiasing) y el dedither por "usar solo dos (búfers)", imagino que esto hace referencia a combinar ambos campos en un mismo FB y que el VI lea información del campo opuesto durante los procesos de combinacion de colores del VI, causando efectos indeseados, así que deduzco que debe tener FBs separados para cada campo, intercalados de lineas de todo ceros o quizá todo unos (RGB 16 bits se supone que son realmente 5 bits por canal, que da 15 bits, aunque a veces se le dan 6 al verde porque somos mas sensibles a este color, completando los 16 bits; o también puede usarse el bit sobrante como bit de transparencia en algunos formatos de color, pero no se cómo funciona esto el VI de N64). Imagino que hace esto por alguna imposición rara del renderizado entrelazado en N64, que exige acceder a las lineas saltándose las del campo opuesto y no permite usar como "entrelazado" un búfer que no tenga las lineas correspondientes al campo opuesto. Pero esto es especulación mía.
También hace referencia a que causa problemas estar mostrando un campo del búfer entrelazado mientras escribes en el otro, y que por eso usa tres (dos para los ya renderizados, par e impar, y uno sobre el que se está renderizando, que se marca como último par o impar, mientras que el anterior se marca como nuevo target de renderizado, y así se van rotando.

@radorn La verdad es que yo tampoco acabo de entender como funciona lo de los framebuffers con el interpolado, especialmente el que necesite 3 FB o se generan artefactos en AA y dedithering.
Quizá, solo quizá, sea una cuestión de los campos y el orden en el que se renderizan. Quizá no puede leer más de dos veces un FB porque lo considere antiguo u otro frame. Es decir, lee una vez para el campo impar, otra para el campo par, pero no lo va a leer una tercera vez a menos que haya frameskip u otro frame nuevo hecho.

Lo que me parece claro es que son 3FB de 640x480 completos. Son casi 2MB de memoria a 16bits de profundidad de color. Es un desperdicio de RAM y no me extraña que el juego sea tan simple en escenarios, entre la agilidad que necesita el RCP y el límite de memoria.

Pero como curiosidad técnica esta genial.

¿Todo esto es para un sdk de dominio público?.

@EMaDeLoC Quizás tenga que ver con el hecho de que ese homebrew también tiene HDR? Es un poco difícil de seguir porque llevan aplicando técnicas sobre técnicas anteriores y tienes que ir enlazando unas con otras, pero si no entendí mal en su momento, hay un buffer de 32 bits que es el que contiene la información “RAW” del HDR, las luces modifican los valores de color alpha de los vértices. Hay que intentar preservar esta información de la manera más fidedigna posible, así que para ello se desactivan todos los efectos cuando renderizan a ese buffer, después un ucode específico en el RSP va línea a línea recorriendo ese buffer y haciendo una transformación de cada pixel a un buffer de 16 bits cambiando la intensidad de color en función del valor original alpha, esta información “descodificada” se pasa a los buffers de 16bits siempre y cuando el VI no esté haciendo nada en ese momento. Ósea el RDP solo conoce el buffer de 32bits y el VI solo conoce los dos buffers de 16bit. Si el RDP renderizase a los buffers que ve el VI y se quedase a mitad de camino, como el antialiasing y el dither usan los pixels de alrededor para sus cálculos podría causas efectos no deseados, sin embargo, como el RSP es en este caso responsable de pasar líneas completas siempre y cuando el VI no esté haciendo nada, eso no debería pasar.

Entiendo que algo similar se hace para el ejemplo de texturas 256x256. En este caso, la textura no contiene los datos R, G, B normales, sino la ID de la textura y las coordenadas U/V. El RDP genera otra vez otro buffer con los efectos desactivados y en este caso la CPU, en vez del RSP, “decodifica” ese buffer de datos y lo convierte en uno de color.

@Misscelan Tiene sentido lo que comentas, podría ser por aplicar un HDR.

Pues bastante resultón todo... pero a ver si desarrollan juegos que lo implementen y que no se quede solo en demos técnicas!

@celgadis_84 Estoy alucinando con los efectos que están sacando estos desarrolladores modernos en la N64. Hace un tiempo comentaba en el hilo de Saturn los proyectos de este desarrollador XL2, con su motor estilo quake con transparencias y mas cosas, deseando que hubiera algo al mismo nivel para N64, y empieza a haberlo.
Lo único que temo es que este tipo de virguerías técnicas nunca lleguen a en un "AAA" original para la consola porque lo mas costoso es desarrollar el contenido y montar una experiencia cohesionada... un juego vamos. Una posibilidad que veo es que estos avances de alguna manera puedan llegar a ser portados a alguna de las decompilaciones o esas decompilaciones ser portadas a las herramientas de desarrollo de la scene (libdragon etc) y así se les puedan implementar estos efectos asombrosos, si es que la consola riende con tanta cosa a la vez. Los juegos minimalistas de la scene siempre me han sabido a poco, aún reconociendo su mérito, y entendiendo que falta mano de obra porque no hay dinero en ello.

En fin, veremos que resulta... aunque yo lo veré de lejos, por haber perdido todo mi material de consolas retro hace unos años.

Señor Ventura escribió:¿Todo esto es para un sdk de dominio público?.

Si, lo es.

@Misscelan @EMaDeLoC

No sabía cómo funcionaba lo de HDR, y no me paré detenidamente a escuchar la explicación de las texturas de alta resolución, así que gracias por eso.

Pero Spooky Iluha menciona especificamente AA y dedither en relación a los problemas con guardar los dos campos del entrelazado en el mismo FB, y son conocidas las "interferencias" que causa la segunda mano de AA que guarda el RDP en los bits extra de la RDRAM y luego el VI usa para suavizar las aristas externas/flotantes (no las internas/conectadas). Si asumimos mi especulación de que el el VI no permite leer un o bien el RDP no permite escribir o el VI leer, o ambas cosas a la vez, un FB de 240 para renderizado y pantalla entrelazadas, si no que requiere que la escritura y/o lectura se haga en lineas alternas del FB en memoria, pero al mismo tiempo, el VI hace AA con lineas adyacentes del FB, ignorando ningún entrelazamiento (cosa que tiene sentido para renderizado progresivo en pantalla entrelazada, tal como se usa en juegos con licencia)... entonces lo que dice Spooky tiene sentido. No puedo decir con total seguridad que eso sea a lo que se refiere, pero con la información disponible, es lo que puedo deducir.

Teniendo en cuenta que lo de HDR, tal como Misscelan lo ha descrito es todo un proceso interno entre el RDP y RSP y al VI no se le da otra cosa que un FB normal... la verdad, no veo de qué manera podría ser la causa de los "artefactos" de los que habla Spooky Iluha.

@radorn no he contestado, pero te he leído. Todavía estoy procesando e intentando entender bien todo lo que has dicho