Hilo de detalles y curiosidades de N64

SuperPadLand escribió:@dirtymagic como hablaba con Ventura hace años, la constante de todas las consolas, al menos las retro, es que siempre se quedan cortas por A o por B en memoria RAM

De todas formas yo más que ver como sería una N64 con un RAM veloz, me conformaría con ver algunas optimizaciones de juegos que salieron apoyándose en la expansión de RAM para mejorar rendimiento, enemigos en pantalla, etc. Es algo muy inexplorado, supongo que será complicado, en Saturn apenas hay de estos hacks que mejores juegos oficiales usando los 4mb de la expansión (creo que sólo algún KoF y Castlevania)

No te creas que está tan inexplorado, al menos en lo que yo manejo, que son los mods sobre los motores del Mario64 y Zelda, ambos se apoyan en el EP, para de primeras cargar mucho más escenario, LOD y variedad de NPCs, que los originales, pero la tónica que veo es que hay como un límite de Fillrate, que no permite tener más FPS, y todos los esfuerzos parecen ir encaminados a poder mostrar más efectos y técnicas más modernas, que en mejorar la tasa de fotogramas, porque al final la arquitectura de la memoria hace que una parte pueda procesar mucho más, porque le da tiempo a ello, pero si hace menos tampoco mejora los FPS, no sé si me explico 😅 .
@EMaDeLoC ¿ Pero lo que comentas, la memoria de la iQue lo solucionaría?

Salud.

@dirtymagic pues no sabía, pero aun así molaría ver algunos updates de los originales aunque no mejoren el framerate y mejoren otras cosas. Es decir, si no puedes darme un Zelda a 30FPS sólo con la RAM pues me vale que sea el mismo Zelda a 20FPS, pero con más distancia de dibujado por ejemplo Es sólo por conocer cuanto más podría haber dado la máquina de haber salido con los 8MB incialmente.

Aunque también está lo de optimizar realmente los originales para subir el rendimiento como Mario 64 funcionando a 60fps por ejemplo, eso es una locura, lo que nos perdimos en la época simple y llanamente por una mala documentación y mejores estaciones de desarrollo.

dirtymagic escribió: @EMaDeLoC ¿ Pero lo que comentas, la memoria de la iQue lo solucionaría?

No creo que lo este solucionando, para eso habría que modificar la arquitectura del RCP y eso es un trabajazo caro. Yo creo que lo único que ocurre es que al estar todo el sistema overclockeado en la iQue, el rendimiento esta por encima del de una N64 normal y los juegos no llegan al límite donde se producen los problemas de rendimiento.
Si la N64 puede dar 25fps en un juego (dato inventado), la iQue, al estar overclokeada un 50%, podría dar 35fps, y luego el frame limit o como se llame lo pone a 30fps.

Vendría a ser como un PC al que rasca un juego, le haces overclock y ya no rasca. No has solucionado ningún problema de arquitectura, has subido el rendimiento hasta que el problema ya no es apreciable.

@EMaDeLoC la gamecube es un fenómeno de la optimización.

Sus fallos:
-El rasterizador tarda mucho mas en generar un triángulo de lo que la unidad geométrica era capaz de calcular. Si ya era una máquina competente escupiendo polígonos, con un rasterizador a la altura de las circunstancias doblas las cifras, y eso como mínimo, lo cual hubiera sido salvaje.

-Juego de instrucciones altivec ausente. Hubiera supuesto un empujón considerable en el rendimiento.

-Compresión de texturas asimétrica. Ocupa lo mismo una textura de 8 bits que una textura de 24 bits, y es un desperdicio de ancho de banda.

-Framebuffer justito.


Así a ojo, esto es lo que mas se le puede achacar.



Editado.

Dejo un par de links con mucha información que me gustaría contrastar, que así no los pierdo (ya los quitaré del hilo).

https://disruptiveludens.wordpress.com/ ... nt-page-1/

https://disruptiveludens.wordpress.com/ ... amecube-2/

SuperPadLand escribió:@dirtymagic pues no sabía, pero aun así molaría ver algunos updates de los originales aunque no mejoren el framerate y mejoren otras cosas. Es decir, si no puedes darme un Zelda a 30FPS sólo con la RAM pues me vale que sea el mismo Zelda a 20FPS, pero con más distancia de dibujado por ejemplo Es sólo por conocer cuanto más podría haber dado la máquina de haber salido con los 8MB incialmente.

Aunque también está lo de optimizar realmente los originales para subir el rendimiento como Mario 64 funcionando a 60fps por ejemplo, eso es una locura, lo que nos perdimos en la época simple y llanamente por una mala documentación y mejores estaciones de desarrollo.

En Romhack está la rom del OoT de iQue y aparte de exigir el EP, me suena que dice que tiene más distancia de dibujado, lo cual no me sorprende por que los mods permiten cargar escenarios más grandes.
El Marioo64 ya le da un buen turbo de rendimiento utilizar F3DX2 en vez del F3D original ,ya que activa back culling , Z sort y scissor, así que no tiene que renderizar las caras ocultas de los personajes, las partes del escenario, que las tapan otras partes ( por eso la campiña de Hyrule tiene esa forma de "donut") y recorta la parte de escena que se sale X píxeles de la cámara.Lo cual no hacía el original.
Salud.

SuperPadLand escribió:

coyote-san escribió:@SuperPadLand

Jugué a Mario 64, a los Crash y a los Spyro en su época, y fue entonces cuando me di cuenta de que Mario está por debajo de ellos. Sois los fans del Mario los que lo tenéis idealizado en la época actual.

Fijate si estás equivocado que yo no jugué Mario 64 hasta el 2016, Crash sí y el Spyro en la demo que traía mi PS1 aunque ambos los vicie a fondo hace unos años también. Y precisamente ese es el detalle que yo no estoy opinando desde recuerdos del pelo largo o gustos personales, simple y llanamente opino de lo que ofrecen técnicamente esos juegos y que no va reñido con que te guste más uno que otro, Crash es más plataformas puro y M64 exploración ahí entran los gustos, ahora lo que técnicamente está procesando M64 es mucho más complejo que lo que se procesa en Crash 1.

GValiente escribió:

coyote-san escribió:Jugué a Mario 64, a los Crash y a los Spyro en su época, y fue entonces cuando me di cuenta de que Mario está por debajo de ellos. Sois los fans del Mario los que lo tenéis idealizado en la época actual.

Yo jugué a los dos (Mario y Crash) en su día cuando salieron, y aunque el Mario 64 es mil veces mejor juego, el Crash me parecía (y me sigue pareciendo) que tenía mejores gráficos.

El Spyro es el peor juego y el más feo de los tres

Crash es un pasillo donde poner toda la carga gráfica, Spyro es un mundo abierto al igual que Mario por eso tiene peor calidad, pero lo que ofrece es técnicamente más amplio y complejo que Crash.

a simple vista los crush engañan un poco, parecen muy potentes técnicamente, pero es un plataformas sobre rieles digamos, así como los panzer dragon(el zwei se ve muy lindo). lo que si ayuda mucho a ps1 es la calidad de las texturas y una mayor claridad en la imagen respecto a n64, aunque un banjo kazooi es un ejemplo de lo que no se puede en ps1 y saturn, el entorno que puede generar esta consola, venir volando de una montaña y ver casi todo el mapa desde arriba, desde abajo a lo lejos, los filtros y efectos grafico que se aplican.... seguramente el framerate no debe llegar a 30, ahora no lo recuerdo. para mi ps1 generando entornos 3d esta entre una saturn, la cual usa fondos y objetos con motor 2d y 3d y una n64 que puede mostrar otras mejores perspectivas.

cristus escribió:

SuperPadLand escribió:

coyote-san escribió:@SuperPadLand

Jugué a Mario 64, a los Crash y a los Spyro en su época, y fue entonces cuando me di cuenta de que Mario está por debajo de ellos. Sois los fans del Mario los que lo tenéis idealizado en la época actual.

Fijate si estás equivocado que yo no jugué Mario 64 hasta el 2016, Crash sí y el Spyro en la demo que traía mi PS1 aunque ambos los vicie a fondo hace unos años también. Y precisamente ese es el detalle que yo no estoy opinando desde recuerdos del pelo largo o gustos personales, simple y llanamente opino de lo que ofrecen técnicamente esos juegos y que no va reñido con que te guste más uno que otro, Crash es más plataformas puro y M64 exploración ahí entran los gustos, ahora lo que técnicamente está procesando M64 es mucho más complejo que lo que se procesa en Crash 1.

GValiente escribió:Yo jugué a los dos (Mario y Crash) en su día cuando salieron, y aunque el Mario 64 es mil veces mejor juego, el Crash me parecía (y me sigue pareciendo) que tenía mejores gráficos.

El Spyro es el peor juego y el más feo de los tres

Crash es un pasillo donde poner toda la carga gráfica, Spyro es un mundo abierto al igual que Mario por eso tiene peor calidad, pero lo que ofrece es técnicamente más amplio y complejo que Crash.

a simple vista los crush engañan un poco, parecen muy potentes técnicamente, pero es un plataformas sobre rieles digamos, así como los panzer dragon(el zwei se ve muy lindo). lo que si ayuda mucho a ps1 es la calidad de las texturas y una mayor claridad en la imagen respecto a n64, aunque un banjo kazooi es un ejemplo de lo que no se puede en ps1 y saturn, el entorno que puede generar esta consola, venir volando de una montaña y ver casi todo el mapa desde arriba, desde abajo a lo lejos, los filtros y efectos grafico que se aplican.... seguramente el framerate no debe llegar a 30, ahora no lo recuerdo. para mi ps1 generando entornos 3d esta entre una saturn, la cual usa fondos y objetos con motor 2d y 3d y una n64 que puede mostrar otras mejores perspectivas.

Por mi experiencia la N64, puede montar escenarios" gigantes", gracias , a la corrección de perspectiva, que no tenía PSX ni SS, eso sí, con el límite de Fillrate, el cual tenías que elegir entre detalle en las texturas , detalle pero que se notará la repetición, o poco detalle y mucho horizonte, al menos al principio, a partir de OoT y la implementación de 3DEX2 para hacer los juegos, podías hacer como OoT, un terreno extenso con una textura repetitiva pero lo suficiente estirada para que no se note, y aprovechar las herramientas que te daba este Ucode en descartar geometría, para utilizar el 2 ciclo de texturizado para meter una textura de detalle, y así nació técnicamente el juego que era imposible replicar en sus coetáneas.
Salud.

@dirtymagic el 3DEX2 es un microcódigo? no entiendo mucho de los aspectos técnicos, pero me gusta saber un poco, se que nintendo 64 se podía programar en microcódigo, la consola se ve que era un dolor de cabeza, por eso había tanta diferencia técnica entre sus juegos, la limitación de las texturas que tenían que ser muy chicas y expandirlas, usando los filtros de suavizado, la corrección de perspectiva, anti alias...dejaban un poco mas prolijo el resultado final.
Ps1 en su terreno, cuando le quedaba cómodo un motor grafico, se veía mejor

cristus escribió:@dirtymagic el 3DEX2 es un microcódigo? no entiendo mucho de los aspectos técnicos, pero me gusta saber un poco, se que nintendo 64 se podía programar en microcódigo, la consola se ve que era un dolor de cabeza, por eso había tanta diferencia técnica entre sus juegos, la limitación de las texturas que tenían que ser muy chicas y expandirlas, usando los filtros de suavizado, la corrección de perspectiva, anti alias...dejaban un poco mas prolijo el resultado final.
Ps1 en su terreno, cuando le quedaba cómodo un motor grafico, se veía mejor

En lo único que PS1 se veía mejor era en juegos que usaban gráficos pre-renderizados y FMV: Resident Evil, Fear Effect, FF, etc. N64 era la Xbox clásica de su generación, podía tener malos port o no cumplir con las expectativas puestas en ella, pero estaba media gen adelantada a sus competidoras.

@SuperPadLand hay varios juegos 3d que salieron peor en N64, pero seguramente era porque no la usaban al nivel que si rare y Nintendo, además estas usaban cartuchos mas grande que la media cuando hacia falta. y esto me hace decir que en gran parte el responsable es el cd en playstation que le daba ventaja para meter los pesados datos pre render a mayor calidad que mencionas. sigo viendo ventaja de poder y tecnología en n64 sobre ps1 y saturn obviamente, a pesar de que no funciona como debería por su arquitectura que tiene cuellos de botella, ya que me entere que esta la versión cara y completa de los chips con la tecnología de n64

Una arquitectura es tan potente como le permite su punto más flaco.
Saturn tiene dos procesadores y dos VDP, pero el bus no permite trabajar en paralelo a las dos CPUs. En N64, como ya comenté, la memoria unificada se encuentra muy congestionada a pesar de su alta velocidad.

PS1 en cambio tiene una arquitectura muy optima: tiene CPU, GPU y chip de sonido, cada uno con su memoria dedicada y conectados con su bus. Estan muy bien balanceados en rendimiento, lo que puede hacer de máximo la CPU se acercará al máximo de la GPU.

Al final lo que ocurre es que si desarrollas en un sistema optimizado, puedes dedicar más tiempo a mejorar tu código. En cambio, si es en un sistema con un punto flaco, has de dedicar tiempo a resolver ese punto flaco y ya no puedes mejorar tu propio código como deberias sin encarecer el desarrollo.
Así, si alguien desarrollaba para Saturn se tenía que pelear con varios procesadores a nivel de ensamblador. Si era para N64 debía optimizar y sincronizar adecuadamente el acceso a la RAM (consejo que viene hasta en el SDK oficial). Pero en PS1, al poder rendir una parte al máximo sin perjudicar a las otras, se podía optimizar el código en otras cosas.

Obviamente va aparte las limitaciones de manejo de polígonos, corrección de perspectiva, etc. intrísecas a cada sistema.

@cristus Supongo que la versión cara y completa de la N64 a la que te refieres son las estaciones Indy de Silicon Graphics.

cristus escribió:@SuperPadLand hay varios juegos 3d que salieron peor en N64, pero seguramente era porque no la usaban al nivel que si rare y Nintendo, además estas usaban cartuchos mas grande que la media cuando hacia falta. y esto me hace decir que en gran parte el responsable es el cd en playstation que le daba ventaja para meter los pesados datos pre render a mayor calidad que mencionas. sigo viendo ventaja de poder y tecnología en n64 sobre ps1 y saturn obviamente, a pesar de que no funciona como debería por su arquitectura que tiene cuellos de botella, ya que me entere que esta la versión cara y completa de los chips con la tecnología de n64

Pero eso no significa que los juegos tuvieran mejores versiones en PS1 porque excepto RE2, ese tipo de juegos que renderizaban los gráficos en megacomputadoras para luego ripearlos y meterlos en un CD en N64 brillan por su ausencia y no es por falta de capacidad de procesamiento es simplemente que meter esos datos en cartuchos salía caro y no se hacia, pero si pasamos del coste del producto final o metemos un addon como 64DD o un hipotético 64CD todos esos juegos pre-render y FMV también se verían peor en PS1.

La CPU-RCP-GPU de N64 es una animalada, con sus cuellos de botella y sus problemas sí, pero es que incluso con problemas sus peores juegos hacen cosas tecnológicamente que PS1 no podría hacer o que haría peor/arrastrándose al generarlas por software. Mismamente Superman 64 en PS1 se podría hacer un juego mejor y más divertido sin dudarlo, pero no podría usar niebla por hardware así que popping a lo bestia y todo ese entorno 3D abierto y sólido en PS1 se vería tembloroso, dientes de sierra del copón y mucho dithering. Y no hablo de memoria, estamos jugando la quinta gen en este mismo subforo, acabo de guardar la PS1 tras jugar Silent Bomber por RGB y por RCA (e incluso por RCA ves píxeles como puños) y este juego es bastante top gráficamente para PS1, pero se le ve una marcha por debajo a N64, pasa lo mismo con SS, por mucho que se patalee, sus mejores hitos 3D consisten en saber tapar o minimizar sus carencias y problemas polígonales y no poner un sólo polígono de más que no sea necesario. Los polycount de SS son similares en sus primeros juegos que en los siguientes que "mejoraban". Pero la gente ve un plano infinito 2D simulando un oceano de agua y ya flipa colorines y cree que eso es 3D, cuando la sola maya de agua de Wave Race 64 debe tener más polígonos y complejidad que media biblioteca 3D de Saturn y un cuarto de la de PS1.

Y vamos, que no pasa nada, te puedes divertir aunque no sean tops gráficos, yo juego SS, PS1 y N64 y lo paso bien o mal según el juego. Ahora estoy con el Zelda de Switch y gráficamente es una puta mierda para los estándares actuales, al menos para jugarlo en sobremesa como hago yo; pero el juego es probablemente el mejor de lo que llevamos de año y no me extrañaría que no sea superado hasta dentro de varios años. Porque con BttW ya salieron clones intentando sacar tajada de la formula y gráficamente eran mejores, pero no lograban igualarlo en calidad/diversión jugable.

@EMaDeLoC había leído una vez, que en su momento había disponible una familia de procesadores(nec vr...) y el que usaron para n64 es muy potente pero era de menor costo que otros disponibles.
Ps1 además de ser mas fácil de programar, Sony se las dejaba mas fácil también a las desarrolladoras.

@SuperPadLand igual el caché de texturas y la compresión que tiene ps1 le permite mostrar texturas mas grandes y una mejor paleta de colores, a pesar de que tiemblan los polígonos...además percibo mayor numero de polígonos en objetos o personajes en particular, como juegos de pelea donde le es cómodo a ps1 mover. en n64 los modelos me parecen mas cuadrados así este mostrando un escenario abierto o un plano mas cerrado como un juego de lucha

cristus escribió:@EMaDeLoC había leído una vez, que en su momento había disponible una familia de procesadores(nec vr...) y el que usaron para n64 es muy potente pero era de menor costo que otros disponibles.
Ps1 además de ser mas fácil de programar, Sony se las dejaba mas fácil también a las desarrolladoras.

@SuperPadLand igual el caché de texturas y la compresión que tiene ps1 le permite mostrar texturas mas grandes y una mejor paleta de colores, a pesar de que tiemblan los polígonos...además percibo mayor numero de polígonos en objetos o personajes en particular, como juegos de pelea donde le es cómodo a ps1 mover. en n64 los modelos me parecen mas cuadrados así este mostrando un escenario abierto o un plano mas cerrado como un juego de lucha

Eso tampoco es así lo siento. Léete este hilo, sale ese mismo bulo cada mes casi. Creo que Conker, Radorn, Emadeloc, Dirty y otros que trabajan con N64 deben estar ya hasta los cojones del monotema y de explicarlo.

@cristus Creo que te refieres a los procesadores R4000 de la compañía MIPS. Tienen varias variantes y la R4300 tiene el bus recortado de 64 a 32 bits. Fabricantes como NEC compraron la licencia y crearon la variante VR4300i.
Hay otra variante con el doble de caché, pero luego todas las variantes han tenido versiones a distintas velocidades de reloj, el de la N64 a 93MHz y algo.

No es que en PS1 fuese más fácil de programar, para ella y N64 había SDK en C y había las mismas facilidades y dificultades, pero en la N64 había que salvar el escollo de la congestión del bus que en PS1 no.

Lo de la cache de texturas esta más que explicado por el hilo. En este mensaje tienes mi última explicación, pero en resumen, la N64 tiene el doble de cache de texturas que PS1, y sin embargo siempre se le achaca a la primera que eso era un problema.

En algún momento tuve un homebrew con el que cacharreaba portado a la n64. El homebrew también funcionaba en PS1, el de ps1 funcionaba a 512x240 y de N64 a 320x240, los dos usando texturas de 32x32. Los dos funcionaban a 30 fps con alguna caída. El de ps1 estaba limitado por la CPU y el de N64 por la GPU. Cambiando a texturas más pequeñas, creo que fue a 16x16 (no recuerdo bien el tamaño pero eran más pequeñas), no detecté más caídas en n64 (en ps1 siendo el problema la cpu esto no cambió nada).

En algunas partes se podía dar mucho overdraw, esto supongo que podía haberse aliviado en n64 si hubiese, por ejemplo, pasado los polígonos a una lista enlazada como en ps1, pero en vez de atrás para adelante, de adelante para atrás para sacar más partido del zbuffer.
No quiero que esto se tome como una comparación de la potencia entre las dos, porque el motor estaba claramente concebido para la arquitectura de la ps1, fue un port rápido y cutre y lo dejé casi de inmediato porque no quería seguir usando el SDK oficial de Nintendo.

Hay muchas más variables en juego, pero en aquel momento lo primero que me preguntaba fue, ¿Qué pasaba cuando perdía la cache de texturas en n64? Al ser memoria unificada, ¿podía haber competencia con la CPU o cualquier otra parte al bajar a por la textura? ¿Cuál podría ser el peor de los casos para traer de vuelta una textura de 32x32? Busque algo por entonces pero no me quedó muy claro.

En ps1 lo tenía algo más claro, vuelta a la VRAM, exclusiva para la GPU, una latencia de entre 60/70ns y un ancho de banda de unos 133mb/s (no recuerdo si estos datos eran para la primera o la segunda revisión de la GPU)

Seguro que hay gente por aquí que me saca de dudas 😊

@Misscelan buenas missce, un placer volver a verte por aquí.

@EMaDeLoC gracias por el link al mensaje, recuerdo haber visto esa misma explicación en el hilo de quién es más potente saturn o ps1, el cual participe en varios mensajes.
Soy poco entendido en temas técnicos, pero siempre trato de entender y me resultan interesantes ese tipo de temas.
Ahora somos varios que nos cuesta entender pq en mucho de los casos Playstation muestra una imagen más definida y con texturas más grandes, que de lejos se ven bien y de cerca se pixelan... En Nintendo 64 eh visto texturas de buena calidad en juegos hechos por Nintendo y mejor en juegos de rare, siempre recuerdo banjo kazooi las escenas en tiempo real con el motor del juego la calidad de los personajes

cristus escribió:Ahora somos varios que nos cuesta entender pq en mucho de los casos Playstation muestra una imagen más definida y con texturas más grandes, que de lejos se ven bien y de cerca se pixelan... En Nintendo 64 eh visto texturas de buena calidad en juegos hechos por Nintendo y mejor en juegos de rare, siempre recuerdo banjo kazooi las escenas en tiempo real con el motor del juego la calidad de los personajes

Bueno, a mi parecer hay un factor que influye bastante y es que el ojo humano prefiere ver cosas nítidas que borrosas. Por tanto, en una pantalla plana que ofrece el mayor contraste entre píxeles, va a ser más agradable a la vista un juego de PS1 que el de N64 ya que la primera ofrece una imagen más nítida mientras la segunda, entre el filtro bilineal de las texturas, el antialiasing en los bordes de los polígonos y desenfoque horizontal de la salida de vídeo, es más borrosa. No es algo que me saque de la manga, tengo N64 con mods HDMI y les activo el deblur para al menos eliminar el desenfoque horizontal y que se vean bien.
Esto en cuanto a pantallas planas, porque en un CRT la cosa se invierte, ya que el CRT no trabaja realmente con píxeles sino con líneas y actuan ciertas propiedades físicas de la luz como la interferencia de ondas, y entonces los filtros citados de N64 sientan bien. De hecho yo he tenido lado a lado el Wave Race en una pantalla plana con HDMI y un buen CRT y la sensación de ser más real en CRT es muy difícil obtenerla por HDMI. Y no es cosa mía, hay comparativas de CRT vs. pixel perfect y el CRT gana de calle. Puede verse en la primera captura que es del MArio Kart 64, demostrando que hay que tener una visión global del contexto tecnológico y de la época de una consola para valorarla justamente.

Dicho esto, no discrepo de que en algunos juegos de PS1 haya texturas de mejor resolución que en otros juegos de N64. A fin de cuentas la de Sony tenía un medio de almacenamiento casi infinito en comparación a la de Nintendo. Pero tampoco estoy seguro de ese punto ya que, como las texturas no pueden ser mayores de 4kb, en 512kb de cartucho entran 128 texturas, que deberian ser suficientes para dos niveles distintos y varios personajes. Y eso sin contar con compresión. Automobili Lamborghini es un cartucho de apenas 4MB y de contenido en circuitos y coches no esta mal. Por tanto, no me cuadra tanto que las texturas supusiesen un problema de espacio como lo es el sonido: en 4kb en compresión ADPCM caben 2 segundos a 8KHz y 8 bits de muestreo, lo cual es una calidad de audio penosa, y eso con suerte y si no me fallan las cuentas. Es decir, que en el espacio de una textura de una pared usada de forma constante, siendo más beneficiosa de espacio, cabe a duras penas un efecto de sonido que se usará de forma periódica.

Bueno, igual he divagado demasiado.

Me gustaría tratar un día de sacar las texturas de un juego de PS1 que se considere de calidad y compararlas con otro de N64, para ver si realmente hay tanta diferencia en el tamaño de estas. Ahora mismo las comparaciones que hay son con Resident Evil 2, pero es que ese juego esta aprovechandose de una particularidad de la GPU de PS1 para cargar texturas más grandes sacrificando mucho el rendimiento.

Será por juegos para comparar, rayman 2, shadoman, armorines, gaulent, Ridge racer, wipeout,…

@cristus ten en cuenta que a ti visualmente puede gustarte más como se ve algo y no por ello significa que la máquina que lo está moviendo tenga mayores capacidades de procesamiento. El ejemplo de Saturn es la viva imagen de esto, el primer Virtua Fighter de lanzamiento tenía serios problemas técnicos y jugables, pero sino recuerdo mal era todo poligonal 3D (ahí el problema), para Virtua Fighter Remix y Virtua Fighter 2 dejaron de pedirle milagros a lourdes y claudicaron con que el 3D poligonal en Saturn cuanto menos mejor y tienes que los suelos donde las arenas de combate ya no son 3D sino un plano 2D infinito mejor que el modo 7 de SNES, pero en esencia lo mismo. Da el pego y funciona muy bien en juegos de lucha o shooters en railes como Panzer Dragoon, de hecho incluso permiten un aspecto visual mucho más atractivo en según que casos, el agua infinita de los oceanos de Panzer Dragoon por ejemplo, era imposible recrear un océano a esa calidad y con tanta distancia de dibujado para una consola de quinta gen. Pero tiene serias limitaciones, no pueden tener físicas ni interactuar el jugador con ellas, como sí pasa con el agua de Wave Race, en Saturn podrías poner ese agua y una lancha a correr encima y meterle unos sprites 2D de agua siendo salpicada para disimular, pero no simular ondas con sus físicas modulando el agua y generando olas que empujan al jugador, etc. Como sí hace Wave Race 64 y que tienes aquí analizado: hilo_hilo-de-detalles-y-curiosidades-de-n64_2171497#p1741499172

A mi me mola como SS se aprovechó de sus capacidades 2D para simular 3D y ahorrarse todos los polígonos posibles para así poder darle el máximo detalle posible a lo que tenía que ser 3D por cojones (luchadores en juegos de lucha 3D, el dragon y las cuatro ruinas en Panzer Dragon (donde hasta los proyectiles son 2D), etc. Pero N64 ya jugaba en otra liga que era el "yo hago todo en 3D excepto cuatro cosas 2D secundarias y a mayores con más calidad polígonal, de texturas, iluminación, corrección de perspectiva, efectos procesados, etc" que se ha mantenido hasta la fecha, ahora hay mejores postprocesados, iluminación, trazado de rayos, etc. Pero todo ello lo hacía ya N64 con lo que había en su época.

Y ya para terminar, todo lo que dices que te gusta más a ti visualmente de PS1, en N64 no está por decisión de los devs y de Nintendo que no licenciaba juegos a "calidad PS1" exigía que todo estuviera activado para mostrar los mejores gráficos por frame posibles. Pero N64 puede hacer juegos sin antialising, sin correción de perspectiva, etc. Vamos igual que cualquier juego de PS1 que elijas, y lo hará con más polígonos y rendimiento que PS1. Excepto lo ya dicho: FMV, pre-renderizados, voces y música CD (y esto no es porque no pueda la máquina es porque necesitarías otro formato físico o un cartuchos de 128-256megas que así a ojo en 1999 su PVP será de 28000-56000 pesetas. Aun así, reduciendo calidad y gracias a la capacidad de poder comprimir-descomprimir datos rápidamente por tener una CPU de casi 100mhz permitió almacenar todo RE2 en un sólo cartucho de 64 megas (14000pelas) y en según que cosas luce mejor (modelos 3D y sus texturas, creo que hai fondos pre-render a más resolución) o peor (voces y FMV).

Lo que no puede ser es al revés, pone a PS1 un hipotetico cartucho para tener velocidad de lectura rápida, pues ni con esas te va a poder hacer un Mario 64 suavizado, texturas no torcidas, etc.

SuperPadLand escribió:A mi me mola como SS se aprovechó de sus capacidades 2D para simular 3D y ahorrarse todos los polígonos posibles para así poder darle el máximo detalle posible a lo que tenía que ser 3D por cojones (luchadores en juegos de lucha 3D, el dragon y las cuatro ruinas en Panzer Dragon (donde hasta los proyectiles son 2D), etc.

Me da miedo comentar en este hilo, pero lo intento...

¿Qué capacidades 2D y no 3D tiene la Saturn?
Hasta donde yo sé, tanto el VDP1 como el VDP2 trabaja con elementos 3D (el VDP1 quads 3D y el VDP2 planos 3D).

SuperPadLand escribió:para Virtua Fighter Remix y Virtua Fighter 2 dejaron de pedirle milagros a lourdes y claudicaron con que el 3D poligonal en Saturn cuanto menos mejor y tienes que los suelos donde las arenas de combate ya no son 3D sino un plano 2D infinito mejor que el modo 7 de SNES,

A diferencia del fondo de modo 7 de la SNES (que utilizada una matriz de transformación 2D), que yo sepa los planos del VDP2 de la Saturn utilizan una matriz de transformación 3D.

EDIT

Echando un ojo, parece que:

• El VDP1 maneja tanto sprites 2D como quads 3D: https://segaretro.org/VDP1_(Saturn)
• El VDP2 maneja tanto planos 2D como planos 3D (con three-axis 3D rotation, a diferencia del plano del modo 7 de la SNES): https://segaretro.org/VDP2_(Saturn)

GValiente escribió:

SuperPadLand escribió:A mi me mola como SS se aprovechó de sus capacidades 2D para simular 3D y ahorrarse todos los polígonos posibles para así poder darle el máximo detalle posible a lo que tenía que ser 3D por cojones (luchadores en juegos de lucha 3D, el dragon y las cuatro ruinas en Panzer Dragon (donde hasta los proyectiles son 2D), etc.

Me da miedo comentar en este hilo, pero lo intento...

¿Qué capacidades 2D y no 3D tiene la Saturn?
Hasta donde yo sé, tanto el VDP1 como el VDP2 trabaja con elementos 3D (el VDP1 quads 3D y el VDP2 planos 3D).

SuperPadLand escribió:para Virtua Fighter Remix y Virtua Fighter 2 dejaron de pedirle milagros a lourdes y claudicaron con que el 3D poligonal en Saturn cuanto menos mejor y tienes que los suelos donde las arenas de combate ya no son 3D sino un plano 2D infinito mejor que el modo 7 de SNES,

A diferencia del fondo de modo 7 de la SNES (que utilizada una matriz de transformación 2D), que yo sepa los planos del VDP2 de la Saturn utilizan una matriz de transformación 3D.

EDIT

Echando un ojo, parece que:

• El VDP1 maneja tanto sprites 2D como quads 3D: https://segaretro.org/VDP1_(Saturn)
• El VDP2 maneja tanto planos 2D como planos 3D (con three-axis 3D rotation, a diferencia del plano del modo 7 de la SNES): https://segaretro.org/VDP2_(Saturn)

La culpa es mía por invocarla aquí, pero evidentemente no podemos hacer offtopic de SS en este hilo. De todas formas está bastante bien explicado en este foro en múltiples hilos, incluso juraría que tu estuviste en alguno de ellos.

GValiente escribió:Me da miedo comentar en este hilo, pero lo intento...

No has de tener miedo, pero si una actitud más abierta y constructiva.

En cuanto a tus dudas sobre Saturn, si quieres puedes leer este mensaje y este otro del hilo de Saturn vs. Dreamcast. En especial un vídeo enlazado en la que un desarrollador de Saturn explica la diferencia entre sprite (2D) y polígono (3D).

Luego si hay alguna duda puedes plantearla en el hilo oficial de Saturn y así no hacemos offtopic en este.

SuperPadLand escribió:Y ya para terminar, todo lo que dices que te gusta más a ti visualmente de PS1, en N64 no está por decisión de los devs y de Nintendo que no licenciaba juegos a "calidad PS1" exigía que todo estuviera activado para mostrar los mejores gráficos por frame posibles.

A todo esto, y esto igual es un poco offtopic, ¿tú crees que en Sony también exigian un mínimo de calidad, al menos en los gráficos? Lo digo porque casi todos los juegos subdividian polígonos para paliar un poco la falta de corrección de perspectiva y pensandolo, me parece un poco raro que diferentes desarrolladoras se pusieran de acuerdo en una técnica concreta. Podría estar en la actualización bestia del SDK de PS1 que se hizo en 1997. Y luego también el tema del framerate, procurando que fuese lo más alto posible.
Que además Sony no se durmió en los laureles y aunque ya había vendido muchos millones de PS1 para cuando salió la N64, saco el Dual Shock, promovió los juegos en varios discos, etc. Así que no me extrañaría que pusieran empeño en mejorar la calidad gráfica de los juegos lo máximo posible.

EMaDeLoC escribió:

GValiente escribió:Me da miedo comentar en este hilo, pero lo intento...

No has de tener miedo, pero si una actitud más abierta y constructiva.

En cuanto a tus dudas sobre Saturn, si quieres puedes leer este mensaje y este otro del hilo de Saturn vs. Dreamcast. En especial un vídeo enlazado en la que un desarrollador de Saturn explica la diferencia entre sprite (2D) y polígono (3D).

Luego si hay alguna duda puedes plantearla en el hilo oficial de Saturn y así no hacemos offtopic en este.

SuperPadLand escribió:Y ya para terminar, todo lo que dices que te gusta más a ti visualmente de PS1, en N64 no está por decisión de los devs y de Nintendo que no licenciaba juegos a "calidad PS1" exigía que todo estuviera activado para mostrar los mejores gráficos por frame posibles.

A todo esto, y esto igual es un poco offtopic, ¿tú crees que en Sony también exigian un mínimo de calidad, al menos en los gráficos? Lo digo porque casi todos los juegos subdividian polígonos para paliar un poco la falta de corrección de perspectiva y pensandolo, me parece un poco raro que diferentes desarrolladoras se pusieran de acuerdo en una técnica concreta. Podría estar en la actualización bestia del SDK de PS1 que se hizo en 1997. Y luego también el tema del framerate, procurando que fuese lo más alto posible.
Que además Sony no se durmió en los laureles y aunque ya había vendido muchos millones de PS1 para cuando salió la N64, saco el Dual Shock, promovió los juegos en varios discos, etc. Así que no me extrañaría que pusieran empeño en mejorar la calidad gráfica de los juegos lo máximo posible.

Creo que Sony en esa etapa licenciaba lo que le dieran, pero precisamente por eso la competencia dentro de la propia PS1 era enorme y eso impulsaría a los propios devs a sacar los juegos a la mejor calidad que la del resto. Eso sumado a lo que has dicho de que Sony daba buena documentación, SDK que según leí hacían todo el juego en C y solo los más pros o que querían ir un paso más allá hacían alguna cosa concreta en ensamblador. Entonces diría que hacer un juego de PS1 a calidad 8/10 debía suponer un trabajo normal para cualquier estudio de calidad media y no supondría matarse para ello.

También, supongo, que no es lo mismo programar en PS1 con todo lo suyo activado que hacerlo en N64 que era mucho más complejo.

Pero bueno, en PS1 hay software a diferentes calidades y donde se ve que o Sony pasaba o era mucho más flexible que Nintendo (no en vano Sony nunca tivo un sello de calidad dorado jaja). Por ejemplo Busby 3D, Tobal, etc. Dejan claro que Sony sacaba juegos sin texturizar o mal texturizados. Sacaron cosas como Revolt que va terriblemente mal de rendimiento aparte de verse fatal (luego sacaron una secuela exclusiva muy buena a calidad PS1 y va fluida)

@SuperPadLand no es que tenga preferencia por los gráficos de ps1, de hecho en su momento tenia preferencia por Nintendo y hoy soy mas imparcial y reconozco que como dicen ustedes se la curraban mucho para sacar juegos con esa factura técnica, siendo un hard inferior al de n64, y siendo inferior a saturn en lo que es 2d, igualmente sigo viendo en algunas ocasiones gráficos a mas resolución en ps1 y como decís la ventaja del cd en algunos juegos permitió meter mas gráficos y sonidos como en el caso de Re2, y eso se vio (ya me voy por las ramas) en las 16 bits donde pc engine teniendo varias limitaciones pudo tener mejores versiones de algunos juegos por estar en cd que megadrive y super nes.
coincido en gustos con saturn, cuando aprovecha el vdp2 para rellenar parte de los gráficos salen cosas muy bellas como panzer dragon zwei, virtua fighter 2, radiant silvergun que cuando dicen que en ps1 no se puede hacer tal cual es verdad ya que se esta aprovechando todos los chips y capacidades de la consola, cosa que en ps1 hasta cierto grado le renta hacer gráficos 2d para relleno del entorno ya que no le sobran chips, sino que gasta recursos de la gpu.
otra cosa que destaca ps1 es la calidad de sonido y los fmv, los mejores de la época.

Todas las compañías por aquella época ya tenían Quality Control y antes de eso el concepto debería ser aprobado (lo del concepto se ha mantenido hasta la época de Wii y media vida de PS4. Ahora el concepto se aprueba automáticamente y solo se hace el QA).
Los casos de prueba eso sí han pasado de unos pocos a cientos en la actualidad.
Aquí podéis ver un extracto de como te presentaban lo que podía pasar y no en Sony para Ps1.



La percepción de resolución, como dice EMaDeLoC, es muy subjectiva. La resolución de una textura también se puede diluir dependiendo de como de grande sea el polígono o puede verse magnificada si el juego funciona a más resolución.
Tres juegos insignias de la época usaban texturas de 64x64, Banjo-Kazooie, Spyro y Powerslave(saturn) (aunque funcionan a resoluciones diferentes)
No tengo constancia de que juegos usaran texturas mucho más grandes en ps1 (quizás los halla). Ni si quiera Resident Evil, de hecho este usa texturas muy pequeñitas (se puede ver en el recuadro rojo), normalmente de 16x16. No sé si es porque se las devolvía así el MDEC, o porque haciendo Tiles se pueden ahorrar overdraw en el los fondos si hay elementos en primer plano (como la estatua en esa habitación)



Con el tema de meter más gráficos, las texturas de esa época si usabas CLUTs se quedaban en muy poca cosa, creo que también entraba el factor de que renderizar es mismo material continuamente es más rápido que ir cambiando cada vez (salvo para Saturn que no tiene cache de texturas y todo va igual de rápido (o lento) como se quiera ver), así que una parte del ahorro en texturas podría venir por ahí.

En PlayStation la velocidad de renderizar algo fuera de la cache se reduce a la mitad, pero era el pan nuestro de cada día, porque pocos materiales se pueden agrupar con Listas enlazadas.
En n64 puedes agrupar todos los materiales si quieres ya que puedes mandarlos desordenados gracias al zbuffer. ¿Aunque no sé si en cierto punto puede ser contraproducente depender en demasía del zbuffer?
También me gustaría saber, cuanto de lento se puede volver si tienes que renderizar algo fuera de la cache en n64, porque he leído latencias 10 veces más grandes y congestión del bus, pero esos datos me parece un poco exagerados, o casos muy extremos?

Y por último sin entrar mucho en el offtopic. La manera en la que el vp1 renderiza los “polígonos” es prácticamente clavada a la de ps1. Tienes unos vértices en 3d, los multiplicas por la inversa de la matriz de la camera, divides la X y la Y entra la Z y con ese tienes el vértice proyectado en pantalla, esos vértices 2D se los pasas a la GPU en forma de paquetes y en el caso de ps1 los renderiza usando Affine Mapping y en Saturn Forward mapping (la Saturn sin UVs eso sí).

Ni la GPU de PSX ni la de Saturn reciben nada de información 3D, por eso ninguna tiene corrección de perspectiva.

A mí me parecen cuestiones de nomenclaturas, en la documentación de Saturn, si a los paquetes no les pones texturas los llama Polígonos. Y la 3DO que hace exactamente lo mismo que la Saturn los llama CELs.
De hecho ese famoso video del Tomb Raider de Saturn que cambian todo a “Sprites” se pueda hacer igual en ps1, de la misma manera, cambiando el tipo de paquete.

Todo el Setup de los planos infinitos de Saturn se hacen en 3d también, tienen muchas limitaciones, pero yo los metería también dentro del saco de 3d.

Pero bueno, que al final es un poco tontería discutir sobre esto y se convierte algo casi filosófico.

Misscelan escribió:Todo el Setup de los planos infinitos de Saturn se hacen en 3d también, tienen muchas limitaciones, pero yo los metería también dentro del saco de 3d.

Pero bueno, que al final es un poco tontería discutir sobre esto y se convierte algo casi filosófico.

No es tan filosófico cuando el que los planos sean 3D o no permite mayor libertad a la hora de mostrar el plano.

Por ejemplo, el ángulo en el que se muestra el plano fondo del vídeo no es posible en una SNES, ya que la escala cambia en el eje vertical de la pantalla, no en el horizontal:



Además, a diferencia de la SNES, que yo sepa con la Saturn no hace falta aplicar raster effects para mostrar un plano 3D, con lo que también se reduce el uso de CPU. ¿Es así?

Misscelan escribió:La manera en la que el vp1 renderiza los “polígonos” es prácticamente clavada a la de ps1. Tienes unos vértices en 3d, los multiplicas por la inversa de la matriz de la camera, divides la X y la Y entra la Z y con ese tienes el vértice proyectado en pantalla, esos vértices 2D se los pasas a la GPU en forma de paquetes y en el caso de ps1 los renderiza usando Affine Mapping y en Saturn Forward mapping (la Saturn sin UVs eso sí).

En este caso, la PSX es "más 2D" que la Saturn, ya que se puede mostrar un triángulo 3D con affine mapping escalando y rotanto un sprite 2D, mientras que con forward mapping no se puede.

Misscelan escribió:En n64 puedes agrupar todos los materiales si quieres ya que puedes mandarlos desordenados gracias al zbuffer. ¿Aunque no sé si en cierto punto puede ser contraproducente depender en demasía del zbuffer?

Efectivamente si aprovechas el z-buffer, puedes cargar una textura y pintar todos los polígonos que la usen, y después pasar a otra textura y repetir. Al agrupar los polígonos con texturas identicas, te ahorras el ancho de banda de cargar la textura varias veces. Lo que pasa es que la operación con z-buffer requiere comparar la profundidad con otros polígonos y acaba consumiendo más ancho de banda de lo que te ahorras con la primera opción. Pero también usar el z-buffer te ahorra el trabajo de ordenar todos los polígonos según la distancia con lo que crear el display list se hace más sencillo que en PS1 o Saturn.

Misscelan escribió:También me gustaría saber, cuanto de lento se puede volver si tienes que renderizar algo fuera de la cache en n64, porque he leído latencias 10 veces más grandes y congestión del bus, pero esos datos me parece un poco exagerados, o casos muy extremos?

No se puede, el RDP del RCP no renderiza nada que no se haya metido en la TMEM (la caché de texturas), no lee texturas directamente de memoria, al menos que yo sepa.

Sobre las latencias de memoria, escribí un post con unos cálculos basandome en los datos de un datasheet de RDRAM. En el mensaje podrás ver la hoja de cáculo. Por resumir, salía esta gráfica:


Cuando los datos son pequeños la velocidad de transferencia cae muchísimo. Es algo normal que pasa con todas las memorias, las tasas altas teóricas solo se alcanzan con paquetes de datos grandes, pero con pequeños la velocidad baja muchísimo.
Si tenemos eso en cuenta, cuando el RCP comprueba el z-buffer de un pixel que acaba de pintar, tenemos que lee el byte del z-buffer (o los dos bytes), lo compara, pinta el framebuffer y actualiza el z-buffer si corresponde. Eso son 3 paquetes minúsculos que suponen un desperdicio notable de ancho de banda. Y luego hay que añadir todas las operaciones de carga de polígonos, de texturas, de samples de sonido, de leer el frambuffer para la salida de vídeo, etc. Cada vez que lo pienso, todavía me parece milagroso que la máquina rinda tan bien.

Pero de alguna manera durante décadas se ha dicho que el problema era la latencia entre la CPU y la RAM, cuando por el pipeline gráfico es casi lo que menos importa. Es como si en un PC de ahora se dijese que la CPU tiene una latencia muy alta con la RAM de la tarjeta gráfica. Pues claro que si, pero es que lo importante es que la GPU acceda a esa memoria, no la CPU.

@Misscelan
Yo no toco mucho código ya que sobretodo modelo en 3D y para un motor como el de Zelda, que tiene sino la última, casi última versión del uCode que se hizo comercialmente.
El overdraw en el primer uCode, mataba muchísimo el rendimiento, de ahí que se abusara de escenarios grandes con pocos polígonos y texturas estiradas o tileadas, con pocas estructuras que se tapasen y en interiores mucha separación en estancias sin tampoco mucha carga, ya que esta primera versión ni siquiera tenía back culling, no fue hasta la primera extensión de está que se añadió, y posteriormente, ZSort y Scissor, aprovechando el Z-Buffer, pasando hacer escenarios de 2000 polígonos (Mario 64) a 15000 ( Zelda64), también es verdad que Nintendo parecía más interesada en mostrar avances gráficos sobre la competencia a coste de rendimiento, de ahí que Zelda,PD, BT funcionen a ~20Fps, a cambio de mostrar efectos imposibles en PSX.
Yo lo que he leído de ese tema, es que hay que alinear bien la memoria, para que los accesos entre los diferentes componentes no se estorben, pero vamos seguro, que le cuesta más poner mucha texturas diferentes, que pocas tileadas o no te digo ya estiradas.
Sobre el tamaño de las texturas, pues yo diría que básicamente, a color, maneja las mismas que PSX,ya que por particularidades de esta, pese a ser de 4KB, si usas Mip Mapping, texturas con paleta o mezcla de 2 texturas, estás no pueden ser más de 2KB, en blanco y negro, llega a 128x64 en i4, llenando los 4KB de caché, imposible para PSX.

Salud.

Misscelan escribió:En PlayStation la velocidad de renderizar algo fuera de la cache se reduce a la mitad, pero era el pan nuestro de cada día, porque pocos materiales se pueden agrupar con Listas enlazadas.
En n64 puedes agrupar todos los materiales si quieres ya que puedes mandarlos desordenados gracias al zbuffer. ¿Aunque no sé si en cierto punto puede ser contraproducente depender en demasía del zbuffer?
También me gustaría saber, cuanto de lento se puede volver si tienes que renderizar algo fuera de la cache en n64, porque he leído latencias 10 veces más grandes y congestión del bus, pero esos datos me parece un poco exagerados, o casos muy extremos?

Recargar textura en cada uso?

Esto no tiene relación pero es curioso: La libdragon más antigua tenía una función que venía de serie y aseguraba que el "sprite" se actualizaba en cada uso, en realidad lo que hacía era volcar en la RAM la porción de cache relacionada de datos que tenía la CPU en ese momento antes de subir al RDP, ya que eso se maneja manualmente en N64, además de añadir condición por superficie, pero claro, después de darle vueltas vi que eso solo se usaba en escenarios puntuales, como actualizar una paleta, y era como una penalización del 20-30%, vamos que fue lo primero que borre de la lib

Tengo tests que dibujan sin recargar para saber la cifra exacta, y también llegué a probarlos recargando la textura en cada uso, para hacerme una idea sobre un escenario "real", ya que en un juego 2D es más común que pocas cosas se repitan y la penalización no la recuerdo crítica, escribir de RAM a cache de texturas debería perjudicar menos que de CPU a RAM.

Aunque podría volver a editar esos tests si es realmente necesario e interesa saber los datos exactos.

--
De las texturas que tal si volvemos a poner varios ejemplos para refrescar la memoria? El hilo son muchas páginas y quizás hay usuarios nuevos.

La cara entera de Claire en el port del RE2 equivale a un ojo del Conker, es un trabajo excepcional en muchas cosas, pero no un ejemplo de uso de texturas en la consola.


No todo está limitado a la cache de texturas, se puede componer en múltiples pasos, ejemplo de DK64 (128x128).



Nota: Ese fondo tiene mucho detalle, las palmeras no tanto, lo cual nos lleva al siguiente punto.

La mala fama del texturizado de N64 es por estirar las texturas hasta el infinito, hay ejemplos y ejemplos, pero básicamente es sacarle partido a la corrección de perspectiva y al suavizado de texturas, mientras de paso se ahorra algo (o mucho) fillrate, que es el principal problema de la consola.


Este es un ejemplo clásico, el suelo en Zelda OOT tiene doble paso, se puede ver una textura más detallada del césped y otra por encima para colorear no tan detallada, en otras circunstancias ese árbol no podría verse así, es decir, si no puedes aplicar suavizado de texturas tendrías que buscarte la vida para darle más detalle al árbol (lo que le tocaría hacer a PSX y Saturn)

Tenemos tipos intermedios:


Y luego los niveles extra del Goldeneye que hacen cosas experimentales con las texturas, la imagen? No tiene ningún tipo de filtro y aún así no se notan los bloques de la textura, al poner tanto detalle en superficies pequeñas.


Yo lo que veo es mucha flexibilidad para conseguir distintos resultados, en tiempos de desarrollo limitados, lo cual nos lleva a las mejoras de Mario 64, donde no hace más que añadir rendimiento según se descubren nuevas formas para optimizar. (sin tocar el aspecto gráfico o lo que es más importante: el ucode, de ahí se podría rascar bastante)

Muchas gracias a todos por la información muy interesante!

EMaDeLoC escribió:Sobre las latencias de memoria, escribí un post con unos cálculos basandome en los datos de un datasheet de RDRAM. En el mensaje podrás ver la hoja de cáculo. Por resumir, salía esta gráfica:

La gráfica muestra que traer una cache line (16 bytes?) de la CPU puede ser una experiencia traumática . Casi que a poco que tengas Ks de información te compensa mandarlos al RSP y tratarlos ahí.
Aunque tampoco creo que muchos juegos de N64 estén limitados por la CPU.
Para el tema texturas, no parece que afecte mucho, ya que una textura aunque sea pequeñita son cientos de bytes. Pero también sería interesante ver la latencia y si algún controlador tiene prioridad? Si bajas a la RAM a por una textura y la CPU estaba ya hurgando para otra cosa, toca esperar?

La TMEM es exclusiva para texturas? Lo digo por si estás comparando la profundidad de un pixel en el zbuffer, esto va a la DCACHE de la CPU? Supongo que el zbuffer pillará más de lo que necesite para aprovechar ancho de banda, pero a su vez si el polígono es pequeño también se malgasta.

dirtymagic escribió:ya que esta primera versión ni siquiera tenía back culling.

Madre mía, pues estaban capando los juegos al 50%

dirtymagic escribió:Yo lo que he leído de ese tema, es que hay que alinear bien la memoria, para que los accesos entre los diferentes componentes no se estorben

En la Saturn la recomendación es parecida, podías poner diferentes líneas para la cache asociativa. Y después ordenar todo en función de eso, pero claro eso es un curro del demonio. Además que te limita más la cache de datos y viendo el ancho de banda con datos pequeños tiene que ser para usos muy específicos.

dirtymagic escribió:Sobre el tamaño de las texturas, pues yo diría que básicamente, a color, maneja las mismas que PSX,ya que por particularidades de esta, pese a ser de 4KB, si usas Mip Mapping, texturas con paleta o mezcla de 2 texturas, estás no pueden ser más de 2KB, en blanco y negro, llega a 128x64 en i4, llenando los 4KB de caché, imposible para PSX.

En playstation las texturas no están limitadas por la cache, puedes poner una de 256x256 si quieres. Aquí puedes ver una de Spyro de 256x108 sin CLUT, pero claro, la practicidad brilla por su ausencia.

Conker64 escribió:Esto no tiene relación pero es curioso: La libdragon más antigua tenía una función que venía de serie y aseguraba que el "sprite" se actualizaba en cada uso, en realidad lo que hacía era volcar en la RAM la porción de cache relacionada de datos que tenía la CPU en ese momento antes de subir al RDP, ya que eso se maneja manualmente en N64, además de añadir condición por superficie, pero claro, después de darle vueltas vi que eso solo se usaba en escenarios puntuales, como actualizar una paleta, y era como una penalización del 20-30%, vamos que fue lo primero que borre de la lib

Tengo tests que dibujan sin recargar para saber la cifra exacta, y también llegué a probarlos recargando la textura en cada uso, para hacerme una idea sobre un escenario "real", ya que en un juego 2D es más común que pocas cosas se repitan y la penalización no la recuerdo crítica, escribir de RAM a cache de texturas debería perjudicar menos que de CPU a RAM.

Eso es muy interesante, la información de latencia y cuellos de botella que había leído por ahí no tiene nada ver. En ese caso la cache de texturas parece que no compensa mucho y lo suyo sería montarse una Lista enlazada y pasársela al RCP de adelante a atrás?
Pierde gran parte de la cache de texturas pero te quitas un montón de overdraw.

GValiente escribió:No es tan filosófico cuando el que los planos sean 3D o no permite mayor libertad a la hora de mostrar el plano.

Si en eso estoy de acuerdo contigo. Yo lo considero 3d, con lo de filosofía no hablaba de este caso en particular. Hablaba en general de qué se considera un Sprite, un polígono, o simplemente 3d (lo que parece VS como se consigue).

Misscelan escribió:La gráfica muestra que traer una cache line (16 bytes?) de la CPU puede ser una experiencia traumática . Casi que a poco que tengas Ks de información te compensa mandarlos al RSP y tratarlos ahí.
Aunque tampoco creo que muchos juegos de N64 estén limitados por la CPU.
Para el tema texturas, no parece que afecte mucho, ya que una textura aunque sea pequeñita son cientos de bytes. Pero también sería interesante ver la latencia y si algún controlador tiene prioridad? Si bajas a la RAM a por una textura y la CPU estaba ya hurgando para otra cosa, toca esperar?

Para cargar una textura no es ningún problema ya que se cargan de una vez en el RCP y casi siempre serán paquetes grandes. El problema es manejar datos pequeños en diferentes líneas de framebuffer. Por ejemplo, sale más costoso un triángulo en vertical que uno en horizontal. No tengo muy claro si la comparación de z-buffer se hace por trozos de línea horizontal o pixel a pixel, supongo que lo primero porque lo segundo sería bastante perjudicial al rendimiento, pero igualmente son muchos datos pequeños por frame, lo que debe suponer un buen coste en el ancho de banda.

Si no recuerdo mal, en el SDK se avisa de que la CPU tiene prioridad en el acceso a memoria y que por tanto cuando se empiece la rasterización se procure no hacer solicitudes a memoria. La latencia extra que puede tener la CPU no creo que sea muy alta, creo que en un vídeo de optimización del Mario dijeron 7 nanosegundos, pero igual se referian a otra cosa.

Lo de que baje la velocidad de transferencia con datos pequeños pasa con todas las memorias. Por eso en muchas arquitecturas se usan memorias dedicadas como PS1. Pero la RDRAM tiene tan buen rendimiento que permite su uso.

Misscelan escribió:La TMEM es exclusiva para texturas? Lo digo por si estás comparando la profundidad de un pixel en el zbuffer, esto va a la DCACHE de la CPU? Supongo que el zbuffer pillará más de lo que necesite para aprovechar ancho de banda, pero a su vez si el polígono es pequeño también se malgasta.

La TMEM es para texturas, paleta de las mismas o mipmaps.
Ya digo que no sé exactamente como se gestiona el z-buffer. Se que tiene su región en memoria, por lo que eso de el 9bit de la RDRAM no tiene sentido como he llegado a leer en alguna parte. Si tengo claro que la TMEM no se puede usar para eso.

World Driver Championship no usa z-buffer, hicieron un buen trabajo optimizando escenario y display list, y la cantidad de polígonos alcanza cifras impresionantes. Se dice que no le dijeron nada a Nintendo en el filtro de calidad y se la colaron, ya que era o con z-buffer o nada.

@Misscelan
He buscado algún test real que había puesto por aquí y quizás tenía un poco de mala memoria.. no es una penalización crítica, pero si bastante más notable de lo que recuerdo, sobre un 38-39% en esta prueba.

Esta escena la construyo con un algoritmo qsort (que no es el más rápido), para determinar en cada posición del scroll el orden en que los tiles se van a pintar para ahorrar tener que recargar la textura.


El resultado en un mismo punto (texturas 4bit de 16x16) :
- 104fps (sin estrategia, recarga siempre)
- 169fps (qsort)

Recargar textura de 4-8bit penaliza algo más que de 16bit, son más comandos y la paleta también hay que subirla a TMEM, salvo que se use la misma para el resto de texturas.

De todas formas en ese test pasan muchas otras cosas, es de hecho de los primeros que hice, en otros test de scroll consigo 300fps en realidad (que tampoco es una buena medida los fps, luego el rendimiento no es linear y a menor tasa esta consola puede con más, pero bueno, me sirve), cuando tenga un rato lo miro con uno más puro y actualizado.

En 3D no hay tanta cantidad de texturas activa por frame, quizás castigue menos que en 2D, sería interesante lo que dices y ver que es lo que más compensa o si hay soluciones intermedias, porque el overdraw es muy común en base a lo visto en el catálogo y si esas superficies van con Z-Buffer la penalización puede ser alta.

Edit: El test es CPU -> RAM -> RDP (creo que de formar el display list con el RSP esos porcentajes variarían o de incluso hacer correr el motor de scroll en el RSP, sería bastante menor el consumo, paralelizado, son 280 recargas de textura por frame, que también inflan la lista que la CPU escribe en la RAM en este caso concreto)

Conker64 escribió:He buscado algún test real que había puesto por aquí y quizás tenía un poco de mala memoria.. no es una penalización crítica, pero si bastante más notable de lo que recuerdo, sobre un 38-39% en esta prueba.

Bueno, es un poco peor pero tampoco parece ser que la cache de texturas sea tan crítica como se ha comentado siempre.
Supongo que si la aplicación tiene un uso mucho más elevado de la CPU, con lo que comenta EMaDeLoC, esta podía bloquear el acceso a la RAM del RDP y penalizar un poco más, pero mucho tendría que ser para que se considerase crítico.

Entiendo también que usando los ucodes de Nintendo, cuando se generaba la información en el RSP para mandar al RDP, esta no podía ser, una vez que terminase, interceptada, reorganizada, y mandada desde la CPU al RDP? Porque viendo los problemas de fillrate de muchos juegos, reorganizar la lista para aliviar el overdraw antes de que llegue al RDP habría mejorado la ejecución a la vez que se mantenía toda la retahíla de efectos gráficos. Y nos es que las Listas cruzadas fueran tecnología muy novedosa o costosa para la CPU porque sus competidoras las llevaban usando ya un par de años en CPUs más livianas. O, también puede ser alguna de esas decisiones oscuras e ilógicas de Nintendo...

@Misscelan pero los planos infinitos de Saturn más allá de que lo consideremos 3D o no, que yo lo considero, a efectos de procesarlo usa polígonos texturizados o no? ¿Uno gigante o varios? Lo digo porque lo que yo trataba de decir es que Saturn empezó intentando hacer como PS1 entornos poligonales 3D mayoritariamente y el fiasco fue grande, en la siguiente hornada (1995 en adelante) ya empiezan a aparecer juegos que visualmente están bien y funcionan fluidos, pero ya no intentan crear escenarios 3D enteros sino que usa planos infinitos. Que es lo que yo quiero decir cuando Saturn aprovecha sus virtudes para paliar sus carencias a la hora de poner polígonos texturizados con goraud más efectos varios como PS1 en toda la escena. Y que yo sepa esa capacidad de crear planos infinitos originalmente se metió para hacer juegos 2D, por eso decía virtudes 2D. Como el paralax de antaño que lograba una sensación 3D en la escena, igual lo puedes usar para algo en un juego 3D poligonal, pero su "idea original" era para juegos 2D.

Por cierto lo de la calidad de PS1 muy gracioso, pero aun así eran bastante laxos y entraba todo lo que generacionalmente estuviera un milimetro por encima de la anterior gen, porque lo de juegos a más de 256 colores es casi más difícil que una PS1 te ponga menos de 256 colores lo de los clones de Doom es un acierto porque aun así se les colaron alguno (pero con polígonos) y meh, hubiera molado si recibieran clones buenos, pero en esa época era complicado filtrar esto. Y claro, su filtro de "calidad" se superaba con que algo usase fondos pre-render de mierda y un par de FMV y los modelos 3D más cutres de la historia, la jugabilidad ni la mirarían y así llegaron a nosotros cosas como The Crow: City of Angels tecnológicamente muy por encima de lo que exigía Sony, jugablemente horrible

Nintendo imagino que haría lo mismo, pero creo que eran más duros exigiendo porque no hay tanta porquería en su catálogo.

SuperPadLand escribió: pero creo que eran más duros exigiendo porque no hay tanta porquería en su catálogo.

O_o A mi parecer, y esto es personal, es la consola de nintendo con mayor cantidad de porquería. Pero da igual. Permitieron el Superman 64, y eso... eso.... es dificil de superar.... quizás con el juego del Neng... aunque ya para Play2

SuperPadLand escribió:los planos infinitos de Saturn más allá de que lo consideremos 3D o no, que yo lo considero, a efectos de procesarlo usa polígonos texturizados o no? ¿Uno gigante o varios?

https://segaretro.org/VDP2_(Saturn)

The VDP2's tiled infinite plane engine uses tilemap compression and a form of scanline/tiled rendering. It draws large 2D background planes and/or large 3D textured infinite planes (for things such as grounds, seas, walls, ceilings, skies, etc.) with perspective correction and a virtually unlimited draw distance, at a very high fillrate for its time.

SuperPadLand escribió:que yo sepa esa capacidad de crear planos infinitos originalmente se metió para hacer juegos 2D, por eso decía virtudes 2D. Como el paralax de antaño que lograba una sensación 3D en la escena, igual lo puedes usar para algo en un juego 3D poligonal, pero su "idea original" era para juegos 2D.

¿Para qué iban a meter planos con transformaciones 3D para juegos 2D?

Es mucho más barato meter planos con transformaciones 2D y si el programador quiere un plano 3D horizontal, que lo haga con raster effects (como la SNES con el modo 7).

SuperPadLand escribió:@Misscelan pero los planos infinitos de Saturn más allá de que lo consideremos 3D o no, que yo lo considero, a efectos de procesarlo usa polígonos texturizados o no? ¿Uno gigante o varios? Lo digo porque lo que yo trataba de decir es que Saturn empezó intentando hacer como PS1 entornos poligonales 3D mayoritariamente y el fiasco fue grande, en la siguiente hornada (1995 en adelante) ya empiezan a aparecer juegos que visualmente están bien y funcionan fluidos, pero ya no intentan crear escenarios 3D enteros sino que usa planos infinitos. Que es lo que yo quiero decir cuando Saturn aprovecha sus virtudes para paliar sus carencias a la hora de poner polígonos texturizados con goraud más efectos varios como PS1 en toda la escena. Y que yo sepa esa capacidad de crear planos infinitos originalmente se metió para hacer juegos 2D, por eso decía virtudes 2D. Como el paralax de antaño que lograba una sensación 3D en la escena, igual lo puedes usar para algo en un juego 3D poligonal, pero su "idea original" era para juegos 2D.

EL vdp2 es un frankestein y realmente no se puede definir en pocas líneas. Es complejo incluso para los estándares de la Saturn, yo el uso que le he dado ha sido testimonial.
Tiene varios planos, que los puedes combinar para hacer diferentes acciones. No todos los planos tienen las mismas propiedades, por ejemplo no puedes tener 7 planos oblicuos.
Depende de que plano, puedes ponerle diferentes texturas, no una encima de la otra, sino repartidas en una malla. Los planos 3d pueden ser infinitos o no, los puedes cambiar de tamaño. Aceptan transparencias y tienen corrección de perspectiva. También se pueden aplicar algunos efectos por líneas a los planos.
El vdp2 es el chip gráfico que está conectado a la salida de video. Toda imagen generada en el vdp1 se pega en uno de los planos del vp2, con el que podrías jugar también como otro plano al uso.
De la historia de como se concibió la Saturn no sé mucho, supongo que como dices tú y mucha gente, empezó con algo poco orientado a las 3d y se fue adaptando.

SuperPadLand escribió:Por cierto lo de la calidad de PS1 muy gracioso, pero aun así eran bastante laxos y entraba todo lo que generacionalmente estuviera un milimetro por encima de la anterior gen, porque lo de juegos a más de 256 colores es casi más difícil que una PS1 te ponga menos de 256 colores lo de los clones de Doom es un acierto porque aun así se les colaron alguno (pero con polígonos) y meh, hubiera molado si recibieran clones buenos, pero en esa época era complicado filtrar esto. Y claro, su filtro de "calidad" se superaba con que algo usase fondos pre-render de mierda y un par de FMV y los modelos 3D más cutres de la historia, la jugabilidad ni la mirarían y así llegaron a nosotros cosas como The Crow: City of Angels tecnológicamente muy por encima de lo que exigía Sony, jugablemente horrible

Nintendo imagino que haría lo mismo, pero creo que eran más duros exigiendo porque no hay tanta porquería en su catálogo.

Sí, bueno, eso al final es un brindis al sol, un poco lo que le gustaría. Pero no una línea roja.
Al final si el concepto que les propones les puede hacer dinero, pues adelante. Al final solo le hacen la QA técnica y punto.
Yo creo que más que Nintendo poniéndose dura, era que no se le acercaban tanto. Si tu al final tienes una empresa y tienes planeado sacar cinco volúmenes de un juego que podría venir en una caja de cereales, te la juegas con ps1 que vas a tener unos costes de producción más bajos (CD) y una base de usuarios más grande para intentar tener un retorno de la inversión. Era la plataforma que estaba de moda.

Misscelan escribió:De la historia de como se concibió la Saturn no sé mucho, supongo que como dices tú y mucha gente, empezó con algo poco orientado a las 3d y se fue adaptando.

Es curioso que la gente diga que la Saturn y sobre todo el VDP2 al principio iban a ser para juegos 2D, cuando según otros el último chip que se añadió a la Saturn (según la leyenda como respuesta a la PSX) fue el VDP2:

@Misscelan
Algo así hacía el ucode de Boss Studios para el zsort, multiples pasos entre el RSP y la CPU. (pero no usaba el Z-Buffer)

Ahí recomendaría leer las respuestas de ERP que posteaba en beyond3D, fue programador del Top Gear Rally y World Driver Championship.

Conker64 escribió:Ahí recomendaría leer las respuestas de ERP que posteaba en beyond3D, fue programador del Top Gear Rally y World Driver Championship.

Genial hilo, gracias por el aporte.

GValiente escribió:

Misscelan escribió:De la historia de como se concibió la Saturn no sé mucho, supongo que como dices tú y mucha gente, empezó con algo poco orientado a las 3d y se fue adaptando.

Es curioso que la gente diga que la Saturn y sobre todo el VDP2 al principio iban a ser para juegos 2D, cuando según otros el último chip que se añadió a la Saturn (según la leyenda como respuesta a la PSX) fue el VDP2:

No sé si el orden de los chips, pero hay entrevista del creador de Saturn donde deja claro que era una máquina 2D principalmente y que al ver la PS1 tuvieron que apañarla, también explica porque era una consola pensada para el 2D que no es sólo "porque creíamos que estaba muy verde la tecnología". En el hilo de SS tiene que estar la entrevista.

Naitguolf escribió:

SuperPadLand escribió: pero creo que eran más duros exigiendo porque no hay tanta porquería en su catálogo.

O_o A mi parecer, y esto es personal, es la consola de nintendo con mayor cantidad de porquería. Pero da igual. Permitieron el Superman 64, y eso... eso.... es dificil de superar.... quizás con el juego del Neng... aunque ya para Play2

Creeme, Superman 64 pudo ser un GOTY si el resto de sus contemporáneos fuesen algunos de los bodrios de PS1. Pero más allá de eso, estás pillando 1 juego malo para concluír 'mayor cantidad' no me salen las cuentas.

La PS1 como todas las máquinas que arrollaron en ventas atesora (por decirlo finamente) una ingente cantidad de morralla, superando a NES. Supongo que Spectrum le superará porque sacaba juegos todo dios sin ningún filtro 🤣. Pero vamos pasa siempre cuando una máquina arrolla y sobre todo se alarga en el tiempo, aparte de las citadas: PS2, NDS, Wii, etc. Otra cosa es que estos sistemas también atesoran una gran cantidad de buenos juegos que por puro % será mayor al de la competencia.

Date cuenta que juegos de PS1 de 5 sobre 10 para arriba puede haber 800-900, lo cual ya es la misma cantidad que todo el fullset de N64.

Tuvo que ser muy bestia la n64 que silicon graphics le enseñó a sega para que estos la descartaran por costes.

Conker64 escribió:@Misscelan
Recargar textura de 4-8bit penaliza algo más que de 16bit, son más comandos y la paleta también hay que subirla a TMEM, salvo que se use la misma para el resto de texturas.

No sabía, que son más rápidas las texturas de 16bit que las que tienen paleta.
Entonces en rendimiento que sería así:
32x32 y 64x32 a color:
16bit> 4 bit compartiendo paleta con otras texturas>8 y 4 bit con paleta.

64x64 a color:
4 bit compartiendo paleta> 4 bit con paleta.

Supongo que las texturas en escala de grises serán las más rápidas.

Salud.

@dirtymagic
A ese tamaño de textura debería funcionar mejor a 16bits, sobretodo si estás continuamente cambiando la paleta, a tamaño completo ocupando toda la cache depende, las de 4bit deberían ser más rápidas, en 2D, desde luego si vas a usar tiles gigantes vas a poder rellenar más pantalla, en menos pasos y recargas, consiguiendo mayor rendimiento. (probado)

Las de escala o intensidad son las más rápidas como dices y las que mayor tamaño pueden alcanzar, si mal no recuerdo.

En un juego 3D tendrías unas 40-60 texturas activas, lejos de las 280 recargas de ese test.

Luego si quieres hacer un ranking, las texturas a lo ancho dan más rendimiento que a lo alto, cuanto más mejor, lo cual también incluye superficies o framebuffer a lo ancho.

Conker64 escribió:@dirtymagic
A ese tamaño de textura debería funcionar mejor a 16bits, sobretodo si estás continuamente cambiando la paleta, a tamaño completo ocupando toda la cache depende, las de 4bit deberían ser más rápidas, en 2D, desde luego si vas a usar tiles gigantes vas a poder rellenar más pantalla, en menos pasos y recargas, consiguiendo mayor rendimiento. (probado)

Las de escala o intensidad son las más rápidas como dices y las que mayor tamaño pueden alcanzar, si mal no recuerdo.

En un juego 3D tendrías unas 40-60 texturas activas, lejos de las 280 recargas de ese test.

Luego si quieres hacer un ranking, las texturas a lo ancho dan más rendimiento que a lo alto, cuanto más mejor, lo cual también incluye superficies o framebuffer a lo ancho.

Si alguien quisiera hacer un motor 2D más o menos genérico para la N64, ¿qué consejos generales le darías para mejorar el rendimiento?

@GValiente
Pues..
> Configurar el chip gráfico en modo COPY, tanto para sprites como tiles, cuanto más se use mejor, son 4 pixel por ciclo
> Usar el modo 1CYCLE solo: (1 pixel por ciclo)
- Para alpha blending
- Si hay que estirar un sprite a lo ancho, a lo alto no es necesario
- Para aplicar suavizado, aunque solo funciona cuando la superficie es superior al tamaño de la textura (zoom)
- Tinte RGB y otros efectos del COLOR COMBINER
> Usar modo FILL COLOR si hay grandes zonas con color solido, también se usa para limpiar la pantalla, pero si se va a dibujar entera no es necesario

El modo es por superficie, se puede cambiar en cualquier momento, aunque si ordenamos un listado para no cambiar continuamente mejor.

Con COPY hay funcionalidad casi completa, sirve hasta para rotaciones, aunque requiere 2 triángulos, en lugar del rectángulo.

1CYCLE en todas las superficies sería necesario en escenas de este tipo, es un tinte RGB aplicado a toda la escena:


Que COPY dibuje 4 pixel por ciclo no quiere decir que 1CYCLE sea 4 veces más lento, por poner un ejemplo de una imagen estática:


Res 640x480
Modo 16bit, tex 16x16 16bits copy = 333fps
Modo 16bit, tex 16x16 16bits 1cycle = 266fps
Modo 32bit, tex 16x16 16bits 1cycle = 211fps

El modo 32bit no lo usaría en juegos, aunque para menús y pantallas de presentación tiene rendimiento de sobras, o juegos sencillos de no más de 2 planos y 320x240, a modo 16bits sería lo ideal.

--
Las mejores texturas para 2D son las de 4bit en general, imagino que los personajes o enemigos usaran paletas, a igualdad de tamaño las texturas de 16bit probablemente sean más rápidas, pero más cuando son pequeñas o se abusa de la recarga de cache, a cierto tamaño la mejor es la que más pantalla pinte, las de 8bit son las que menos uso les he dado.

Las texturas a lo ancho rinden más, puedes comparar 32x64 con 64x32 o 16x32 con 32x16, el tamaño máximo tanto de ancho como de alto es de 256, es un test oficial de Nintendo.


Contrastado con las pruebas que hice después que coinciden.


Si el fondo es una imagen que no se repite, se pueden usar texturas de 256x8, más si es una capa de poca movilidad, o para layers que no son a pantalla completa.

--
Es recomendable una estrategia de recarga de texturas, pero yo solo lo aplicaría si los fondos van a usar muchos tiles repetidos, como en el ejemplo del Goldenaxe II, que sacas un 38-39% más de rendimiento, en los sprites no me molestaría.

La optimización más simple es la de comprobar si la nueva textura que llega es la misma que ya hay, si se dan las condiciones favorables puede existir algo de ganancia, a coste mínimo, 1 comprobación por recarga, yo esto siempre lo recomendaría.

--
También te puede servir un render optimizado para eliminar capas tapadas, en una recreación del Castlevania SOTN lo puse en práctica:


- Dibujando todo: 116fps
- Eliminando capas tapadas: 178fps

Nota los fps eran bajos en ese momento de desarrollo, luego las cifras subieron, un Castlevania SOTN completo correría a 60fps sin problemas, en una libdragon, incluso sin usar el RSP (salvo en el audio), en libultra debería ser todo mucho más rápido, ese es un problema añadido a la scene, la libdragon antigua era muy lenta, la nueva hace tiempo que no la pruebo.

--
El sonido en el RSP, la consola tiene potencia en 2D para prescindir totalmente, pero para el audio usaría el RSP, tanto sonido como música, penaliza mucho si corre en el mismo hilo que el programa (cosa que hacía antiguamente la libdragon)

--

Luego hay otras pequeñas cosas, pero vamos, aquí de unas a otras puede salir una gran diferencia de fps.

¡No esperaba tanta info, gracias!

¿Es posible renderizar dos sprites distintos con la misma textura para que sea horizontal?
Por ejemplo, si se quiere mostrar dos sprites de 32x32, utilizar una textura de 64x32 como spritesheet.

EDIT

¿Vale la pena repintar sólo las partes de la imagen que han cambiado, o mejor repintar todo en cada frame?

@GValiente
No prob

En la libdragon original viene una función de spritesheet, yo soy más de separar individualmente, daba algo de mejor rendimiento.

Pero sí, cuando subes una textura estableces todas las coordenadas y posiciones de memoria, tanto de origen como destino, eso si quieres comunicarte directamente con el chip, o a más alto nivel en el formato "sprite" que es el tipo de textura que usa libdragon.

Lo de repintar solo las partes que han cambiado lo usaba en un render por software en pc, cuando la cámara estaba quieta lo aplicaba, si el scroll se movía, había temblor y similar lo dejaba en modo rastro, era una buena combinación para cada momento, pero depende del tipo de juego.

En N64 no me lo llegué a plantear la verdad.