Hilo de detalles y curiosidades de N64

@Flash-Original En AE por 30€ https://es.aliexpress.com/item/1005005952135414.html
Más o menos la calidad debería ser aceptable.

Me he encontrado esto que es una lista del UCode que se usa en los juegos de N64.
Ucode
Faltan algunos como los de Factor 5, Boss con Ucode propio y de RARE que de estos que yo sepa usan el BK, DKR y GE el F3DEX 1.23, BT y PD que es FDEX 2.08, Conker que es F3DEX 2.06, los Zeldas tienen uno propio que seria como el F3DEX 2.0 y los que sale el RSP SW son F3D el primer microcode de la consola.
En la pagina principal tambien hay cosas curiosas
https://shygoo.net
Salud.

Dejo un vídeo de una demo técnica reciente creada por pekkavaa con libdragon y el microcódigo Tiny3D:


Sorprende el efecto bloom y la sobreexposición lumínica que le da a la demo un estilo artístico sacado de ICO o Shadow of the Colossus. La demo acaba con una muestra muy bestia de algo similar a normal-mapping que casi parece CGI.

¿Alguien podría explicar técnicamente cómo lo hace? Hay algunos mensajes del autor en los comentarios del vídeo, pero estoy espeso y no me entero.

Lo que se está viendo de esta máquina no es normal. Son solo demos, pero indican la bestialidad de cosas que se pueden llegar a conseguir con una buena planificación.

Existe una demo para dreamcast basada en algunos efectos del doom 3, y para algún detalle no me ha convencido tanto como algunas cosas que he visto de n64... supongo que depende de cuanto quieres abarcar...

@Sogun @dirtymagic @EMaDeLoC lo pongo yo antes de que venga @Señor Ventura a aplaudir con las orejas cosas que también hacían Saturn o PlayStation, ya que él se perdió esa generación:



Hack de GoldenEye 007 a 480i, logicamente con peor frame-rate que él ya lamentable original en ese campo, pero no deja de ser 1 currada e impresionante para N64.

@Señor Ventura sabes que esto es entrelazado ¿No? Como los 704x448i del Virtual Fighter 2 de Saturn (@60 fps x cierto), o los 640x480i de ciertos hombrew de PlayStation con Net Yaroze, no son 640x480p reales. Lo digo por si ya estás poniendo a N64 un paso más cerca de Dreamcast

@Sexy MotherFucker
Estos parches ya llevan mucho tiempo circulando. Creo que alguna vez los he mencionado en este hilo. Creía que incluso había puesta escrito un mensaje con imágenes comparativas, pero no lo encuentro.
Algunos se pueden descargar de aquí:
https://github.com/jombo23/N64-Tools/tr ... %20Patches

Los de GoldenEye funcionan bien. Otros introducen fallos y el juego se cuelga. Es todo muy experimental y no está pulido. También es obligatorio el uso de Expansion Pak. El rendimiento es un horror, así que tomadlo sólo como curiosidad.

Existe otro parche para GoldenEye que aumenta la resolución a 440x330 (la resolución de los menús y la secuencia de créditos) y elimina el antialising, por lo que el rendimiento es parecido a la versión comercial.
También hay otro parche para GoldenEye a 640x480i sin antialising con el que pude completar el juego en la dificultad más sencilla. Es bastante injugable y te tienes que saber el juego de memoria para anticiparte a lo que pueden hacer los enemigos y usar estrategias más sigilosas y menos letales.

Esta noche intentaré rescatar las imágenes que saqué de los distintos parches y las cuelgo. Son fotos sacadas a la televisión directamente, pero se ven las diferencias.

Sogun escribió:Dejo un vídeo de una demo técnica reciente creada por pekkavaa con libdragon y el microcódigo Tiny3D:

Sorprende el efecto bloom y la sobreexposición lumínica que le da a la demo un estilo artístico sacado de ICO o Shadow of the Colossus. La demo acaba con una muestra muy bestia de algo similar a normal-mapping que casi parece CGI.

¿Alguien podría explicar técnicamente cómo lo hace? Hay algunos mensajes del autor en los comentarios del vídeo, pero estoy espeso y no me entero.

El autor explica como hizo la demo en su Blog, te lo dejo por si no lo has leído.
https://30fps.net/pages/palette-lighting-tricks-n64/

@Sexy MotherFucker
Como te comentan esos parches existen desde hace mucho, y el rendimiento es el que es.
Me parece más interesante como a conseguido hacer 480i sin tener que hacer un framebufer de 480p en este port de un juego de la scene de DC a N64.



Y aquí la explicación sacada del propio video.

I've been working on a phased RDP/VI interlaced rendering to make sure that the hardware doesn't render any more pixels than necessary at high resolutions.

Since the N64 is mostly fill-rate limited, especially at high-res, its really important to minimize the amount of pixels drawn as it directly corellates to the fps in-game. With that done, the game runs as optimally as it is theoretically even possible. And it pretty much maximizes the N64's capabilities of resolution, framerate, audio and 3d visuals.

In the 1.0 release the game is rendering internally at a 480p but the TV output is still 480i, so I made use of the RDP's special interlaced mode for the optimization. But to actually make proper use of it you'd need a tight phased frame schedule between the RDP and VI to make sure that the frames drawn are latest and complete. Moreover since the AA/dedithering algorithms use adjasent lines which may still be rendering by the RDP, the phased schedule needs to account for that and only use fully drawn framebuffers for the VI.

The expected performance is about 50-60 FPS on fastest setting, 45-50 FPS on normal and 40-45 FPS on nicest setting in the middle of gameplay

Salud.

La scene es impresionante una pena no saber ingles para leerlo pero tiene merito todo lo que sacan ultimameente de la 64, quizas lo pruebe con mi sobrino
¿la IA que tiene es minimamente competitiva?

Pero... ¿como va a ser el virtua fighter 2 de saturn entrelazado y a 60fps?, ¿que me he perdido?.

N64 YA está un paso mas cerca de dreamcast. Osea, que si, que viva la youtube 64 porque nunca la tuve, pero lo que se ve de esta máquina no tiene nada que ver con los 32 bits... texturas super bestias, bump mapping, hdr, color combiner para un efecto chulísimo de iluminación (oclusión ambiental)... cpu sobrada para lo que quieras, y la tecnología de cartucho para darle toda la gasolina que necesita toda esa capacidad.

Esta máquina iba a ralentí en los 90, hay que concederle eso, porque es la verdad.

Edit: Copia&pego de Gemini sobre el articulo de las luces explicándolo en palabras más simples:

explicame este articulo para gente profana de la programación en alto nivel: https://30fps.net/pages/palette-lighting-tricks-n64/

¡Claro! Imagina que tienes una caja de lápices de colores (esa es la "paleta") y con ellos dibujas una imagen en tu Nintendo 64.

Normalmente, para que un objeto en un juego 3D parezca iluminado, la consola tiene que hacer muchos cálculos complicados para cada pequeño punto (píxel) de ese objeto. Esto consume muchos recursos.

El truco del que habla el artículo es una forma inteligente de simular esa iluminación sin tanto trabajo. En lugar de cambiar cada punto del dibujo, lo que se hace es cambiar los colores de los lápices directamente.

Así funciona:

Preparación: Los desarrolladores crean el objeto 3D y le aplican una textura (la imagen que lo cubre). Esta textura usa colores de una paleta específica. También crean un "mapa de normales", que es como una guía que le dice a la consola cómo la luz debería rebotar en cada parte del objeto.
El truco: En lugar de que la consola calcule la iluminación para cada píxel del objeto en tiempo real, el programador hace estos cálculos de antemano en la CPU (el "cerebro" de la consola).
Actualizar la paleta: Basándose en esos cálculos, se crea una nueva paleta de colores ya "iluminada". Si un color era rojo brillante, y la luz viene de un lado, en la nueva paleta ese rojo se vuelve un poco más oscuro en el lado opuesto y más brillante en el lado iluminado.
Aplicar: La consola simplemente usa la textura original, pero con esta nueva paleta de colores "iluminados". El resultado es que el objeto parece tener luces y sombras realistas, ¡pero la consola se ahorra un montón de trabajo!
En resumen: En vez de pintar la luz directamente sobre el dibujo punto por punto, cambias los lápices de colores por unos que ya tienen el efecto de luz incorporado. Esto hace que los gráficos se vean bien y que el juego funcione más rápido en la Nintendo 64, que no era tan potente como las consolas modernas. 🎮✨


Fuentes



hay algun contra en esta tecnica?

Sí, aunque esta técnica es ingeniosa y eficiente para la Nintendo 64, tiene algunas desventajas y limitaciones:

Discontinuidades en el sombreado: Como la iluminación se aplica a la paleta de colores en lugar de a cada píxel individualmente, a veces se pueden notar "saltos" o cambios bruscos en la iluminación, especialmente en superficies curvas o con degradados suaves.
Solo texturas en escala de grises (inicialmente): El artículo menciona que la técnica, en su implementación base, funciona mejor o está diseñada para texturas que originalmente no tienen mucho color (escala de grises), ya que la iluminación "añade" el color. Aunque luego se refina, esto puede ser una limitación.
No hay luces de punto (Point Lights) efectivas: Las luces que emanan de un punto específico en el espacio (como una bombilla o una antorcha) son difíciles o imposibles de calcular correctamente con esta técnica. Está más pensada para luces direccionales (como el sol) o ambientales.
Requiere preprocesamiento elaborado: Crear las texturas, los mapas de normales y configurar todo para que funcione con la paleta requiere un trabajo de preparación considerable por parte de los desarrolladores antes de que se pueda usar en el juego.
Dificultad con las sombras: Representar sombras complejas o dinámicas solo con la paleta de colores es muy complicado. Las sombras suelen necesitar otros métodos.
Iluminación especular limitada: Conseguir brillos especulares (como el reflejo de la luz en un metal) de forma precisa y dinámica es muy difícil, ya que la técnica se centra en cambiar los colores base de la paleta.
Interpolación de la iluminación menos suave: Como los cálculos de cómo la luz interactúa con la superficie (espacios tangentes) son constantes por polígono, la iluminación no se interpola (suaviza) tan bien entre las caras de un objeto 3D como con técnicas más avanzadas.
En esencia, es un truco muy bueno para ahorrar recursos en una consola con limitaciones como la N64, permitiendo efectos visuales que de otra manera serían demasiado costosos. Pero estos ahorros vienen con compromisos en la fidelidad y flexibilidad de la iluminación y los efectos visuales.

Flash-Original escribió:La scene es impresionante una pena no saber ingles para leerlo pero tiene merito todo lo que sacan ultimameente de la 64, quizas lo pruebe con mi sobrino
¿la IA que tiene es minimamente competitiva?

Pero no tienes traductor en el navegador? Aquí tienes la tradu automática:

He estado trabajando en una representación entrelazada de RDP/VI escalonada para asegurarme de que el hardware no rendere más píxeles de lo necesario en altas resoluciones.

Dado que el N64 es mayormente limitado de tasa de llenado, especialmente en alta resolución, es realmente importante para minimizar la cantidad de píxeles dibujados como directamente corellas a las fps en el juego. Con eso hecho, el juego corre de la manera más óptima posible teóricamente. Y maximiza prácticamente las capacidades de resolución, framerate, audio y visuales 3d de la N64.

En el lanzamiento 1.0 el juego está renderizado internamente en un 480p, pero la salida de TV todavía es de 480i, así que hice uso del modo especial entrelazado del RDP para la optimización. Pero para hacer un uso adecuado de ella se necesita un horario de marco escalonado ajustado entre el RDP y VI para asegurarse de que los marcos dibujados son últimos y completos. Además, dado que los algoritmos AA/dediferenciación utilizan líneas adjasent que todavía pueden ser renderizadas por el PDR, el calendario escalonado debe explicar eso y sólo utilizar framebuffers completamente dibujados para el VI.

El rendimiento esperado es de alrededor de 50-60 FPS en el entorno más rápido, 45-50 FPS en lo normal y 40-45 FPS en el entorno más bonito en el medio de la jugabilidad

NINTENDO Space World, en el vídeo se puede ver una versión previa de Pokemon Snap, y del Pokemon Stadium para el 64DD.

@Sogun @dirtymagic yo sólo conocía los modos a "media" resolución. Este de 480i full interlaced es nuevo para mí y me ha sorprendido gratamente a pesar de que el rendimiento global es renqueante, y aunque las zonas y niveles que ya rascaban a 320x240p en el original (como el de la jungla) ahora son casi injugables, pero visualmente es bastante agradable ver de vez en cuando nitidez en una Nintendo 64. Lo he probado en casa de 1 amiguete este finde, y a dobles crashea en algunos escenarios, sobre todo usando C4. Imagino que si ya se ejecutase en progresivo el juego sería 1 pase de diapositivas, pero ya digo, a modo de museo interactivo es interesante.

@Señor Ventura voy a tomar 1 cambio de actitud hacia tu persona cuando discuta contigo. No es sano para mí a mis 43 años dejarme llevar por la bilis a cada rato cual adolescente en el recreo del instituto. Además mis embestidas personales hacia ti no aportan nada al subforo, y después de todo cada uno tiene derecho a opinar lo que quiera

N64 YA está un paso mas cerca de dreamcast

Entonces la SNES ya está 1 paso más cerca de Ps5 por la demo del Raytracing, ¿No?

O la Mega Drive está a 1 paso más cerca del Modo-7@60fps por la demo de Gasega, ¿No?

Por favor, seamos realistas... Todas estas demos tipo HDR, megatextura, etc, con TODOS los recursos del sistema enfocados hacia 1 sola finalidad, únicamente valen para contextos muy sesgados que difícilmente se traducen en el grueso principal de 1 vídeojuego. Cuando entran en escena IAs, colisiones, NPCs, accesos a la ROM, framerates de 30 fps, Z-Buffer, etc, etc, la realidad te golpea. La única demo a la que le veo, PARCIALMENTE, capacidad para convertirse es 1 juego real es la última esa de las texturas hi-res, ya que en cierta medida dependen del tamaño de la ROM. Del resto solamente le veo usos muy limitados en los juegos más allá de detallitos tipo, yo que se, en 1 fist Person Shooters entras en la habitación de un edificio, se borra toda RAM de enemigos y movidas, se desactivan las colisiones, y cuando miras por la ventana de esa habitación el frame-rate baja hasta los 10 fps y surge un efecto pseudoHDR mientras miras por el hueco. Pues vale... Si a ti eso te parece estar 1 paso más cerca de Dreamcast sigue jugando por YouTube.

Por lo demás Nintendo 64 es 1 máquina de la misma generación de PlayStation porque:

- Es 1 consola en esencia de 240p, y que hace sus pinitos en pseudo hi-res entrelazada, como PlayStation.

- Es 1 consola que empuja una media de poligonos 50-100k, y un poco más por encima forzándola, como PlayStation. Incluso quitándole anclas como el Z-Buffer para ganar fillrate la cosa apenas llega @130k @30fps (World Driver Championship). Si le quitas el AA apenas rasca 1 par de frames más. Sin Subfiltro Bilineal no hay diferencia de rendimiento o aumento en la capacidad de proceso. Si no usas Mip Mappings sólo ahorras RAM, no ganas nada más. Etc. Etc. Aunque la obligues a funcionar "desnuda" en juegos nunca llegará siquiera al nivel de una Model 2 (300.000k @60fps), que sería lo intergeneracional de verdad. Bueno aunque la Model 2 usa filtros también.

- Es 1 consola que al final del día trabaja con 1 popurrí de texturas de entre 2/4/8 bpp máximo en los juegos, haciendo algunos pinitos de 16/24 bits en contextos sesgados tales como DEMOS, pantallas de presentación, habitaciones cerradas con carga, etc; como PlayStation. Ya veremos en qué cristaliza la última demo de texturas. Por lo pronto manda el catálogo comercial como principal voz de la razón.

- Es 1 consola que ¡No tiene! Hardware de sonido dedicado, a diferencia de PlayStation. Que sí; que por software quitándole un % a otros componentes se igualan, pero a fin de cuentas hay 1 ausencia donde no debería darse en 1 hardware que se las jacta de superior, y según tus fantasías de "intergeneracional". Menos nunca en más o si quiera igual, sobre todo a nivel físico. PS; Reedbook audio CD + 24 canales ADPCM por software, combo abusador. N64 de 16 a 32 canales según el juego. Normalmente de 20 a 24.

Y luego sí, por supuesto, dentro de su generación era la más potente de todas, una estación de trabajo recortada. En esencia se distinguía por ofrecer un "maquillaje" extra a unos polígonos algo menos bailongos: Subfiltro Bilineal, Trilineal, Mip Mappings Z-Buffer, corrección de perspectiva, etc. Acercando sus gráficos a los ofrecidos por las tarjetas gráficas de PC, con entornos más orgánicos a nivel visual. Un poco como el "Glide" de los pobres Y por supuesto es la que más potencial tiene para florecer en la scene... Pero lo siento, sigue una máquina de la misma generación que PlayStation al igual que Neo Geo AES fue una consola de la misma gen que MD/SNES/PCE aunque fuese la más potente.

En cambio DREAMCAST sí que pertenece a otra generación, porque a diferencia de PS1/N64 en su primer año ya mostraba juegos @640x480p, con 1 millón de polígonos en sus picos máximos, texturas de 16 bits, "self-shadowing" con precisión por vértice por hardware, y casi toda la gama de efectos activados (Filtro Trilineal, Corrección de perspectiva, Mip Mappings, etc) en el PUTO SALÓN de tu casa:



Aunque bueno en el CRT de nuestros padres lo veíamos a 640x480i. Si en 1999 queríamos 480p teníamos que irnos al monitor del PC con cable VGA para que se viese así:



A años luz del Mace: The Dark Age de Nintendo 64, o ya puestos del Soul Edge/Blade de PlayStation. Ambos @320x240@30fps y @512x240p@30fps respectivamente, y con 10 veces menos geometría en pantalla.

Y si te ponías tonto encontrabas también juegos de lucha con 2 millones de polígonos:



O BUMP-MAPPING en juegos comerciales:



O 640x480p en videojuegos "complejos" como te gusta decir a ti:



"Complejos" dentro del rango de potencia de la Dreamcast claro; un hardware de 1998 que si bien se codeaba con las mejores tarjetas aceleradoras y más potentes placas ARCADE del momento, estaba bastante por debajo de 1 GameCube. No me vayas a comparar la "complejidad" de un Shenmue con la de por ejemplo Zelda: Twilight Princess; un título con hasta 3 veces más geometría, escenarios enormes, y efectos gráficos con los que la valiente DC ni puede soñar.

O juegos con 64 canales de sonido arrojando @44.1khz. Aún recuerdo el "RUMBLEEEEEEEE!" del Ready 2 Rumble Boxing de Dreamcast comparado con las versiones de PlayStation/N64. Los colegas del insti se quedaban flipando con el sonido de la blanquita comparando los multiplataformas.

Ésto sí que fue 1 auténtico salto generacional totalmente evidente, sin ambigüedades, apreciable desde la primera experiencia tanto en gráficos como en sonido, los que estuvimos allí entonces lo sabemos, no había debate posible más allá de 1 silencioso o escandaloso reconocimiento. Por eso me resulta entre cómico y ofensivo cuando llega un individuo como tú que ni tuvo, ni tiene, ni pretende tener ninguna de estas 2 máquinas, ergo desconocedor absoluto de los catálogos y el tacto de sus mandos, a opinar sobre una con tanto entusiasmo, denostar a otra con tanta fríaldad, y encima ponerse a compararlas basándose en cosas como 1 video comparativo de los multiplataformas con base técnica PlayStation estilo Shadowman o Vigilante 8... Es que es para indignarse. Aunque claro para entenderte como forero hay que observar las "coincidencias" en tu patrón de opiniones: Principal defensor de SNES en el subforo, principal defensor de GC en su subforo, segundo (con permiso del bueno de Diskover) palmeador oficial de CUALQUIER novedad de Famicom/NES, etc. Se caía de maduro que tarde o temprano ibas a estar haciendo el hooligan por los hilos de Nintendo 64.

¿Te veremos en 1 futuro reivindicando la WiiU o en el foro de Switch 2?



Pero bueno, estás en tu pleno derecho de rendir pleitesía a quien te plazca. Y ya empieza a resultar cansina por mi parte la continua reiteración de tu censurable (en mi opinión) devoción a dicha marca.

Último post al respecto, te doy mi palabra.

color combiner para un efecto chulísimo de iluminación (oclusión ambiental)

No pierdas tu tiempo; si quieres ver los efectos más bestias usando color combiner para simular iluminación y efectos dignos de máquinas más potentes busca en PlayStation 2. Combinándolo junto a su extraordinario ancho de banda verás un interminable desfile de efectos por software tales como: Gloom, Bloom, Depth of Field, Normal Mapping, etc. Y en juegos comerciales, no en demos sesgadas.

¿Está la PS2 1 paso más cerca de la GC o Xbox usando los microcódigos adecuados?

cpu sobrada para lo que quieras

Ni tanto. Si bien es unas 4 veces más potente que la CPU de PlayStation (misma familia x cierto), al final del día el R-4300i no deja de ser sino la versión recortada y abaratada del R-4000; con el bus externo castrado a 32 bits y la FPU mutilada en rendimiento. No va tan sobrada como dices, sobre todo si pretendes paliar otros campos al mismo como el del sonido.

Pero... ¿como va a ser el virtua fighter 2 de saturn entrelazado y a 60fps?, ¿que me he perdido?.

Que los hz de la pantalla no tienen necesariamente que coincidir con los "frames por segundo" a los que funciona un vídeojuego. Olvídate de Saturn; conecta tu GameCube con 1 simple cable de vídeo compuesto. Pon un F-Zero GX o Metroid Prime y comprueba tú mismo como se mueven.

Ah, qué agusto me he quedado lleve o no lleve razón 🤗

@Sexy MotherFucker No entiendo que te enfade que a @Señor Ventura le guste Nintendo. Habla peor de tí que de él que te moleste algo así.

@Falkiño ya he hecho autoterapia, y como digo en mi anterior post es mi última mención a ese hecho. Pero necesitaba 1 último desahogo.

A ti también te chifla Nintendo, pero me da igual porque tú antes de opinar a saco yo se que te has mamado casi todas sus generaciones y máquinas. Hablas de N64 con conocimiento de causa, no basándote en videos de Youtube.

@Sexy MotherFucker Desde SNES las he tenido todas. La NES no, jugué como todos a clónicas en casa de amigos y bueno dos sí tenían la original. Nintendo es mi segunda madre, estás avisado eh
Sobre N64 no he seguido mucho la scene, estoy más centrado en romhacks y cosas que vayan en hardware real: los romhacks estos que solo van en emulador son un engañabobos, en mi opinión.

Un saludo!

Falkiño escribió:@Sexy MotherFucker No entiendo que te enfade que a @Señor Ventura le guste Nintendo. Habla peor de tí que de él que te moleste algo así.

En realidad no me gusta nintendo. Me gustaba la nintendo de los 80, pero desde hace mucho tiempo lo que me gustan son algunos hardwares -a pesar de nintendo-.

Puede que nunca tuviera la nintendo 64, pero la ultra 64, también project reality... esa es patrimonio de todos los que ojeábamos las revistas, y presenciamos el cruis'n usa y killer instinct arcade en rigurosa primicia. ¡Viva la youtube 64!

@Señor Ventura

pero la ultra 64, también project reality... esa es patrimonio de todos los que ojeábamos las revistas, y presenciamos el cruis'n usa y killer instinct arcade en rigurosa primicia

Eso nadie lo niega. En ese entonces la mayoría de "Goldens" que actualmente posteamos aquí éramos fans de Terminator 2 y sus efectos visuales Made in Silicon Graphics:



Cuando Nintendo anunció su asociación con ellos @todos se nos cayeron las pistolas al suelo. El hype fue tremendo al pensar que veríamos esos mismos gráficos en nuestros hogares, como tremenda fue la hostia que muchos se llevaron al final.

Aunque bueno algo de ellos sí que vimos:





Grande Super Mario 64 anyway. De las pocas veces que los usuarios de PlayStation volteábamos la cabeza para mirar a otro sitio. Me hice las 120 estrellas junto a mi hermana en apenas 1 mes.

LOL!

Ese gif del SoulCalibur es mio jajajajaa

@7Force dinos la configuración que usabas!

¿CRT estándar a 480i + RGB o S-Video?

El problema de Ventura es que se emociona rápido y dice afirmaciones un tanto alocadas, como que N64 está cada vez más cerca de Dreamcast lo cual no tiene ni pies ni cabeza. Sexy se enrolla demasiado explicándolo, pero acierta al decir si una MD entonces con las demos de Gasega ya está más cerca del 32X o Saturn, cuando PSX recibió el Quake II en los 90 estaba a un paso de un Pentium II o III? Al final cuando una consola recurre a trucos o a demos enfocadas a lograr algo similar a generaciones posteriores lo que está probando es justo lo contrario, que está muy lejos de esas máquinas que hacen lo mismo con la punta de la p...

PS2 tiene un prototipo con iluminación por pixel, en entornos oscuros y pasilleros, con enemigos y acción ¿Ya supera a GC y se pone al nivel de Xbox?

Además de que incluso en este caso de N64 y DC se ignora lo que su propia scene porque mientras en N64 sacan el Rocket League low-poly de DC o demos de megatexturas, en Dreamcast han porteado dos GTA de PS2 y los han optimizado y mejorado para que gráficamente sean mejores. Y todo funcionando en un CD que es más lento que un GD-rom.

Sin negar que N64 tiene un potencial muy tocho a nivel scene, Portal 64 es un claro ejemplo de que se pueden lanzar juegos nuevos con mecánicas modernas para ella. Pero tampoco creo que Saturn y PS1 no puedan sacar demos de cosas "imposibles" para ellas mediante trucos, de hecho Saturn ya tiene una demo de un "Sonic Metalico" que se suponía era un efecto que solo podía sacar N64 esa gen y PS1 tiene protos adaptando la primera parte de Majoras Mask y su iluminación dinámica. Ambas dificilmente podrían mover un Mario 64 o un Majoras Mask igual que N64.

Sexy MotherFucker escribió:@7Force dinos la configuración que usabas!

¿CRT estándar a 480i + RGB o S-Video?

Retroarch con un shader en una LCD xD

Es muy sencillo. Os estais tomando demasiado en serio afirmaciones que no es posible ser entendidas con literalidad.

Cada uno tiene su forma de ver las cosas, y en ocasiones ciertas afirmaciones son figurativas. Figurativas. Para mi, ver las demos que están saliendo en la n64 lo asocio con cosas que he visto en dreamcast... sobra decir que en magnitudes incomparables, pero, ¿que esos son efectos nativos de la máquina?, pues también.

Dreamcast hace juegos de esa forma, y n64 desvía todos sus recursos para enseñar un fugaz ejemplo de forma reducida, y aún así no al mismo nivel... ya lo sabemos.



Un ejemplo rápido, con compresión de texturas en 16MB de ram, la dreamcast no puede superar de forma clara los 40MB que ocupa el texturizado de la demo de la megatextura (que queden libres entre 6 y 10MB para texturas con una compresión 1:4 o 1:6, desconozco como es). Eso si, podemos contar con que lo haga a 60fps, y mucha mas geometría... pero las texturas... una n64, ojo. Y eso no es todo, ahora pasa de una habitación a otra, estaríamos comparando tiempos de carga con transiciones mas o menos fluídas.


Mini punto para la n64. Para un sistema inferior, eso es mucho.


edit: También es cierto que no debería necesitarse practicamente ningún mip mapping en dreamcast, resultando en un menor malgasto de memoria para una mayor calidad de texturas.

@Señor Ventura sólo para terminar de perfilarla; Dreamcast también tiene 8MB de VRAM aparte de los 16 MB principales, no es memoria unificada. También su chip gráfico @100Mhz es 1 eficiente Tile-Render (el Framebuffer lo dibuja a cachitos para ahorrar ancho de banda) como el Xenos de la 360, tiene compresión de texturas VQ por hardware (que no es gran cosa pero algo ayuda), y su lector óptico es x12 (sobre 1,8 MBs de lectura).

Aunque bueno creo que ya hemos hablado suficiente de Dc en 1 hilo de Nintendo 64.

Señor Ventura escribió:compresión 1:4 o 1:6

4:1 o 6:1.

Hack de Super Mario 64 @60fps intentando que funcione en hardware real:



El juego crashea desde la intro tanto con expansión Pak como con los 4'5MB de stock, 1 pena. Incluso la demo se ralentiza. Al final del vídeo pone otro hack de 2 players, curioso cuando menos.

Eso sí pedazo mod RGB se gasta el pavo. En la Nintendo 64 de mi hermana no se veía así de cristalino ni de Blas

Señor Ventura escribió:Es muy sencillo. Os estais tomando demasiado en serio afirmaciones que no es posible ser entendidas con literalidad.

Cada uno tiene su forma de ver las cosas, y en ocasiones ciertas afirmaciones son figurativas. Figurativas. Para mi, ver las demos que están saliendo en la n64 lo asocio con cosas que he visto en dreamcast... sobra decir que en magnitudes incomparables, pero, ¿que esos son efectos nativos de la máquina?, pues también.

Dreamcast hace juegos de esa forma, y n64 desvía todos sus recursos para enseñar un fugaz ejemplo de forma reducida, y aún así no al mismo nivel... ya lo sabemos.



Un ejemplo rápido, con compresión de texturas en 16MB de ram, la dreamcast no puede superar de forma clara los 40MB que ocupa el texturizado de la demo de la megatextura (que queden libres entre 6 y 10MB para texturas con una compresión 1:4 o 1:6, desconozco como es). Eso si, podemos contar con que lo haga a 60fps, y mucha mas geometría... pero las texturas... una n64, ojo. Y eso no es todo, ahora pasa de una habitación a otra, estaríamos comparando tiempos de carga con transiciones mas o menos fluídas.


Mini punto para la n64. Para un sistema inferior, eso es mucho.


edit: También es cierto que no debería necesitarse practicamente ningún mip mapping en dreamcast, resultando en un menor malgasto de memoria para una mayor calidad de texturas.

Pues aceptando como cierto lo que dices, redacta de forma que se puede diferenciar entre cuando hablas literal y cuando figuradamente porque no te podemos leer la mente, oír el tono de voz ni ver tu lenguaje corporal en un foro. Ahí te van unos tips:

Comillas: Usar comillas puede indicar que una palabra o frase se está utilizando en un sentido especial o no literal. Por ejemplo: Esa noticia fue una "bomba". Sin embargo, el abuso de comillas puede recargar el texto.

Cursiva: Similar a las comillas, la cursiva puede resaltar una palabra o frase, sugiriendo un significado particular. Ejemplo: Su explicación fue cristalina.

Aclaraciones Parentéticas o Guiones: Puedes añadir una breve aclaración.
Ejemplo: "Se le encendió la bombilla (es decir, tuvo una idea brillante) y resolvió el problema."
Ejemplo: "Llovían chuzos de punta —una forma de decir que llovía torrencialmente—."

Expresiones Introductorias: Utilizar frases que alerten sobre el uso de lenguaje figurado.
Ejemplos: "Por así decirlo...", "En sentido figurado...", "Como si dijéramos...", "Metafóricamente hablando...", "Dicho de otro modo...", "Valga la expresión...".

Preguntas Retóricas o Exclamaciones: A veces, la propia estructura de la frase puede sugerir que no se busca una interpretación literal.

Lo de Dreamcast y las texturas, el tipo de compresión que pueden manejar las consolas depende del tipo de datos que se quieran comprimir, tipo de texturas en este caso, la DC según el tipo de textura va de 4:1 a 16:1. Si pillamos un tipo de texturas que se pueda comprimir a 8 y usamos 10 megas de esa VRAM ya tenemos 80 megas de texturas. En todo caso, yo he probado la demo de megatexturas y, no sé el motivo, pero o no está volcando todas las texturas comprimidas en RAM sino que las va cargando según el movimiento de la cámara o, si las carga completas, tiene un grave problema que no se puede ignorar y es que al moverse y acercarse o alejarse y cambiar el grado de detalle de las mismas va a "golpes" lo que sería porque el hardware (supongo que la CPU) no puede manejar fluidamente esas tasas de compresión para hacer un juego, en una demo donde vas sólo a sacarte la p... da igual, lo que importa es que hay fotogramas estáticos donde se ve una calidad muy buena de texturas, pero en perspectiva global no puedes hacer un juego con esos saltos, bueno poder puedes, pero vamos que no es como para decir que N64 maneja esas calidades sin contratiempos. Y como ya ha dicho Sexy, esa demo se enfoca sólo en ese aspecto, metele unas físicas, IAs, colisiones, efectos gráficos o animaciones y terminarás de nuevo con un juego de calidad gráfica del catálogo de N64. Que podemos luego imaginar un juego con calidad estandar de N64 que por ejemplo al entrar en una tienda cambie a primera persona y podamos observar los items a comprar a esas calidades pues sí, pero va a ser algo muy secundario y limitado. Que no es nada nuevo, en RE1 de PS1 cuando observas items en el inventario sube la calidad de texturas, en Shenmue en DC en el disco passport puedes ver modelos de los personajes a calidades pepino porque solo se centra en renderizarlos a ellos, los menús de muchísimos juegos de todas las generaciones suelen subir resolución y en muchos casos incluso se mueven a 60fps, etc.

Sexy MotherFucker escribió:Eso sí pedazo mod RGB se gasta el pavo. En la Nintendo 64 de mi hermana no se veía así de cristalino ni de Blas

Tiene pinta de ser mod HDMI, o el RGB con algún filtro de enfoque del editor de vídeo.

@EMaDeLoC se ve de la hostia.

Aunque yo seguiré fiel a mi S-Video cuando vuelva a tener una N64 de nuevo; la FIEL representación de lo máximo que podías conseguir en la consola a no ser que fueras japonés o francés.

Sexy MotherFucker escribió:@EMaDeLoC se ve de la hostia.

Aunque yo seguiré fiel a mi S-Video cuando vuelva a tener una N64 de nuevo; la FIEL representación de lo máximo que podías conseguir en la consola a no ser que fueras japonés o francés.

Ninguno de los dos tenian RGB de serie. Los mods se descubrieron después del fin de vida de la consola, si no me equivoco.

@EMaDeLoC juraría que hubo 1 par de tiradas en ambos países que cuando menos RGB Sync-on composite aceptaban de serie.

Tú deberías saberlo mejor que yo

Superpadland, es que la demo de la mega textura no hubiera tenido que ser posible dada su generación... o las que involucran al color combiner, como bastantes otras cosas... visualmente conceptualmente hablando la n64 está a los pies de la montaña next gen, pero está junto a la montaña, no lejos. No hace falta compensar ninguna aprosodia, ni mucho menos explicarlo para observar eso, porque se ve a simple vista lo que son todas estas cosas.

Decir que esto recuerda al doom 3 de la xbox debe entenderse en su contexto:




Que por cierto, he notado que el cambio de iluminación no sucede mientras se mueve la cámara... aunque en la demo del castillo el bump mapping + oclusión ambiental si sucede mientras hay un desplazamiento... aunque no de la cámara...

¿Son coincidencias?.



P.D: En vcdecide estarán complacidos de enseñar que eso no es de nintendo 64 xD

Señor Ventura escribió:Superpadland, es que la demo de la mega textura no hubiera tenido que ser posible dada su generación... o las que involucran al color combiner, como bastantes otras cosas... visualmente hablando la n64 está a los pies de la montaña next gen, pero está junto a la montaña, no lejos. No hace falta compensar ninguna aprosodia, ni mucho menos explicarlo para observar eso, porque se ve a simple vista lo que son todas estas cosas.

Decir que esto recuerda al doom 3 de la xbox debe entenderse en su contexto:




Que por cierto, he notado que el cambio de iluminación no sucede mientras se mueve la cámara... aunque en la demo del castillo el bump mapping + oclusión ambiental si sucede mientras hay un desplazamiento... aunque no de la cámara...

¿Son coincidencias?.



P.D: En vcdecide estarán complacidos de enseñar que eso no es de nintendo 64 xD

Bueno sí, si la montaña es de 7000m te compro la analogía. No es que no me sorprendan esas demos y me gusta probarlas en mi N64, pero siguen siendo eso demos. Es como el T-Rex de PS1, no vimos unos gráficos así en ningún juego del catálogo o como el raytracing nativo de PS2 para la demo queda genial, para hacer juegos no.


Lo de la iluminación de ese vídeo ya me pilla demasiado novato para captar bien lo que está logrando, o sea veo la iluminación dinámica que va cambiando por el entorno y supongo que será más realista o detallado que la iluminación dinámica de Exhumed o Terracon, pero me cuesta apreciarlo, aunque evidentemente no hicieron una demo así si no estuvieran logrando algo nuevo:



Personalmente me llama más la atención la demo de megatexturas porque es más fácil de apreciar los cambios de calidad en el CRT.

@Sexy MotherFucker Pues no, todas eran modificando.
Quizá te refieres que eran la modificación fácil, con solo un amplificador de vídeo, o el sistema a lo bruto de conectarlas directamente, que daban imagen oscura y se podía quemar el chip de vídeo.
Pero de una forma u otra había que abrir la consola y soldar, no era "de serie" o solo enchufar el cable.

@SuperPadLand
La Demo que a puesto es de un pseudo Bumpmapping.

A mí la demo de la mega textura, me parece que no tiene más recorrido que el de esa demo, yo al menos no tiraría por esa vía ni para hacer un juego rollo Myst, limita mucho la creación de un juego, la forma que tiene de trabajar.
Mi experiencia es que me parece más beneficioso para la scene, que se haya desarrollado unas texturas que se llaman IHQ y SHQ, que ambas permiten texturas de 64x64 ( o otras relaciones de aspecto con la misma densidad de píxeles) a 16 bits de color y un 1 bit de trasparencia, la primera incluso permitiendo Trilinear mipmapping.
Básicamente es el mismo concepto que ya se conocía de mezclar con el color combiner una textura de 32x32 a 16 bits y otra de 64x64 en 4 bits de escala de intensidad, que necesitaba 2 cycles para mezclarlas y dibujarlas, lo que han conseguido con esto es hacer lo mismo usando sólo el modo de 1 cycle del color combiner.

Los contras es que sólo se puede usar en homebrew nuevo que use Libdragon ya que usa MKsprite para cargar este tipo de texturas, se puede ver su uso en el juego Driver Strikers 64, junto al efecto Bloom y en 480i.

Salud.

Iluminar una textura por vértice se lleva haciendo desde antes de la playstation, la diferencia es que la n64 parece controlar la dirección en toda la textura, de forma que no solo se simula una iluminación global, sino que puedes proyectar la sombra de lo que parece ser una columna, o detalles individyales como los socavones, de forma independiente.

Es bastante mas complejo lo que se ve en el gif, de hecho playstation creo que no tiene color combiner, la forma de llegar a ambos resultados es incluso también diferente.

Pero me sigue llamando la atención que suceda con la cámara estática, pero que cuando se produce un movimiento la iluminación ya deja de ser dinámica... igual es solo coincidencia.

Prototipos de NINTENDO 64 DD encontrados.

dirtymagic escribió:@SuperPadLand
La Demo que a puesto es de un pseudo Bumpmapping.

A mí la demo de la mega textura, me parece que no tiene más recorrido que el de esa demo, yo al menos no tiraría por esa vía ni para hacer un juego rollo Myst, limita mucho la creación de un juego, la forma que tiene de trabajar.
Mi experiencia es que me parece más beneficioso para la scene, que se haya desarrollado unas texturas que se llaman IHQ y SHQ, que ambas permiten texturas de 64x64 ( o otras relaciones de aspecto con la misma densidad de píxeles) a 16 bits de color y un 1 bit de trasparencia, la primera incluso permitiendo Trilinear mipmapping.
Básicamente es el mismo concepto que ya se conocía de mezclar con el color combiner una textura de 32x32 a 16 bits y otra de 64x64 en 4 bits de escala de intensidad, que necesitaba 2 cycles para mezclarlas y dibujarlas, lo que han conseguido con esto es hacer lo mismo usando sólo el modo de 1 cycle del color combiner.

Los contras es que sólo se puede usar en homebrew nuevo que use Libdragon ya que usa MKsprite para cargar este tipo de texturas, se puede ver su uso en el juego Driver Strikers 64, junto al efecto Bloom y en 480i.

Salud.

Coincido, pero vamos que de querer usarse para algo en un juego no sería para un juego completo sino para cosas muy específicas y puntuales. Al igual que ya en los Zeldas usaron fondo pre-render para interiores porque permitían un mayor grado de detalle y calidad gráfica, pero el 99% del juego es 3D poligonal.

Señor Ventura escribió:Iluminar una textura por vértice se lleva haciendo desde antes de la playstation, la diferencia es que la n64 parece controlar la dirección en toda la textura, de forma que no solo se simula una iluminación global, sino que puedes proyectar la sombra de lo que parece ser una columna, o detalles individyales como los socavones, de forma independiente.

Es bastante mas complejo lo que se ve en el gif, de hecho playstation creo que no tiene color combiner, la forma de llegar a ambos resultados es incluso también diferente.

Pero me sigue llamando la atención que suceda con la cámara estática, pero que cuando se produce un movimiento la iluminación ya deja de ser dinámica... igual es solo coincidencia.

Y en la demo dicen si todo eso es en tiempo real o precalculado? porque me parece raro que GC tenga que llevar precalculado las sombras y luces del Luigi y que esta demo de N64 no sea algo parecido.

Dado que este es 1 hilo centrado en lo técnico vamos a sacarle provecho.



@dirtymagic @EMaDeLoC @Sogun @Conker64 @Misscelan OS invoco como máximos conocedores de las tripas de Nintendo 64 que conozco en castellano y en la vida en general A ver si alguno tenéis a bien arrojar un poco de luz en mis tinieblas personales:

- Aparte de World Driver Championship en el cual prescindieron del Z-Buffer para ganar tasa de relleno, y por ende aumentar el polycount más allá de lo habitual hasta unos destacables 120-125k @25-30fps bastante estables; ¿Se conoce de algún otro título que se pase por el forro el microcódigo de Nintendo para ir más allá de los límites impuestos por éste? Pedazo labor de optimización BTW sin la ayuda de Z, aunque supongo que al ser un Racing Game/pasillo con curvas es más sencillo establecer una display list sin mucho overdraw.

- Siguiendo con carreras; ¿Alguien sabe los números de Ridge Hacer 64? Polycount, fps, resolución, efectos, etc; la sensación de velocidad siempre me ha impresionado. Va FOLLADO. Aún suponiendo que casi seguro va @30fps los coches van más rápido que en casi todos los RR de PlayStation, aunque como juego no sea tan bueno y redondo como un Type-4.

- Los cartuchos de N64 tienen un máximo de 64MB/512 Mega bits es debido a que la consola no puede mapear más allá de esa cifra ¿?

Gracias de antemano.

@Sexy MotherFucker para ir más allá de los límites ni idea, pero Factor 5 usó microcódigo propio para Star Wars Rogue Squadron, Star Wars Episode I Battle for Naboo e Indiana Jones and the Infernal Machine. El caso de Rogue Squadron es la leche porque ese juego directamente tiene drivers de sonido escritos directamente por Factor 5, no utiliza los estándar, son totalmente propios.
También de Nintendo y RARE se dice que F-Zero X, Zelda Majora's Mask, Conker's Bad Fur Day, Donkey Kog 64 y Perfect Dark usan microcódigos propios y no los estándar de Nintendo con el kit de desarrollo. Ignoro la veracidad de esto.

Sobre la cantidad de ROM usable ignoro la capacidad pero los chinos venden repros de por ejemplo los 3 Mario Party en 1 cartucho y en el destripe sale que tienen dos chips de 512 Mbits, o sea 128MB en total, y funcionan en las N64 de stock sin problemas. No sé si los lee tal cual o usan mapeadores y bank switching.

Un saludo!

EDIT: estoy mirando por ahí y leo que Nintendo 64 puede usar sin mapeadores ni ayuda extra hasta 240MB de ROM.

@Sexy MotherFucker
Hola, no estoy muy participativo pero he visto la mención.

1) El Stunt Racer 64 de Boss Studios creo que también usa el z-sort, es posterior al WDC, supongo que menos conocido por no salir en Europa, no es un juego realista, así que los escenarios son en plan mundo de la piruleta o casa del terror en una pista rollo F-zero.

Puedes ver los distintos circuitos en el vídeo, los detalles suelen ser bastante redondeados, incluidas las curvas de las pistas, y el rendimiento es bueno, pero hasta Twisted Edge Extreme Snowboarding rinde bien, sabían como trabajar con la consola.


2) A mi me da que es más por velocidad de desplazamiento y la forma en la que choca con las barreas, que es como hacia adelante.

Hay extracciones poligonales en el hilo, y es probable que ponga puntos sobre 60K, tiene geometría optimizada, es decir si necesita superficies grandes las usa, por la corrección de perspectiva.

Igual Misscelan te puede ayudar en el resto de datos o en extracciones, que tiene un setup más actualizado con un polycount más exacto.

3) 64MB es el tope al que llegaron en la vida comercial, los cartuchos flash para ahorrar costes metían memorias de 64MB, pero ahora que la scene está despegando ya se empiezan a ver cantidades superiores, te pongo un fragmento de la SummerCart 64:

Sus principales características incluyen 78 MiB de memoria combinada (64 MiB SDRAM + 14 MiB flash), soportando ROMs más grandes que los cartuchos estándar de N64, además de emulación de hardware 64DD para volcados directos de disco, juegos multi-disco y títulos combo (cartucho + disco)

En teoría para acceder a esos 14MB el SDK debería ser moderno y preparar la rom para ello, no pongo la mano en el fuego sin haberlo probado, además de que solo funcionaría en esa flash, el tema emuladores, puede que muchos fallen al pasar de 64MB, por no estar preparados.

Luego estaría lo que comenta Falkiño, cartuchos piratas, homebrew en cartuchos de más capacidad, etc

En cuanto a los límites reales, puedes leer un artículo en n64brew

@Sexy MotherFucker
Creo que como han comentado ya juegos que yo conozco que hacían cosas raras, pero siendo un poco tiquismiquis, el uso o no del zbuffer no depende de usar micro códigos propios, incluso en el SDK oficial se puede desactivar el zbuffer por primitiva.

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.

En casi todos los microcódigos (oficial y custom) el RSP espera los vértices en fixed-point (16.16) siendo los 2 primeros bits de la parte decimal los que se usaban para la subpíxel-precision del raster, así que si limpias esos dos bits antes de que entren al RSP, también te saltas eso y puedes tener polígonos “bailongos”.
De una manera parecida te puedes cargar la proyección de perspectiva si tocas las W de la matrix de la inv de la cámara.

Para tocas todas estas cosas era bastante fácil incluso en aquella época, las dos últimas tendrían 0 efecto en el desempeño, las otras dependiendo del caso podrían. Pero no sé cómo Nintendo se aseguraba de que nadie tocaba en eso.

En términos generales puedes hacer una pipeline con todas las “features” desde la CPU sin microcódigo (el RSP solo es un facilitador), al final el RDP espera unos paquetes con el tipo de primitiva (triangulo FLAT SHADED/GOURAUD, con/sin TEXTURA, con/sin ZBUFFER), los coeficientes/pendiente de cambio de cada uno de esos valores (normalmente se encarga el raster pero en n64 eso ha sido externalizado - si tienes curiosidad aquí puedes ver el cálculo esos coeficientes en c: https://github.com/DragonMinded/libdragon/blob/trunk/src/rdpq/rdpq_tri.c ). La ventaja de hacerlo en el RSP es que puedes paralelizar algunas instrucciones haciéndolo más rápido que la CPU y que trabaja dentro de su cache sin molestar a nadie, aunque la transferencia de datos de la RAM a su cache y de vuelta a la RAM tiene también un coste.

Sobre el WDC, he oído mucho baile de números, en esa época se tiraban muchos triples y me huele a un caso similar a Vagrant Story donde más tarde con emuladores se vio que los números no eran tales. El problema de medir los polígonos en n64 es que no conozco ningún emulador que intercepte los paquetes que se envían al RDP, la única manera que conozco es hacer una extracción de los paquetes enviados al RSP y luego importas eso en Blender (y ni esto funciona en el WDC y funciona regulero en otros juegos como Indy), pero en esa extracción se cuelan los polys con backface culling (los que están de espaldas a la cámara), y los que deberían estar fuera del frustum de la cámara. El backface culling lo puedes más o menos calcular si sabes donde estaba la cámara, el frustum tienes que saber el FOV, y los planos de corte cercano y lejano y eso es más difícil de conseguir, así que generalmente los números que ves son aproximaciones y no números concretos.

Sobre RR, no se como mandar links directos a post, pero subí una extracción hace algún tiempo, la deberías ver por aquí: https://www.elotrolado.net/hilo_hilo-de-detalles-y-curiosidades-de-n64_2171497_s3500

Es un extracto al iniciar la carrera, ves que tiene 2177 triángulos, pero como te comentaba se puede ver que están incluidos los que están hasta detrás de la cámara, también había unos cuantos a derecha e izquierda que estaban seguro fuera del frustum, y no hay ningún tipo backface culling.
Aunque los números de polígonos de N64 siempre serán más efectivos en términos prácticos que otros de esa generación ya que no requieres subdivisión de los cercanos.

@Sexy MotherFucker

Básicamente es lo que comenta @Misscelan

Los microcódigos son por un lado plantillas y por otro lado optimizaciones en como procesa los datos el RDP.

Por ejemplo el primer microcódigo acepta todos los efectos en tema de filtrado de texturas,anti-aliasing, Tri-linear mip mapping, mezcla de 2 texturas , environment mapping ect....
Los siguientes microcódigos añadían optimizaciones para procesar más vértices y acotar lo que se renderizaba , como el sccisor y frustum o el cull manual, incluso el backface culling, no estaba en el primer microcódigo.

El F3DEX3 que es el microcódigo hecho por la comunidad (Sauraen),que tiene todas estas mejoras en comparación con los anteriores.
F3DEX3

Y es el único que que permite medir el rendimiento de los juegos de forma precisa, el problema es que hasta donde yo sé los únicos juegos comerciales que se pueden compilar con este y poder activar los medidores son las decomp de SM64 y OOT/MM.
Aquí sale toda la información que arroja, entre ellos los triángulos calculados y los que dibuja.


Salud.

Señor Ventura escribió:Pero me sigue llamando la atención que suceda con la cámara estática, pero que cuando se produce un movimiento la iluminación ya deja de ser dinámica... igual es solo coincidencia.

@Misscelan perdona que te pregunte que supongo estarás liado o no te apetecerá enrollarte con tecnicismo, pero lo de la demo esta de iluminación: https://30fps.net/pages/palette-lighting-tricks-n64/

Según el truco explicado de su autor, consiste en cambiar paletas precalculadas (muy resumidamente) ¿Este clase de truco no sería trasladable a SS o PS1 aunque fuera más limitado? En el caso de SS usando su expansión de 4MB si es necesario y que imagino valdría para almacenar los precalculos necesarios.

@SuperPadLand
Puedes usar ese tipo de fake normal mapping hasta en VGA:


Básicamente generas una imagen base y una paleta por cada nueva dirección de luz (o al menos el método que conozco yo), ósea quieres 16 direcciones de luz, pues 16 paletas (pero una sola imagen).
Y sí, de eso ya hay ejemplos en Saturn (este es de un usuario que hace homebrew, pero si mal no recuerdo tenías hasta un ejemplo en el SDK original):


Y en PSX:
https://streamable.com/upgrpu

EDIT: he cambiado el video de Saturn que había subido uno incorrecto.

@Misscelan el de SS con los planos infinitos queda bastante resultón. Gracias por la explicación y las demos!

@Falkiño @Misscelan @dirtymagic @Conker64 gracias a todos.

Un par de cosas:

@Misscelan

El problema de medir los polígonos en n64 es que no conozco ningún emulador que intercepte los paquetes que se envían al RDP

así que generalmente los números que ves son aproximaciones y no números concretos.

¿Esto es 1 problema generalizado en todos los emuladores de sistemas que emplean Z-Buffer, o sólo atañe a la Nintendo 64?

Porque entonces los cálculos vía emulador para PS2, GameCube, o Xbox también serían engañosos...

Si no recuerdo mal Perfect Dark lo desactivaba en algunas ventanas con luz de edificios para que fuesen más definidas.

Si no recuerdo mal Quake también te dejaba desactivar el AA en las opciones, aunque si te digo la verdad no recuerdo que influyese directamente en el rendimiento, si bien sí en la nitidez del entorno; en mi opinión mucho más recomendable jugar con éste desactivado.

Lo que realmente me impresiona de la N64 es que fue 1 máquina excesivamente adelantada a su tiempo. Conceptualmente incluso podría decirse que es más moderna que Dreamcast y PlayStation 2, ya que en éstas toda la fase de transformación e iluminación de la geometría se gestaba vía CPU y luego se mandaba el resultado a los chips gráficos que eran poco más que rasterizadores con un set de efectos gráficos incluidos; mientras que Nintendo 64 ya jugueteaba con el concepto de "GPU" independiente de la CPU para dichas labores si así se quería. Memoria unificada, etc; fue una visión -muy prematura- al futuro.

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:

@Sexy MotherFucker
En teoría no debería, pero al final eso depende del emulador, aunque el sistema tenga z-buffer la primitiva tiene que llegar al raster y ahí decidir pixel a pixel si lo pinta o no.

En el caso de N64, puede ser también que muchos emuladores no se hayan molestado en implementar el RSP ni el RDP y simplemente capturan los triángulos que se van a mandar al RSP y se los mandan a OpenGL para que le haga todo el triaje de polígonos sin que ellos se preocupen.

Yo pa hacer homebrew uso el Ares que es el que para mí, el que más se acerca en FPS y fidelidad visual a lo que muestra la consola, este seguro que tiene su implementación propia del RSP y el RDP pero tampoco he cacharreado mucho para saber que opciones de debug tiene.

Otro ejemplo en otra plataforma, la PSX que no tiene z-buffer tampoco suele mostrar resultados de triángulos correctos, los emuladores para esta consola normalmente capturan los paquetes que se van a enviar a la GPU y te muestran eso como “Polígonos” o “Primitivas” pero tienes que inspeccionar cada paquete (si el emulador lo permite) para saber si es un quad que se divide en 2 triángulos (si lo que quieres es contabilizar triángulos).

Creo que a los que crean emuladores, mostrar el numero correcto de triángulos renderizados se la trae un poco al pairo, y si tú como usuario quieres comparar entre versiones y consolas se convierte en un trabajo a tiempo completo.

Respecto a lo de los chips de apoyo el GTE de PSX también te hace las transformaciones, las proyecciones y los cálculos de luz al margen de la CPU principal. Todas las consolas de esa generación incorporaron con mayor o menor suerte chips de apoyo para esas tareas (con la única excepción de Jaguar sino recuerdo mal, que aun así su procesador encargado de rasterizar tiene opcodes para las multiplicaciones de matrices por ejemplo). Pero el RSP es la mejor versión de todos los chips de apoyo porque no solo puede hacer lo que las otras sino que además es programable.

@EMaDeLoC
Sí tienes razón, me equivoqué, era el filtrado de texturas.

@Misscelan sólo 1 apunte:

Respecto a lo de los chips de apoyo el GTE de PSX también te hace las transformaciones, las proyecciones y los cálculos de luz al margen de la CPU principal

Pero el GTE está alojado junto a la CPU, es 1 coprocesador de apoyo para el R-3000, del mismo modo que en los PC del momento las transformaciones 3D las ejecutaban las FPU de sus CPU, es decir; todo el proceso era paralelo al sistema gráfico (tarjetas aceleradoras/VDPs/etc) sí o sí, con buses bien separados.

En cambio cuando en PC llegaron las GPUs con Vertex y pixel Shaders (Nvidia nosecuantos fue la primera) los procesadores gráficos tomaron las riendas de todos los cálculos para la geometría. Y en consolas ocurrió cuando llegaron la GameCube con sus TEVS y la Xbox con su GeForce "3'5" custom.

El asunto es que la Nintendo 64 se adelantó al PC 4 años, y a las GC/Xbox 5 años, ya que a pesar de la potencia y modernez de sus chips gráficos Dreamcast y PlayStation 2 seguían funcionando "a la antigua".

3DO, Saturn, PlayStation, los PC/Pentium, etc, tenían su hardware para cálculos geométricos bien en su CPU a modo de FPU/copro-matricial, o a modo de chip custom 100% programable y/o procesador de punto fijo alojado en un lugar separado y/o casi aislado del resto de componentes. Siendo la Saturn el Frankestein por antonomasia con su doble CPU, SCU-DSP, M68000 accesible, etc.

Nintendo 64 por contra a pesar de no tener TEVs, Pixel o Vertex Shaders, ni mucho menos los actuales Shaders unificados, a diferencia de los PC y consolas de su tiempo sí que tenía un sistema gráfico 100% independiente equipado con hardware para cálculos 3D (RSP). También fue pionera en el uso de memoria unificada en consolas, de hecho su esquema base fue copiado y mejorado a partir de la GC tanto por la propia Nintendo, Sony, o Microsoft, con la excepción de ese bicho raro que fue la PS3.

Coño para una vez que trato de elogiar a la N64 en algo no me cortéis el rollo xDDD

@EMaDeLoC gracias por el apunte