Hilo de detalles y curiosidades de N64

Me parece todo super curioso. Te doy gracias por dedicar tu tiempo en escribir estos posts. Sigue así!!

Excelente aporte BMBx64.

Nintendo 64 y Playstation utilizan dos métodos completamente diferentes a la hora de representar las cosas y es absurdo compararlas en base a números (cantidad de polígonos y tamaño de las texturas).
Un escenario completo de Super Mario 64 tiene alrededor de 1000 polígonos. Mario eran unos 700 visto de cerca pero el modelo con cámara normal serán bastantes menos (¿500?). Los enemigos y resto de elementos como monedas no supondrían muchos polígonos tampoco, a parte de que no se renderizan hasta que no aparecen en pantalla o nos acercamos lo suficiente a ellos (popping). Podríamos decir que todo junto serían 3000 polígonos (aunque en ningún momento está todo visible en pantalla). A 30 fps da 90000 polígonos por segundo, de sobra para lo que puede mover una PSX. Podríamos ir a 60fps y aún así estaríamos dentro de lo que teóricamente mueve la consola de SONY (unos 300000 triángulos por segundo según algunas fuentes, contra los 90000~100000 de N64).
Y sin embargo Super Mario 64 es un juego inviable en Playstation si queremos que se vea igual (excepto por el filtro bilinear, ni antialiasing, ni corrección de perspectiva, ni precisión subpixel). Para mantener la distancia de dibujo y que las texturas tengan un tembleque "normal" para lo que es PSX, habría que subir la carga poligonal en los escenarios una burrada (como puede verse en la imagen del F1 WGP) y la consola ya no sería capaz de moverlo.

Otra curiosidad de Super Mario 64 es que me parece que no usa el filtro trilinear salvo para casos muy contados (el truco del retrato de Peach/Bowser). Recuerdo una entrevista a una persona que vio una demo del juego durante su desarrollo y mencionaba que ese filtro aún no estaba aplicado al juego, y parece que no lo usaron al final.
Otra curiosidad es que es un juego que utiliza sombreado en tiempo real sobre los escenarios (creo que es goraund) en el que la fuente de iluminación simpre está en el mismo punto de la cámara (a la derecha de la imagen). Se puede ver perfectamente en la secuencia de créditos cuando la cámara gira alrededor de la torre del segundo nivel (vídeo) pero lo más curioso es que parece que se puede aplicar esta ilumincación según la textura y dejar partes del escenario sin ella. En los mismos créditos se pueden ver escenarios como los acuáticos donde parece que no hay ningún tipo de iluminación, pero se puede comprobar también en los jardines exteriores del castillo donde se utiliza el sombreado de vértices para simular sombras estáticas en las paredes del castillo y sin embargo en la zona del estanque, la arena que lo rodea sí cambia su iluminación según el punto de vista de la cámara.

Ya que mencionas Perfect Dark y la falta de filtros en los edificios. Nintendo 64 tiene dos filtros para las texturas:
-Filtro bilinear. Actúa cuando el tamaño de la textura en pantalla es mayor al original. Interpola los colores entre los píxeles de la textura para que no se vean "cortes" repentinos en la textura. Combinado con la precisión subpixel de Nintendo 64 nos evita el temblequeo de texturas.

-Filtro trilinear (o mipmapping). Actúa cuando el tamaño de la textura en pantalla es menor al original. No es un efecto que se pueda activar si la textura no reúne ciertas condiciones. La consola parte los 4 KB de la caché por la mitad y en una almacena la textura y en la otra versiones más pequeñas de la misma. Según la lejanía (o inclinación) a la que se ve la textura, va interpolando entre los distintos tamaños de la textura para evitar la pixelización. Si la textura es tan grande que no permite liberar 2 KB de la caché (por ejemplo las texturas de 64x64 a 16 colores del The World is not Enough que ha mostrado BMBx64 en su anterior mensaje) no se puede aplicar este filtro.

Pero también es posible desactivar el filtro trilinear aunque la textura reúna las características necesarias y Perfect Dark lo hace en algunas texturas como algunos cuadros colgados de la pared del nivel de Villa.

Desactivando efectos Nintendo64 puede acercarse al rendimiento poligonal de PSX. En igualdad de condiciones las fuentes dicen que N64 movería el doble de polígonos, y con polígonos tan pequeños la caché de 4KB es más que suficiente (PSX tiene una caché de 2KB). Si se desactivan los efectos con cabeza se pueden conseguir cosas como el World Driver Championship.


Pero hace poco me topé con una característica de PSX que parece que no es replicable en N64. Se trata de algo llamado 'additive alpha blending' o una técnica similar que es la que permite que los juegos de luces tan espectaculares en las invocaciones de Final Fantasy IX (y muchos otros juegos de PSX) sean posibles.
Siempre pensé que aquello era posible porque de alguna manera aprovechaban la reproducción de FMV's durante el juego para conseguir esos efectos, pero aunque creo que hay partes en las que es así, realmente hay algo en las transparencias de las partículas y la superposición de los rayos que no he visto en ningún juego de Nintendo 64 (aunque hay algo parecido en Jet Force Gemini).
Nintendo 64 es capaz de hacer normal alpha blending. Esto es: cuando una capa semitransparente se suporpone a otra capa, calcula el color que resultaría de mezclar ambos de manera sustractiva (azul + amarillo = verde; y rojo+azul+amarillo = negro). Sin embargo PSX también es capaz de mezclar los colores de forma sustractiva, como lo hace la luz (verde + rojo = amarillo; y rojo+azul+amarillo = blanco).





Ya digo que me cuesta pensar en juegos de Nintendo 64 que usen esta técnica y que por eso este tipo de efectos siempre me han parecido bastante flojos, pero en Jet Force Gemini con el cañón de plasma o la pistola eléctrica se consigue algo parecido.
(No encuentro ningún video mostrando el funcionamiento de estas armas, pero se puede ver en el enfrentamiento contra el jefe final. Cuidado con los spoilers).

¿Se trata de la misma técnica o es sólo un truco para simularla? ¿Algún otro juego con efectos de luz de este tipo? ¿Podría entonces la Nintendo 64 mostrar algo como las invocaciones de los Final Fantasy?

@BMBx64 Muchas, gracias. La verdad es que vaya diferencia de carga poligonal. Aunque sea para evitar "el baile" de polígonos, la diferencia es abrumadora a favor de PSX. He echado un ojo al Rush 2049 y aunque las curvas están mucho más suavizadas, creo que no llegan al nivel "pley".
Respecto a las texturas muy curioso también. ¿Se nota mejoría de rendimiento al desactivar el suavizado?

@sgonzalez
Pues solo lo probé en emulador, pero depende del trabajo del RDP, es el que se encarga de pintar texturas, además de filtrarlas o de meter antialiasing, por lo menos ganarías más tiempo para poder pintar más, si lo desactivas a lo bruto quizás hay cálculos previo paso que se siguen procesando aunque no sean necesarios.

@Sogun
Muy buen texto también

Add / Subtract se puede implementar por software teniendo acceso al framebuffer, vamos lo he visto en engines 2D que corren por software y que se podrían portar a N64, ahora a saber el rendimiento, en polígonos 3D habría que investigar, no sé como lo hacen en PSX.

En cuanto polígonos yo no he visto que PSX mueva los 180K texturizados (los oficiales) en ningún juego de los que he analizado, si te fijas en todas las extracciones que he ido sacando las cifras son siempre parecidas, unos 4000 polígonos por frame si van a 30fps, 2000 polígonos por frame si van a 60.

Por ejemplo Tobal 1 son 120K (2000x60) y casi todo en flat shaded y goraud, con alguna textura por ahí.
Tobal 2 (1500x60), Tekken 3 (1500x60), Wipeout 3 (3000x30) unos 90K.
Los Crash Bandicoot entre 60 o 70K (2000/2500x30)
Tomb Raider picos de 60K si llega. (2000x30)

Si te vas a una esquina del escenario o a una pared, todas las consolas de esa generación estarán moviendo ¿5K? y para encontrar el pico de geometría igual tienes que liarla parda o jugar durante horas, por eso sacar cifras de esto es tan complicado y siempre se dan como "cifras aproximadas", quizás también sea importante cuanto se mueve de media en lugar de los picos o altibajos.

Luego tenemos el framerate, en el F1 WGP de PSX si fuera a 30fps eso serían 120K, el problema es que no lo sabemos sin analizarlo, si fueran 20 ya solo serían 80K, esto le pasa bastante a N64, hay muchos juegos por encima de 4000 polígonos por frame, pero a 15 o 20fps en ese momento exacto, World Driver Champioship es de los pocos que mantiene el tipo y por eso las cifras se le disparan por encima de 100K, por tanto es N64 capaz de manejar 100K? La respuesta sería si, pero no tan fácil.

En N64 luego tienes las extracciones que se sacan sin culling, imagina una esfera de 500 polígonos, en pantalla siempre vas a estar viendo la mitad de ella, por tanto no son 500, eso la cpu ya lo descarta incluso antes de mandarlo al RSP, lo procesa pero no lo renderiza (que es la cifra que nos interesa, la final), lo que verás son 250, exactamente la mitad.

Una esfera no es como un humano, donde todo el detalle por ejemplo se centra en la cara, si ves a un personaje de espaldas igual estás descartando un 65% del modelado, o un 35% si lo vieras de frente, a eso le llamo yo "deducciones".

En Conker Bad Fur Day en la taberna tienes unos 8000-9000 polígonos, cuando les aplicas la deducción igual se te quedan en 4000/5000 (principalmente porque todos los muñecos están de cara), eso lo multiplicas por 15 o 20 (gracias al debug exacto del juego) y nos da los 80K en ese preciso instante, pero no quiere decir que en otras secciones "más afines", menos texturas o iluminación no ponga 90K o en otro lugares caiga a cifras más bajas, sobretodo al girar la cámara.

En cuanto a escenarios pienso que hay de todo, pero en PSX por necesidad siempre va a tener que poner más polígonos como se demuestra en la mayoría de capturas (y de paso aprovechan y meten curvaturas o cosas menos puntiagudas, a fin de cuentas PSX tenía todo el apoyo de la industria y a la mayoría de genios trabajando para ella), pero vamos a verlo en modelados completos, esto es el primer nivel de Spyro (fíjate todo lo que se le va en el agua):


En Banjo Tooei, esta comparación no tiene mucho sentido porque son escenarios de distinto tamaño, este es más pequeño, pero bueno, menos polígonos en este caso pero mejor texturizado, también hay que tener el cuenta el número de vértices que calcula la CPU.


Sobre objetos 3D y modelados concretos la cosa es más dispar, por lo pronto he visto modelados más complejos en N64 que en PSX, por ejemplo el protagonista de Turok 2 son casi 3000, cada enemigo de Perfect Dark son 650 (igual que Solid Snake), etc, pero luego ambas utilizan LOD.

Igual tiene que ver que el microcódigo de culling para objetos 3D es bastante más rápido que el de clipping para escenarios o que simplemente lo que ahorran por un lado lo meten en otro.

También hay que tener en cuenta que las superficies por muy grande que sean hay que rellenarlas con una textura, gastando tiempo en cada paso, vamos que cada una en su sitio

El additive alpha blending no me parece muy diferente al normal. Por lo que yo entiendo es mezclar los colores haciendo lo contrario.
Si en uno se suman valores en el otro se restan, aunque me parece que lo que se hace es conservar los valores más altos de RGB en uno y los más bajos en el otro. Cogiendo como base la imagen de los círculos que he posteado antes:

En el additive alpha blending un píxel rojo (255,0,0) y otro verde (0,255,0) te da un píxel amarillo (255,255,0). Creo que conserva los valores más altos, porque si los sumara enseguida se alcanzaría el color blanco.

Sin embargo en el normal alpha blending un píxel cián (0,255,255) y otro amarillo (255,255,0) dan uno verde (0,255,0). Un píxel magenta (255,0,255,) y otro amarillo (255,255,0) dan uno rojo (255,0,0). Aquí se conserva el valor más bajo y ya.

Luego en los canales alfa de ambos métodos me parece que se sumarían los valores (0 sería totalmente transparente y 255 totalmente sólido). Mmm, se necesitaría algún tipo de Z-buffer para saber qué está delante y qué detrás de las distintas capas de transparencias si se da el caso.



El número de polígonos que puedan decir las especificaciones que es capaz de mover una consola en realidad no dice mucho. Hay muchas más cosas a parte de la carga poligonal que afectan al rendimiento: tipo de iluminación, IA, físicas, transparencias, la resolución... en Nintendo 64 incluso el sonido.
En PSX parece que se puede controlar más lo que se puede hacer porque tiene distintas memorias dedicadas y chips específicos. En Nintendo 64 al tener "todo unificado" puedes quitar cosas de un sitio para meter recursos en otro.
Y como hemos visto en N64 puedes desactivar efectos para ganar rendimiento, mientras en PSX no hay nada que desactivar.



EDITO: Me acabo de encontrar con un Easter Egg del Bomberman 64. Si antes del jefe del nivel 5-1 consigues evitar el diálogo con Sirius y luego lo fuerzas tras vencer al jefe, aparecerá un símbolo de interrogación en la cabeza de Bomberman que se estará preguntando "¿Pero de que c*** me habla este tío?".
Vïdeo

Muy interesante todo lo que comentáis aquí.

En temas de 3D estoy muy verde. Hace unos años hice una demo con Obj y Md2, modelos del Quake que iba cargando, enemigos, y un robot que andaba y les disparaba, y los enemigos tenían una animación de muerte (algunas colisiones 3D).

También se podían pasar filtros y ver distintos modos de visualización: wireframe, textured, solidificar, etc.

Quizás en el futuro me ponga con Unity y pueda aportar algo más en estos hilos.

@Sogun
Sí, las cifras oficiales de polígonos por desgracia se utilizan en muchos foros para devaluar a N64 sin molestarse ni en analizar que hay detrás, ponemos una imagen de 2 juegos distintos y si cuela cuela.

En PSX la CPU puede seguir trabajando y mandando algunas instrucciones a la GPU así de forma paralela, trabajando con bloques inferiores a 4KB para aprovechar la cache de la CPU, luego cada componente tiene su propio pozo de memoria evitando posibles cuellos de botella, la maquina dará todo lo que pueda, quizás explicaría porqué pasaron de 60K o menos de los primeros juegos a 90-120K en los últimos años de la consola, los polígonos de PSX son a precisión de enteros, bastante más rápido que calcular en coma flotante pero también impreciso.

En N64 es tal como dices, son cifras con todos los efectos activados (salvo el zbuffer en WDC), si empiezas a desactivar cosas, a currarte microcódigos y optimizar, el rendimiento solo va a ir en aumento, luego la memoria unificada tiene sus ventajas, la CPU puede escribir directamente en el framebuffer o acceder a toda la información, en PSX el framebuffer lo metes en la VRAM y ahí tienes que acceder a él mediante comandos a la GPU, sin embargo para acceder a la RAM la CPU de N64 tiene que pasar antes por el RCP en lugar de hacerlo directamente, ahí tienes un posible cuello de botella.

Por otro lado me quedan los juegos de Factor 5, pero pasa lo de siempre, no se pueden analizar sin un debugger que los haga funcionar.

@Promis ya contarás que tal

--
EXPLOSIONES 2D
(En otro foro me han preguntado sobre las explosiones de MGS y las de Goldeneye, que precisamente tienen que ver con el Additive que comenta Sogun), dejo el texto:

He ido a esta escena del MGS (PS3 con HDMI), ojo al efecto en el camuflaje del Ninja, luego cuando el gordo cae se activa el blur a pantalla completa (efecto de rastro) con distintos brillos para mejorar el efecto de las explosiones.

Las explosiones como tal parecen sprites mirando siempre hacia cámara, así que no habría problemas de perspectiva, porque no existen cambios de ángulo, solo están redimensionadas, el efecto no parece un alpha blending convencional, sino uno additive (intensificar colores, más tarde hay ejemplo).


En Goldeneye las explosiones empiezan sin transparencia o las lleva en las puntas de forma gradual, la verdad no me he parado a comprobarlo, terminan en semitransparencia y dan paso a una ristra de humo.


Luego explotan en cadena y de forma descontrolada, se aprovechan de las explosiones solidas para no pintar otras que queden completamente tapadas, pero cada elemento extra como cajas crean más explosiones extra, hasta las sillas explotan, existe un tope, pero es muy elevado.


El humo persiste durante bastante tiempo tras la explosión y se acumula, se calculan 2 imágenes, la de "fondo" se combina con el humo en un nivel de semitransparencia solicitado para sacar un color "intermedio", ese es el efecto, el polígono rota y hay cierta animación en el humo, esta rutina se funde el fillrate de cerca.


He creado un pequeño programa con un engine 2D, como las explosiones son también 2D no hay problema, aquí una explosión normal sin transparencia con gráficos random que he encontrado por ahí con un fondo de Goldeneye.


Aquí 50% de transparencia, es del tipo que usa Goldeneye al final de las animaciones o en el humo, aunque está al 50% podría ir de 100% a 0%, de hecho este gif quedaría mejor al 75% para ese sprite de explosión, o bien que el propio sprite esté dividido en 4 partes y el degradado vaya de solido en el centro a transparente en las puntas, podría ser algo similar al additive en su ausencia.


El additive, se combina el color del fondo con el sprite, pero además se rotan hacia colores claros como el blanco o el amarillo para intensificarlos, es lo que parece que hace MGS (gif patrocinado por Michael Bay)

Que pasada de hilo y que lástima que la N64 no fuese con cd's.
Ahí Nintendo erró de lleno.

@BMBx64 De nuevo fenomenal aporte!.
Es cierto que el additive alpha blending en PSX aportaba una vistosidad y nitidez que no tenían otras consolas de la época. Las partículas o efectos de N64 en la mayoría de las veces no destacaban bastante y muchas veces pecaban de borrosidad y/o poca definición. Por ejemplo el fuego normalmente quedaba muy, muy deslucido.

Respecto a Golden Eye, a mi me encantaba que después de la explosión el humo permaneciera bastante tiempo, le daba mucho realismo, es como si se creara una especie de atmósfera neblinosa.

Y respecto al nivel de poligonización, creo que a simple vista se ve que en N64 es inferior respecto a PSX y me atrevería a decir que posiblemente respecto a Saturn. Además acompañado casi siempre con nieblas y framerates dubitativos .

También hay excepciones y también es cierto lo que habéis comentado respecto a que los grandes desarrollos de la época estaban en la máquina de Sony.

DETALLES PERFECT DARK
Pues ya hemos visto cosas de la IA del Goldeneye pero no algunas mejoras introducidas en Perfect Dark.

Una de ellas es poder disparar al personaje a distinto nivel o a través de plantas, en Goldeneye es como si fueran paredes y no pueden vernos.. un momento, esa mosca debe ser del Jet Force Gemini porque sabe lo que va a pasar.


Así que el soldado va a rodear la pasarela para encontrarme y poder disparar, por el lado derecho hay cajas que estorban, el lado izquierdo está libre, qué camino tomará el enemigo?


Efectivamente el más corto, traza una ruta y la sigue, lo sorprendente es que oyes a los enemigos abriendo puertas por aquí y allá, recorriendo todo el camino hasta encontrarte, en las fases nevadas puedes subirte a la antena y verlos correr desesperados desde la otra punta del escenario.


En Perfect Dark quería enseñar como disparan desde cualquier lado y ha salido esto.. lo he dejado y he recordado como son los juegos hoy en día, donde los enemigos parecen maquinas de matar con 99% de efectividad en los disparos, aquí vemos al enemigo haciendo el lelo, tirándose por el suelo, fallando y disparando a una pared, esa naturalidad, esa forma curiosa de reaccionar creo que es lo que hace tan mítico a estos juegos, en Rare sabían que ibas a tardar en apuntar con el mando y te lo adornaban dándote tiempo a reaccionar.


Una de las cosas magníficas de Goldeneye eran los daños localizados, en Perfect Dark fueron más allá y añadieron daños permanentes, he dejado lisiado al enemigo, a ver si así se le quitan las ganas de dar patadas.


Ahora vamos al brazo, pues lo mismo, me gustaría verlo con daños en el brazo y la pierna, un detalle interesante son los berridos que sueltan al vernos, podemos escucharlos gritar dammit por ejemplo cuando se les atasca el arma.


En Goldeneye el arma es como si formara parte del cuerpo, reciben impactos pero no daños si disparamos al arma, en Perfect Dark con puntería puede saltar por los aires, los enemigos tienen varias rutinas en ese instante, o bien liarse a hostias, ir a recoger armas del suelo, rendirse..


Si deciden enfrentarse algunos aún guardan una pequeña pistola, algo así como disparar a los científicos del Goldeneye.


Este hombre ya debe estar harto de mí, por eso se ha rendido, nótese los pasos que hace hacia atrás, yo no me fiaría un pelo..


En Goldeneye ya hemos visto que casi todo explota o se puede romper, las sillas, las taquillas, los interruptores.. puedes liarte a romper luces en el Bunker y no dejar ni una encendida.



Natalya ya está harta de nosotros, solo hay que ver el facepalm al cargarnos el teclado (con explosión claro).


Hasta enemigos que dicen ser invencibles no lo son, explosión salvaje inesperada.


En Perfect Dark las balas como tal no hacen explotar algunas superficies, ver este tipo de físicas como mover mesas y recordar posiciones, dejar enemigos en el suelo de forma temporal (y hacer una sangría con su cara mientras salpica la sangre a todas partes) eran detalles más propios de un PC de la época.


Incluso las partículas en los disparos o la cantidad de balas registradas en la pared o diferentes desperfectos por el escenario eran recordados, se nota que el juego hizo buen uso de los 8MB de RAM.


--
A Saturn le pasa un poco como a N64, hay que programar bien en ella para sacarle partido, una por no dejar acceder a bajo nivel / sin documentación y la otra por usar una arquitectura tan complicada, hay que usar la segunda CPU, planos abatidos para no pintar con polígonos el suelo o el techo, etc. por ejemplo Tomb Raider en el 6:50:
https://www.youtube.com/watch?v=VutzIK3DqZE

NBA COURTSIDE 1 & 2 Feat. Kobe Bryant
Recuerdo cuando entrenaba a basket y leía la Nintendo Acción donde le dedicaron unos cuantos artículos a este juego, dado que no hay nada en el hilo sobre juegos de basket vamos a darle una repasada a estos.

El bueno es realmente el segundo, pero compararé algunos apartados.


Empezamos por la resolución interna, 472x212 el primero.


Una ligera mejora de resolución en el segundo (460x280), en hardware original luce mucho más nítido, así que pueden existir otros trucos al respecto, los juegos se mueven muy bien en ambos casos.


Quedan lejos en resolución de otros juegos de la consola como los de Acclaim, sin embargo este tipo de deportivos en general se le dan bien a N64 y casi todos ellos corren a una resolución elevada, 576x408 en este caso.


Ya de por sí salta a la vista una mejora gráfica, pero la cosa no acaba ahí, tal como hicieron en Excite Bike 64 Left Field añadió un sin fin de modos extra y novedades.


Vale no me digas más yo quiero ver esas caras hi-res, por muy feos que sean los jugadores de la NBA.


Pues parece que perdieron la cabeza en ello, benditos emuladores, igual tan hi-res no le ha gustado al plugin y ha pasado por completo.


Tanta felicidad no cabe en esa cara, habría que verlo perdiendo el partido o tras un pisotón.


De hecho existen animaciones y algunas expresiones faciales que pueden verse en planos cercanos o en las repeticiones desde todos los ángulos, en NBA Live 2000 también hay algo similar, pero el modo repetición de Courtside es el más avanzado de todos los juegos de NBA de N64. (gif sacado directamente de la consola)


La pelota como era de esperar es un objeto 2D para hacerla más redonda sin dedicar demasiado, las gradas usan la típica superficie plana donde ponen las texturas, en este caso por suerte no parece una lasaña en forma de público, en la segunda parte han puesto como 3 paneles adicionales delante de las gradas para dar más volumen y detalle.


En el primero los patrones del público son fáciles de ver, además no paran de lanzar fotos, ya hay ganas de ir a revelar carretes en aquella época.


En la segunda parte le han puesto más ganas, por ejemplo la grada del medio y los hermanos gemelos en la siguiente, detrás de las 3 capas detalladas han puesto un conjunto diferente de personas con formas y colores que no se repiten entre gradas, en muchos casos también aparecen banquillos vacíos por si juegan los equipos en la cola.


En cierto modo esto me recuerda al Quién es Quién?.. Y son 3 capas también.


Volviendo a la pista, uno de los detalles es ver reflejados algunos objetos en ella, como pueden ser luces, algunas paredes o los pies de los jugadores, he puesto la cámara por debajo de la pista y ahí están amputados, tenemos pies sin cuerpo y cuerpos sin cabeza.


Un vistazo a las animaciones y los modelados, así es el primero.


Así es el segundo, no solo mejora la cara o la animación en general, el cuerpo se ve mucho más real, parece que están usando muchos más polígonos pero lo cierto es que no, el primer juego usa bloques de polígonos para componer un cuerpo mientras que el segundo usa un esqueleto con información para poder animar después un modelado completo.


Para entenderlo mejor tenemos el Super Mario 64 de la DS, que redonditos no?


Ninguno de ellos tiene más polígonos que el modelado original de Mario 64 y sin embargo quedan mejor, versión DS a la izquierda, versión 64 a la derecha, a destacar la mayor experiencia modelando en 3D, Mario 64 sería de los primeros modelados de N64 o especialmente las herramientas, si aún hoy se hicieran juegos en N64 iban a lucir mucho mejor.


En Mario 64 por ejemplo se nota la unión de los brazos con el cuerpo y además como todo son bloques independientes unidos entre si se están usando polígonos de más para cerrarlos, aunque quedan por dentro y luego la consola los descarta es trabajo de proceso extra, esos polígonos desperdiciados están bien usados en la versión DS, para hacer cosas como una oreja y barbilla más redondeada, quitar esa especie de buche raro que tiene el de N64, etc.

Volviendo a Courtside, el modo arcade es un puntazo sobretodo para quién no le gusta demasiado la simulación real, la IA por su parte es bastante superior en la segunda parte, sin duda uno de los mejores juegos de NBA de la consola.
https://www.youtube.com/watch?v=ZisV8aHdM-E

Estaría muy bien que comentáramos detalles del Majora's Mask.

Como siempre con tus análisis se aprende un montón BMBx64, ni sabía que Courtside tenía una segunda parte, y encima mejora al primero. En su época se le dio mucha importancia al original, lo jugué bastante alquilado y prestado también, y eso que no me gustan demasiado los deportes. También muy interesante el pequeño análisis de los modelados de Mario64 de DS y N64.

Al igual que dice ashurek, sería muy interesante que analizaras Majora's Mask sobretodo con respecto a Ocarina, a mi nunca me pareció superior al primero y menos que obligase a usar el Expansion Pak, aunque seguro que estoy equivocado, por eso me interesa mucho tu opinión .

Me apunto lo del Majora's Mask, lo poco que he visto sin filtrado de texturas es muy similar a OOT, algunas muy buenas otras con altibajos.

También he comprado un cable sync on luma para una N64 RGB francesa.. estoy cruzando dedos porque he leído de todo, desde que no sacan svideo, a que es el mejor cable, según el polaco el cable funcionará, ya sacaré comparativas cuando me llegue si es que va.

PAL VS NTSC
He estado mirando algunos juegos a ver si merece la pena la versión PAL, dado que el framerate muchas veces oscila entre 20 y 30, no sería mejor si la versión PAL que corre a 25 resulta ser más estable que la NTSC?

El primero que he mirado es el Earthworm Jim 3D que afortunadamente tiene un debug en PAL y NTSC, el rendimiento es malo, al nivel de los peores de la consola en cuanto a poly (~30K), donde en la versión NTSC el juego cae a 20 (30, luego 25) aquí lo hace a 17fps (sobre 25), en este juego (y en muchos) no están sacando un cálculo sobre 50hz para saber si a la maquina le dará tiempo de hacer el número de frames establecido, es como si solo aplicaran un 16% más lento a la versión PAL pero manteniendo la lógica NTSC, por otro lado el algoritmo del frameskip de muchos juegos no es demasiado bueno, realmente no hay que bajar a 17fps de golpe, entre renderizar una sala pequeña a una más grande y compleja hay una buena diferencia sin embargo mantiene exactamente el mismo rendimiento, lo cual da a entender que el frameskip es excesivo (imagen sacada de consola).


Tenemos los juegos de Rare, al ser un equipo inglés se preocuparon más por el territorio PAL y adaptaron algunos juegos, por ejemplo Goldeneye tiene una resolución de 320x222 en NTSC y 320x268 en PAL, aunque la versión PAL se ve estirada los pixeles no parecen ser duplicados (se notaría en las montañas de nieve), el contador de balas tampoco está redimensionado, pero horizontalmente hay algo menos de visión.


El debug no está presente en la versión PAL pero da la impresión de que la versión NTSC es más fluida, en la PAL puede que se noten menos los altibajos, dado que el framebuffer es mayor en la PAL debería tener menos memoria disponible y ser más propensa a colgarse como cuando ponemos cientos de minas y las explotamos, aunque esto es solo una suposición.

Hay otros juegos de Rare como Perfect Dark que siguen la misma linea, en low res es recomendable la versión NTSC por tener menor resolución, sin embargo en hi res se mueve mejor la versión PAL por ser 448x268 en lugar de 640x222.

Banjo Tooei y otros títulos también usan 320x268 en territorio PAL, por deducir si estiran la imagen o no, pero por lo menos eliminan franjas negras.


Hay juegos que tienen un target fijo como Zelda OOT, Majora's Mask o Waverace 64, todos ellos corren a 20fps y lo hacen el 95-99% del tiempo, es la enorme diferencia entre un juego que lo intenta a 30 pero cae a 15 al girar la cámara y otro que siempre va a 20, el segundo resulta mejor experiencia, algunos plugins son capaces de identificar estas tasas y aplicarlas, por supuesto la versión PAL de estos juegos corre un 16% más lenta, entre 16-17fps, por lo tanto son versiones a evitar.


Y sin embargo no hay que fiarse de lo que digan los emuladores cuando el framerate está desbloqueado, es variable y apunta a 60hz, aquí no funciona ni de lejos a la cifra real, debería ser 12fps en emulador.



En otros casos como Rakuga Kids si que nos sirve para saber que efectivamente corre a 60fps porque el juego no es inestable y tiene el framerate desbloqueado.


CENSURA A LA CENSURA
Generalmente se habla de Superman 64 como el ñordo de la consola, pero ojo con Carmageddon 64, en la versión de PC al igual que aquí puedes completar las fases de distintas maneras, tratando de finalizar las carreras o cargándote a todos los contrincantes, pero la gracia está en hacerlo mientras atropellamos toda clase de seres vivos, gritan, se montan sobre el coche, ruedan por el suelo, salen volando o a cachos, nos dan tiempo extra para seguir jugando.

Para el port eliminaron todo eso y lo cambiaron por.. zombies, al igual que en PSX, todas esas físicas y colisiones que hacían tan divertido atropellarlos también eliminadas, como juego de carreras es peor todavía por la tasa media de fotogramas, junto al extraño control donde gira el coche con la cámara.


Pero el colmo se lo lleva la versión Alemana.. +18 a un juego de atropellar dinosaurios? Míralos, parecen actores, hasta que el coche no está a un palmo no se mueven.. ríete tú de Turok y sus sangrías.


Definitivamente le quitan todo el alma al juego original.
https://www.youtube.com/watch?v=CqBPEkpSUvY

La OST por su parte también es distinta, aunque algún tema pueda tener su aquel, la original es mítica.
https://www.youtube.com/watch?v=rDnpizDu1rQ

Lo cual me recuerda que hay juegos de destrucción más resultones como Vigilante 8 y su segunda parte.
https://www.youtube.com/watch?v=-oevkedK0P8

Ahí va... Menuda pasada lo del carmagedom. No lo recordaba tan sumamente cutre. La verdad es que a veces la censura jode loa juegos de una manera absurda.

Se han creado unos códigos de GS para poder jugar a 60 fps en emuladores a Mario Kart 64 y Diddy Kong Racing.
Los códigos no son perfectos porque algunas partes parecen o están aceleradas en ambos juegos, pero lo que es correr las carreras funciona sin ningún problema.

http://forum.pj64-emu.com/showthread.ph ... #post69612

Mario Kart 64 - WIP 60 fps
81001890 2419
81001892 0001
81001894 2419
81001896 0001
80000FE3 0000
800014CF 0001
81001C90 240A
81001C92 0001
81001C94 240A
81001C96 0001
81001A38 2409
81001A3A 0001
81001A3C 2409
81001A3E 0001
80122CBB 001C or 0003C (not confirmed)

Diddy Kong Racing (U) (V1.0)
Sixty Frames
80079A2B 0003
May freeze at some points,physics can get wonky with slopes on both codes. (Puede colgarse en algunos puntos, las físicas pueden dar problemas en pendientes en ambos códigos)

Alt Sixty Frames
80079A2A 0003
A friend informed me this didn't freeze. (Un amigo me ha informado que así no se cuelga).

Diddy Kong Racing (U) (V1.1)

Sixty Frames
80079E7B 0003
Same but for 1.1 as the primary test version. (Lo mismo pero para la vesión 1.1)

Alt Sixty Frames
80079E7A 0003
Same as above notes. (Igual que en los ocmentarios de arriba).


Esta gente va desarrollando códigos para forzar los juegos a framerates superiores al original, aunque al hacer eta muchas cosas dejan de funcionar correctamente porque precisamente se basan en el framerate y luego hay que ir haciendo ajustes a los códigos para dejarlo decente.
Por ejemplo, en los Zeldas la capacidad de salto y el tiempo que están encendidos los palos deku dependen del framerate y el juego se vuelve injugable pasando a 30 fps, no digamos ya a 60 fps (Link apenas salta y los palos deku duran un suspiro).
También desarrollan otros códigos para estabilizar el framerate a la tasa que debería de ir el juego y reducir los tiempos de carga de los juegos.
También hay por ahí códigos para forzar otros aspectos de imagen como 16:9 y 21:9 en juegos que no tienen soporte, pero al no estar diseñados para funcionar de esta manera hay problemas de popping en los laterales de la pantalla y defectos de imagen en los menús.

Lo de los dinosaurios en el Carmageddon 64 alemán es de las cosas más absurdas que haya visto en un videojuego.

No hay forma peor de arruinar un videojuego.

BMBx64 escribió:[beer]

DETALLES PERFECT DARK
...

Perfect Dark fue uno de los mejores títulos de Nintendo 64, repleto de detalles y donde Rare sacó pecho. Aún recuerdo cómo podías disparar a las luces de una sala, una oscuridad total solo interrumpida por los chispazos de las bombillas rotas. Algo que en juegos de hoy en día no es nada fácil de encontrar y que dice mucho de los desarrollos next gen a toda prisa.

Gran trabajo BMBx64

Genial, muy interesante, gracias.

Esta semana me ha llegado un cable RGB CSYNC PAL Multi audio para la consola y menuda diferencia, el audio puede ir por separado para evitar ruido de fondo, en concreto el cable es este:


He intentado sacar capturas pero ninguna le hace justicia, nunca había visto a la N64 sacar colores tan vivos y mostrar tal nitidez, sobretodo cuando hay goraud porque los suavizados los hace sin interferencias ahora.

Aquí una del Fifa (el granulado añadido al hacer la foto)


En el otro cable RGB que tenía era imposible ver a Mario con los colores sólidos, había una cascada de interferencias, por ejemplo en el rojo de la gorra, ahora se muestra perfecto en la tele LED.


La iluminación o las transparencias también han mejorado una barbaridad, salvo el dithering que se nota más en unos juegos que otros por el modo 16bits.


--
De paso dejo la ost del Castlevania SOTN para N64, ya la puse en otro hilo pero por si acaso


He montado una rom con las 34 canciones de la OST a 44khz/estéreo/128kbps en ogg, usando la libogg compilada para la consola, de momento no es muy aplicable in-game hasta que no resuelva como van los hilos de audio separados de la lógica del programa, lo que hace ahora es mantener todo el programa en espera mientras llena los buffers.

El fondo está hecho con el RDP, tiles de 64x32 de 16bits, 5 por cada línea, 30 en total, muy rápido.

Descarga en mega

También se me acumula la faena, tengo algunas cosillas pendientes por añadir al hilo

De paso dejo la ost del Castlevania SOTN para N64, ya la puse en otro hilo pero por si acaso


He montado una rom con las 34 canciones de la OST a 44khz/estéreo/128kbps en ogg, usando la libogg compilada para la consola, de momento no es muy aplicable in-game hasta que no resuelva como van los hilos de audio separados de la lógica del programa, lo que hace ahora es mantener todo el programa en espera mientras llena los buffers.

El fondo está hecho con el RDP, tiles de 64x32 de 16bits, 5 por cada línea, 30 en total, muy rápido.

Descarga en mega

También se me acumula la faena, tengo algunas cosillas pendientes por añadir al hilo

Perdon por el offtopic, siempre me paso por el hilo para leerlo. ¿pero me podrias decir como usar esa rom? La curiosidad me mata.
Me dio por meterle al project 64 pero no tira. Hablando desde la completa ignorancia. Lo siento.
PD: Era para un cartucho flash... bueno.

@blade133bo
Sí, la rom lo más seguro es que solo funcione en hardware original mediante cartucho flash, copión, etc, Project 64 si no son juegos comerciales no sabe como interpretar homebrew, por lo menos con la mayoría de plugins, en CEN64 podría funcionar, pero no es un programa fácil de usar.

En este caso no he usado la interfaz SD del Everdrive, si fuera así solo sería compatible con este cartucho, también me consta que hay librerías del neoflash para otra interfaz, luego a saber que hace 64drive, la verdad ni he mirado si existe una interfaz común de desarrollo, por compatibilidad he llenado tan solo de información el cartucho.

Señor Ventura escribió:@Sexy MotherFucker Mira, partículas a 60fps con bump mapping y 640x480

http://imgur.com/sam9t5z.

Y aquí también mira:



Pero para que te hagas una verdadera idea hasta qué punto llega la escena vamos a usar la cámara:



Eso sí todo a 512x448i, menos carga poligonal, y con texturas de mierda comparadas con las del Metroid Prime; pero tío es una puta Ps2, qué esperas de ella, bastante hace con no asfixiarse xDDDDD

Anyway; esto no representa el techo in-game de la consola a respecto de procesado de partículas: MGS 3 Snake Eater tiene tramos en que simplemente se dedican a fundir la tasa de relleno, y a hacer magia con efectos de back-buffer "transparentes" en la EDRAM de 4 MB. Z.O.E 2 es un punto itermedio, pero nada comparado con lo que se ha visto en MSG 3 en ciertos sitios, o en algún Onimusha.

Tenemos el hilo pendiente, no me olvido

P.D: Perdón por el off, es que acabo de ver el mensaje xDD

@Sexy MotherFucker

Hombre... es un pasillo, tio xD

Pero está claro que con mas cpu puedes hacer mejor uso del fill rate, que encima también es superior. El problema de la play es como le penaliza ese mismo fill rate el multipassing, entre otras cosas (como tener que hacer la mitad del trabajo de la GPU antes de empezar a hacer cuentas). Le viene genial a esa escena tener una carga poligonal tan baja.

La GC por su parte también tenía sus peculiaridades:
http://www.3djuegos.com/noticias-ver/10 ... ologia-3d/

Señor Ventura escribió:@Sexy MotherFucker

Hombre... es un pasillo, tio xD

Ya, pero es que esa escena no representa el pináculo del sistema, y aún con la penalización que sugieres sigue estando por encima de las otras es ese campo.

Ejemplo de programación solvente:

https://www.youtube.com/watch?v=jt0QGaf7LhI&t=5s

14 millones poly, 30 fps estables, resolución progresiva a 640x448p si no recuerdo mal (lo probé en emulador todo esto), festival de partículas, etc.

Lo de las partículas no es una venada mía, ni de Rusty xD; mismamente ahí en Beyond hay más developers que tocaron todos los sistemas que en legendarios post han dicho que si hay una única cosa en que la Ps2 le pasa mano por la cara a Gamecube y X-Box, es en post-procesado de partículas, y a la X-Box en ciertos efectos de backbuffer.

En el resto es peor porque es una puta Ps2 del año 2.000, con un hardware diseñado por el culo:

- No le pidas entornos muy detallados a 640x480 porque va asfixiada ya a 448i/p
- No le pidas bump mapping, depth buffering, etc; como los de una Gamecube/X-Box porque sencillamente es incapaz en cosas que no sean demos, o entornos muy controlados.
- No le pidas iluminación Gamecube sin sacrifiicar cosas porque es incapaz.
- No le pidas texturas variadas y detalladas a la vez en una escena porque 4 MB son pocos, y la compresión de texturas VQ es muy costosa por software.

Pero organízate bien el entorno, y conseguirás ciertas cosas que no puedes en una Gamecube, o incluso una X-Box, a nivel de partículas/efectos de backbuffer.

¿Pa qué le vale eso si el resto está por debajo? Pues pa taparse sus propias verguenzas con algún remiendo.

@Sexy MotherFucker

No, ya, ya... poca broma. Ni la lluvia del project gotham racing 4 está tan conseguida (¡PGR4!).

Una cosa en WDC prescinde del Z-buffering para doblar el fill-rate,pero solo mueve 100k-120k pol/seg a 30fps,que es la cifra que se suelen mover los juegos punteros de n64 con Z-buffering¿que esta haciendo uso del texturas en 2 pass? sino no entiendo que no dibuje más poligonos.

Salud.

dirtymagic escribió:Una cosa en WDC prescinde del Z-buffering para doblar el fill-rate,pero solo mueve 100k-120k pol/seg a 30fps,que es la cifra que se suelen mover los juegos punteros de n64 con Z-buffering¿que esta haciendo uso del texturas en 2 pass? sino no entiendo que no dibuje más poligonos.

Salud.

¿Qué juegos punteros de N64 se mueven a esos fps de forma estable? En los que pienso se mueven por debajo, o me da esa sensación.

Las cifras de WDC son aproximadas, en las carreras corren 8 vehículos pero no siempre están activamente en pantalla.

Pongamos que un coche son 650 polígonos, le descartamos por ejemplo la mitad por el culling, se quedan en 325, si salieran los 8 en pantalla a modelado completo serían 2600 polígonos por frame, pero es algo que va a ser harto difícil, habrá alguno con modelado intermedio o bajo si está más alejado, pero indistintamente del número de coches el juego funciona siempre igual, si lo que buscamos son picos de geometría serían más fáciles de conseguir en un VS, 1 tarima fija y 2 luchadores con todo controlado, aquí hay que calcular bien los segmentos de pista y por supuesto tendrían que coincidir los coches.

En cuanto a escenarios va bastante cargado, por ejemplo aquí se ven poco los wireframes, pero hay una buena pila de edificios amontonados.


En este otro gif se nota más la pista, lo que viene a ser curvas bastante redondeadas o todas las sombras del escenario sobre la pista a mano, si bien en las zonas más cargadas podrían haber entre 1000-2000 polígonos en escenarios.


Hay que tener en cuenta que si entras en vista interior hay un espejo frontal donde se muestra una segunda cámara con el escenario por detrás, el esfuerzo podría ser mayor que renderizar el coche, aunque parece una representación mini.


A lo sumo 4000x30=120K, que es lo que se viene diciendo, pero eso no importa porque no siempre alcanzará esa cifra o puede que en picos incluso sea superior a eso, manteniendo los 30fps, es un juego muy bien diseñado y rasca más en cosas como levantar polvo muy cerca de la cámara (porque pierde el control sobre esa tasa controlada).

En otros juegos con Fast3D puedes alcanzar 50-60K, si que es cierto que alguno con hacks en la libultra puede ponerte 100K como Conker, pero si giras la cámara donde hay que reorganizar el setup de triángulos a lo bestia o en condiciones similares te baja el rendimiento, el Stunt Racer 64 te usa el ucode Zsort, que es bastante más rápido que usar el Z-buffer del Fast3D y cualquiera de sus optimizaciones.

BMBx64 escribió:En este otro gif se nota más la pista, lo que viene a ser curvas bastante redondeadas o todas las sombras del escenario sobre la pista a mano, si bien en las zonas más cargadas podrían haber entre 1000-2000 polígonos en escenarios.


Hay que tener en cuenta que si entras en vista interior hay un espejo frontal donde se muestra una segunda cámara con el escenario por detrás, el esfuerzo podría ser mayor que renderizar el coche, aunque parece una representación mini.

El juego tiene buena pinta incluso así.

Como curiosidad..a mi me parece que la placa arcade Atari/Midway Seatle muestra sus gráficos muy al estilo de n64, salvando las distancias claro, pero cuando veo el aspecto visual de juegos como Mace the Dark Age, Carnevil, Hyper Drive o Vapor TRX....me hacen pensar que alguna tecnología en común tienen o al menos de la misma familia de chips.
Los gráficos de la placa Seatle son muy característicos ya que como n64 tira como de un texturado "lavado borroso" por decirlo de alguna forma y no tanta carga poligonal aparentemente, eso sí la resolución parece alta.
La cpu de Seatle es un R5000 y el sistema grafico 3DFx....yo veo a esta placa como lo que podría haber sido de forma bruta el hardware de Ultra 64.
Es una opinión personal, a vosotros que os parece?
Ahora desde el movil no puedo cascar unas imágenes.

Xfactor escribió:Como curiosidad..a mi me parece que la placa arcade Atari/Midway Seatle muestra sus gráficos muy al estilo de n64, salvando las distancias claro, pero cuando veo el aspecto visual de juegos como Mace the Dark Age, Carnevil, Hyper Drive o Vapor TRX....me hacen pensar que alguna tecnología en común tienen o al menos de la misma familia de chips.
Los gráficos de la placa Seatle son muy característicos ya que como n64 tira como de un texturado "lavado borroso" por decirlo de alguna forma y no tanta carga poligonal aparentemente, eso sí la resolución parece alta.
La cpu de Seatle es un R5000 y el sistema grafico 3DFx....yo veo a esta placa como lo que podría haber sido de forma bruta el hardware de Ultra 64.
Es una opinión personal, a vosotros que os parece?
Ahora desde el movil no puedo cascar unas imágenes.

Tengo la misma sensacion !
es casi la pcb usada por ultra 64 en killer instinct arcade con la adicion del 3dfx.
una burrada de placa.
Me encanta.

Mirad el texturado y modelo poligonal de Carnevil....puro n64 style

Me da que no, eh?. Ya solo la iluminación muestra diferencias, y luego está el conteo de polígonos, y la calidad de las texturas.

A lo mejor me equivoco, pero no me parece similar a una N64.

el juego san francisco rush de N64 siempre me ha parecido muy similar a la version recreativa que corre bajo la placa ATARI FLAGSTAFF HARDWARE
http://www.system16.com/hardware.php?id=781&gid=545#545

BMBx64 escribió:Las cifras de WDC son aproximadas, en las carreras corren 8 vehículos pero no siempre están activamente en pantalla.

Pongamos que un coche son 650 polígonos, le descartamos por ejemplo la mitad por el culling, se quedan en 325, si salieran los 8 en pantalla a modelado completo serían 2600 polígonos por frame, pero es algo que va a ser harto difícil, habrá alguno con modelado intermedio o bajo si está más alejado, pero indistintamente del número de coches el juego funciona siempre igual, si lo que buscamos son picos de geometría serían más fáciles de conseguir en un VS, 1 tarima fija y 2 luchadores con todo controlado, aquí hay que calcular bien los segmentos de pista y por supuesto tendrían que coincidir los coches.

En cuanto a escenarios va bastante cargado, por ejemplo aquí se ven poco los wireframes, pero hay una buena pila de edificios amontonados.


En este otro gif se nota más la pista, lo que viene a ser curvas bastante redondeadas o todas las sombras del escenario sobre la pista a mano, si bien en las zonas más cargadas podrían haber entre 1000-2000 polígonos en escenarios.


Hay que tener en cuenta que si entras en vista interior hay un espejo frontal donde se muestra una segunda cámara con el escenario por detrás, el esfuerzo podría ser mayor que renderizar el coche, aunque parece una representación mini.


A lo sumo 4000x30=120K, que es lo que se viene diciendo, pero eso no importa porque no siempre alcanzará esa cifra o puede que en picos incluso sea superior a eso, manteniendo los 30fps, es un juego muy bien diseñado y rasca más en cosas como levantar polvo muy cerca de la cámara (porque pierde el control sobre esa tasa controlada).

En otros juegos con Fast3D puedes alcanzar 50-60K, si que es cierto que alguno con hacks en la libultra puede ponerte 100K como Conker, pero si giras la cámara donde hay que reorganizar el setup de triángulos a lo bestia o en condiciones similares te baja el rendimiento, el Stunt Racer 64 te usa el ucode Zsort, que es bastante más rápido que usar el Z-buffer del Fast3D y cualquiera de sus optimizaciones.

En fin, fantásticos aportes como siempre .
La verdad es que el WDC si que tiene un nivel de poligonos tipo PSX, como dices las curvas bastante redondas. Una pena que no hubiera más así.

Voy a ir lanzando una serie de tests para la consola, iré aumentando la complejidad de los mismos, pero primero empezaré por cosas sencillas analizando como se puede ir mejorando el rendimiento, puedo liberar código si se requiere, limpiándolo primero y eso, de momento solo pondré la descarga de los tests.

TEST 1: EXPLOSIONES


Este test es muy sencillo, permite poner de 1 a 999 sprites animados de forma independiente, cada explosión consiste en 5 frames, el tamaño de los sprites varía, el más grande es de 32x32, mientras que el más pequeño de 8x8, son texturas de 16bits, lo cual ya de por sí es lento.

Cuando la explosión termina se generan aleatoriamente nuevas coordenadas para X/Y, para ello he usado una nueva función rand, ya que la que viene con mips64 no funciona bien.

El rendimiento inicial era de:
410 explosiones a 60fps (NTSC)
507 explosiones a 50fps (PAL)

Primero a destacar que aquí el frameskip SÍ funciona correctamente, así tendrían que ser los juegos PAL de N64, aguantando más antes de hacer saltar el frameskip y de hecho he notado que Perfect Dark parece funcionar mejor en PAL, pero es algo poco común en otros juegos.

El rendimiento no es para tirar cohetes, pero en el test estoy recargando la textura por cada explosión sin ningún tipo de estrategia, así que vamos a hacer lo siguiente, una comprobación, si la última explosión era el frame 2 y la explosión de ahora es frame 2, no recargarás la textura.

Resultados con previsión smple de textura:
480 explosiones a 60fps
579 explosiones a 50fps

Bueno, vamos mejorando.. se podría optimizar mucho más, como pintar todas las explosiones de frame 1 sin recargar textura y luego las de 2, pero eso afectaría Z, dado que el orden al pintar interfiere directamente en la prioridad de pintado, así que lo dejamos así.

Toda esa ganancia solo añadiendo ésta linea de código:


Otros apuntes:
- Dado que el fondo es negro se requiere limpiar el buffer de pantalla, aunque en el test he incluido 3 modos:
* Limpiar buffer de pantalla con el RDP mediante fill color (color negro evidentemente)
* Limpiar buffer a través de la CPU (muy lento, cae a 30fps desde la primera explosión)
* No limpiar buffer (aquí la ganancia es de igual 1 sprite, lo cual quiere decir que el modo fill color es excesivamente rápido)
- No hay diferencia de rendimiento entre usar una explosión con marco negro (sin transparencia) o usar canal alpha para que la explosión tenga zona transparente (bordes, no semitransparencia).
* Con 30 o 40 explosiones ya se podría llenar la pantalla de explosiones.
* Con 999 explosiones el test se mantiene a 30fps.
* El rendimiento es variable dado que las explosiones son aleatorias y no todas coincidirán de la misma forma cada vez que arranquemos el test.

CONTROLES
A - Incrementar explosiones (de 1 a 999)
B - Reducir explosiones
Start - Explosiones a 1
Z - Explosiones a 999
C Arriba - Limpieza de buffer con RDP
C Izq - Limpieza de buffer con CPU
C Abajo - No limpiar (útil si se pinta fondo, aquí dejará rastro)

DESCARGA
Link mega

Siguiente test, explosiones más complejas, en lugar de ser de 32x32, serán de 100x100, en lugar de 5 frames serán 12, habrá que texturizar múltiples veces en cada sprite, en este se hacen en 1 solo paso.

Con el project64 no funciona...

Menudo fill rate mas bestia tiene

Preguntóme yo, si alguien de aquí que controla, sabe de los errores o averías más frecuentes en una Nintendo64. Os cuento mi caso: tras emparanoyarme con el hilo sobre la vida que le queda a las consolas retro, he re enchufado mi N64 para probar los juegos. Me van casi todos a la primera o segundo intento, pero hay un puñado que o no me van nunca, o me van tras 1000000 intentos, y estos encima a los pocos minutos me cuelgan la consola.
No sé si es la consola o los juegos, la cosa es que con los otros juegos no se me cuelga la máquina al minuto ni me dan errores de sonido. Pero desconozco la motherboard de la N64 y me gustaría saber si existe alguna avería común relativa a condensadores hinchados o cosas así que pudieran afectar, más que nada para ver si me busco a alguien que los pudiera cambiar en caso de ser así.

@Falkiño Limpia los contactos, la gran mayoría de las veces ese es el problema.

Usa una goma de borrar, es lo mejor, pero si usas un paño o algo, que esté totalmente seco.

Señor Ventura escribió:@Falkiño Limpia los contactos, la gran mayoría de las veces ese es el problema.

Usa una goma de borrar, es lo mejor, pero si usas un paño o algo, que esté totalmente seco.

Veo complicado meter una goma con mis manazas xD pero lo intentaré. Gracias por el consejo. ¿Basta con pasar la goma suavemente o recomiendas hacer algo de presión?

Falkiño escribió:Veo complicado meter una goma con mis manazas xD pero lo intentaré. Gracias por el consejo. ¿Basta con pasar la goma suavemente o recomiendas hacer algo de presión?

Haz un poquito de presión, que frote bien ahí.

Las gomas de los lápices no suelen ser muy buenas, pero si cortas una goma con un cuchillín, o algo, podrás usarla sin problemas para limpiar los contactos de los cartuchos.

Cuando termines usa un trapito para "pulirlo", y quitar los restos que puedan evitar un buen contacto, y fuera.

TEST 2: EXPLOSIONES MÁS GRANDES
Los resultados de este test al principio decepcionan, 27 explosiones a 60fps o 33 a 50fps, pero luego de mirar los números el rendimiento parece en la linea del anterior.


- El sprite de 16bits más grande del test 1 era de 32x32 (2KB) mientras que en este es de 122x96 (22,8KB), el más pequeño en el test 1 era de 8x8 (0,125KB), aquí lo es de 58x48 (5,4KB), con lo cual puede que mueva una media de 15 veces más de información y sin estrategia de recarga de textura.

- Este test consta de 12 animaciones, para la consola es indiferente actualizar a cada frame o no, pues tiene que renderizar todo de nuevo usando la pequeña cache de 4KB, haya movimiento o no, así que si tenemos memoria de cartucho y RAM no estaría mal actualizar todo a cada frame.

Para montar las explosiones lo he hecho en múltiples pasos, parece que el RDP o bien mksprite tienen problemas con ciertos tamaños verticales, 44x48 mala visualización, 44x44 idem, sin embargo si son 8, 16, 32, etc funciona correctamente.

Así que he montado un programa que analiza el png, detecta si es impar horizontalmente y le añade un pixel (pues la consola se cuelga con texturas impares) y recorta en laminas de un tamaño válido de cache, está pensado para soportar recortes de hasta 128x16, si el sprite acaba antes le añade espacios, esto para automatizar un poco el proceso sino es un coñazo.

La herramienta también da el centro virtual de la imagen, ya que todos los gráficos en el RDP se pintan alineados por arriba a la izquierda y en esta explosión se requiere el centro, más adelante se podrá setear con el ratón un nuevo centro virtual, además de tablas de tiempo de animación, esto para hacer personajes animados es primordial, también me gustaría generar la texturas a partir de este programa y prescindir del mksprite.


DESCARGA - TEST2
Link mega

He encontrado un código donde utilizan texturas de 8bits (paletas), miraré de estudiarlo a ver como de difícil es de implementar al entorno, porque visto lo visto las texturas de 16bits son muy lentas, aunque creo que 4 planos de scroll a pantalla completa de textura única (320x240) y unos 100 sprites de 32x32 si que se podrían alcanzar en este modo.

Para el siguiente test voy a prescindir de las texturas y a tirar de fill color a ver que pasa, con algún test de partículas o algo similar.

Por cierto me he encontrado con este fallo tras poner en el Everdrive Diddy Kong Racing y luego Destruction Derby 64, a saber como quedan los estados del RCP para que el segundo no arranque.


@Señor Ventura
Sí, los tests con libdragon solo funciona en hardware original o quizás en los emuladores CEN64 o MESS, puedo mirarlos y poner una descarga con todo configurado, sin poder probar los tests igual pierden la gracia..

EDIT
Desactivando flush texture se consigue aumentar el rendimiento de forma exponencial, casi el doble en el segundo test, por lo visto viene en automático por defecto y si solo se va a usar 1 slot de textura no tiene mucho sentido, ya se limpia en cache al cargar otra encima.

Test 1
480 => 593 NTSC
579 => 728 PAL

Test 2
27 => 50 NTSC
33 => 62 PAL

He actualizado los links con los tests mejorados.

MÁS RESOLUCIONES INTERNAS
Dejo otra tanda de resoluciones exóticas, en algunos juegos es la resolución por defecto y no existe otra.

Turok: Rage Wars (480x360), la misma resolución que Turok 2, Turok 3 o Shadowman 64, necesita expansion pak.


Scooby-Doo! Classic Creep Capers (480x240), no requiere expansion pak.


Rampage 2 - Universal Tour (400x240), la primera parte debería correr a la misma resolución, no requiere expansion.


Nightmare Creatures (512x240) o bien 510x237 sin redondear, resolución única sin expansion y se mueve bastante bien, aunque el juego es muy oscuro.


Xena: Warrior Princess: The Talisman of Fate (440x240), aparece en la lista de juegos soportados por el expansion pero no me ha parecido ver ningún cartel o opción de resolución, viendo que es de Titus esperaba lo peor pero se mueve bien, la pega es lo cutres que son las animaciones.


--
Dato curioso.. la partida guardada en el controller pak es compatible entre regiones en algunos juegos, por ejemplo se puede continuar partida con Turok 1, Quake o Duke Nukem en PAL y NTSC.

Juegos como Rush 2049 cargan la partida pero luego dicen que los datos son corruptos, así que sería aconsejable quitar el controller pak en este caso, hay otros juegos que no detectan la partida entre regiones o utilizan nombres distintos.

QUAKE 2
Dejo este vídeo de DF donde analizan un poco la saga pero el 2 principalmente, a partir del minuto 12 empiezan a hablar de los ports y de la versión de N64, que no es un port del 2 sino una versión única como Doom 64, a destacar que en este caso usar el expansion pak sí mejora el rendimiento del juego.
https://www.youtube.com/watch?v=DFYjSkUdfb4

--
Iba a hacer una saga de tests pero veo que no despiertan demasiado interés, así que cuando tenga algún juego de prueba o algo interesante ya volveré a hablar de ello.

TEST 3: COPOS
En este test en lugar de texturizar se utilizan rectángulos de colores renderizados por el RDP, de 4x4 en forma de copos con desplazamiento independiente.


Rendimiento inicial:
5120 copos a 60fps
6430 copos a 50fps

Usando variables de 16bits en lugar de 32bits y otras optimizaciones:
5600
7120

Este test mueve unos 350K rectángulos por segundo en el test PAL, la mayoría del trabajo lo hace la CPU.

- Si se utilizan copos de 8x8 el rendimiento solo baja en 100 copos, por lo que el fillrate no es el problema.
- El uso de "static" en según que variables cambia drásticamente el rendimiento para bien o para mal, no sé exactamente como funcionan las optimizaciones del compilador.
- Es seguro usar variables de 16bits para cosas como coordenadas, mejora el rendimiento.
- La consola puede ser más rápida generando números aleatoriamente que guardándolos en una tabla y rescatándolos después ¿?
- Aún y con todo estos tests son solo de rendimiento con la librería, no de la consola en sí.

Los controles igual que en los otros tests, salvo que R activa distintos colores.

DESCARGA - TEST3
Link mega

Tras hacer un repaso y mirar todo el código de la librería, por hardware solo permite estirar los sprites, no parece que deje usar las semitransparencias, ni rotar, ni paletas ni otras cosas básicas como acceder al buffer..

Sin embargo editando la librería si que pueden crear nuevas funciones que dejen acceder al buffer entre otras cosas, tiene funciones get_pixel y set pixel para pintar por software en sus funciones que no están disponibles con la librería compilada, obteniendo el color del pixel del buffer también podríamos hacer un blend additive como se comentaba páginas atrás (se supone que la consola solo puede hacer lo que le permita color combiner, que es el comando del RDP que evita que sea la CPU la que vaya a leer al buffer para luego mezclar los colores) y en lugar de usar set pixel se puede ir llamando al rdp en modo fill color para rellenar pixels y quizás acelerar el proceso, sería una función mitad cpu y mitad rdp.

Con fill color + semitransparencia se pueden hacer fundidos a negro de la pantalla y a la inversa, o fundidos a rojo cuando hay fuego, regiones de agua, etc de forma muy rápida, por lo pronto iré editando la librería añadiendo todo lo que pueda.

@BMBx64 Mas de 7000 partículas xD

Con algo así se pueden recrear tormentas en un plataformas 2D la mar de curiosas, o incluso simular el fluído de un líquido... ¿técnicamente podría ser? (aunque imagino que agotas todo el fill rate para sprites y fondos, pero igualmente sigue siendo brutal).

@BMBx64 una duda rápida; ¿por qué no salió la N64 con más frecuencia de reloj si está demostrado que el r4300i rula con excelentes resultados a 125 mhz? ¿Temían posibles problemas de sobrecalentamiento?

Juegos como Rogue Squadron lo hubiesen agradecido un montón por lo que se ve aquí:

https://www.youtube.com/watch?v=nYI9gPS-tc4

Y eso que es overclock a lo loco, es decir, no son juegos programados aprovechando esos ciclos; sino que simplemente se beneficían de la aceleración para el frame-rate.

Con la Mega Drive me corroe la misma duda; a 10 Mhz ha demostrado que va fina filipina sin mayor problema, y conozco a gente que la tiene a 13 Mhz...

¿Por qué un M68k a 7,67 Mhz cuando el standard era 10 y la consola lo soportaba sin problemas?

Sexy MotherFucker escribió:@BMBx64 una duda rápida; ¿por qué no salió la N64 con más frecuencia de reloj si está demostrado que el r4300i rula con excelentes resultados a 125 mhz? ¿Temían posibles problemas de sobrecalentamiento?

Juegos como Rogue Squadron lo hubiesen agradecido un montón por lo que se ve aquí:

https://www.youtube.com/watch?v=nYI9gPS-tc4

Y eso que es overclock a lo loco, es decir, no son juegos programados aprovechando esos ciclos; sino que simplemente se beneficían de la aceleración para el frame-rate.

El caso es que overclockearla no hace que se note el frame rate mas suave, es mas rápido, pero no mas suave). Tendría que estar mucho mas subida de vueltas para que se notase.

Sexy MotherFucker escribió:Con la Mega Drive me corroe la misma duda; a 10 Mhz ha demostrado que va fina filipina sin mayor problema, y conozco a gente que la tiene a 13 Mhz...

¿Seguro que no se calienta ni nada?.

Sexy MotherFucker escribió:¿Por qué un M68k a 7,67 Mhz cuando el standard era 10 y la consola lo soportaba sin problemas?

Porque nosotros somos unos frikazos, y queremos un hardware que aproveche hasta el último ciclo, pero ellos quieren un hardware que no de problemas, y sea una plataforma que albergue sus juegos sin pensar en si podrían transferir un par de tiles mas, o dibujar algunos sprites mas.

De hecho, sin estar configuradas a tope llegaron al punto de terminar su generación sin aprovechar a tope sus características. Viendo que caparon su direccionamiento a solo 32 megas (cuando pudo haber direccionado 128), para mi que no se esperaban que fuera a necesitarse mucho durante todo el tiempo que estuvieron vivas (y en parte así fué, pocos cartuchos de mas de 32 megas vimos en aquella generación).

Señor Ventura escribió:¿Seguro que no se calienta ni nada?

A 10 mhz ningún problema, a 13 no sé. Vamos, no tengo conectado el overclock todo el día, pero sí te digo que lo utilizo en partidas largas a cosas como Gunstar Heroes o ThunderForce IV (elimina bastante los slowdowns), y me puedo tirar 3 horazas tranquilamente al primero.

Es un tema curioso, porque en los juegos primerizos en los que el Motorola intervenía en el funcionamiento del driver de sonido, las músicas se aceleran.

Sexy MotherFucker escribió:

Señor Ventura escribió:¿Seguro que no se calienta ni nada?

A 10 mhz ningún problema, a 13 no sé. Vamos, no tengo conectado el overclock todo el día, pero sí te digo que lo utilizo en partidas largas a cosas como Gunstar Heroes o ThunderForce IV (elimina bastante los slowdowns), y me puedo tirar 3 horazas tranquilamente al primero.

Es un tema curioso, porque en los juegos primerizos en los que el Motorola intervenía en el funcionamiento del driver de sonido, las músicas se aceleran.

Es una buena manera de saber que drivers pertenecen al z-80, y que drivers no xD

@Sexy MotherFucker
Supongo que fueron conservadores, igual no todas las CPU pueden alcanzar los 125MHz, desde luego muy pocas aguantan con el multiplicador a 3.

Aún así menudo cuello de botella se iba a generar con eso, lo que tendrían que haber hecho es acompañar la CPU con RAM de baja latencia para sacarle todo el partido y dejar la RDRAM solo para el RCP que accede por DMA y lo hace mejor que la CPU.

Además de meter más cache de texturas, por lo menos 16KB, ya que el mip map o algunas paletas dividen la cache.

Se rumoreaba que la CPU iba a ir a 105Mhz, eso sería si el RCP fuera a 70Mhz (lo cual sería un incremento en todos los componentes), la verdad es que hubiera estado muy bien así, pero la memoria usa ese multiplicador y ya va calentita..

@Señor Ventura
350K o 7000 rectángulos es un resultado pobre, estoy seguro que algo falla en todo el proceso y seguramente encuentre formas de mejorarlo, teniendo en cuenta que turbo 3D en teoría pondría 500K triángulos (que son más lentos y en 3D), en condiciones reales de juego con libdragon podrías poner cientos de todas formas, los tests buscan un punto de estrés donde algún componente se satura y perjudica a los demás, en el de los copos es la CPU en conjunto con la RAM (que para colmo tiene el framebuffer en ella), así que tengo que encontrar como aligerar el código o ver si se está usando de forma óptima.