Hilo de detalles y curiosidades de N64

@Sexy MotherFucker Si quiere tirar el dinero que compre agua con azucar a 300€ a algún homeópata

EMaDeLoC escribió:Pero ahora me ha entrado la curiosidad y quiero comprobar unas cosas de la salida RGB de la consola, como si es posible la compatibilidad de un juego de 60Hz en una consola y una TV CRT PAL. Si tengo un rato lo miro este finde y lo cuento por aquí.

A que te refieres con esto?

@Calculinho , gracias por la recomendación, como siempre. Yo tengo la N64 Pal, de cuando salió. Lo del pad, lo tengo mega claro.
Hace poco me he hecho con una Famicom AV(top loader), con los mandos dogbone y flashcard. Tengo mi MD con mod de región+hz, y como digo, he notado mucho, mucho la diferencia, tanto en MD como en MS.
Estoy leyendo muy interesado este hilo, por las conclusiones que vais sacando.

La N64 es una consola a la cual le tengo mucho cariño, pero por un conjunto de circunstancias no la pude disfrutar tanto como las generaciones de 8 y 16 bits. La verdad es que en un futuro muy próximo me gustaría dejarme la consola lista en las mejores condiciones posibles para jugar conforme me va apeteciendo.

Después de mi experiencia con la Famicom AV y la MD con mods, se me hace raro que la N64 Pal pueda ser la mejor opción, pero si no hay tanta diferencia como con las otras máquinas, por mi mejor.

Un saludo.

@aranya a ver que si quieres gastar pasta puedes comprarte una PAL - Francesa que sea compatible con el mod RGB o pillarte el cacharro para hacerle el mod HDMI o directamente un framemaster. Pero hablamos de tres cifras por una mejora de calidad que teniendo un CRT la verdad yo no lo considero tan importante, si tienes que enchufar la consola a una tele plana sí, ahí estás jodido porque se ve muy mal esta consola en teles modernas.

La mejora con esos mods se nota, pero tampoco nos engañemos los juegos siguen siendo poligonotes cuadrados, que los veas más nítidos no los va a redondear ni a meterles motion engine. Si fuera algo de 20-30€ yo sería el primero en comprarlo, pero entre tanto CRT y así tienes la "true experience 90's" y para el tema de jugar a 60hz no lo necesitas, con el flashcard y roms a 60hz listo. Lamentablemente, que yo sepa, no es posible forzar 60hz en juegos PAL ni modificando la consola ni las roms así que en muchos casos tendrás que elegir entre 60hz o idioma español. Por encima, las pocas tradus españolas que tiene N64 son en su mayoría de juegos PAL, no sé si es que era más complicado hacerlo en la NTSC o si no pensaron en el tema de los hz.

@Calculinho , no, yo paso de teles modernas. Pillé un CRT de 29 Philips para las clásicas. Me has convencido, viendo como está el panorama en la 64 y teniendo ya la consola PAL, tiraré de flashcard y jugaré con juegos de otras regiones.

Gracias de nuevo. Un saludo.

radorn escribió:No creo que el coste de la RDRAM bajase tanto como para ser comparable al precio del conector.

Ya digo que es el conector y el terminal pak, son dos cosas, y encima esta última se compone de plástico y circuito, así que su dinero debió costar.
No he encontrado precios de RDRAM, pero si genéricos en esta web y el coste por MB bajo a la cuarta parte en tan solo 1 año, del 95 al 96, justo en la época que salía la consola. De ahí que pronto salieran revisiones de la N64 con un solo chip de RDRAM en vez de dos. ¿Podrían haber sacado una revisión de la consola con los 8MB ya instalados y el mismo coste? Yo creo que si, pero tener dos modelos de consola en el mercado es absurdo y una estupidez comercial, es reconocer claramente que la cagaste en el primer diseño.
No es que la consola con 8MB desde el principio hubiese aportado muchas mejoras, pero al saber los desarrolladores que tenían mejores especificaciones de máquina desde el principio y por defecto, no de forma opcional, habría más juegos con opción a hi-res, mapeados mayores, etc.

radorn escribió:

EMaDeLoC escribió:Pero ahora me ha entrado la curiosidad y quiero comprobar unas cosas de la salida RGB de la consola, como si es posible la compatibilidad de un juego de 60Hz en una consola y una TV CRT PAL. Si tengo un rato lo miro este finde y lo cuento por aquí.

A que te refieres con esto?

Nada, una tontería, he probado una consola NTSC con un juego de la misma región en una tele PAL con el RGB y efectivamente funciona. Ya lo había leído por ahí, pero si no lo pruebo no me quedo tranquilo.
Vamos @aranya que si te interesa el tema del RGB te puedes pillar una N64 japo de las primeras y el mod RGB sencillo (ambos son muy baratos y fácil de instalar) y conectarlo a la tele de tubo. El cable compuesto es verdad que es suficiente, pero la imagen "vibra" un poco y con RGB queda perfecta.

ziu escribió:EMaDeLoC
Una curiosidad!
Has comentado que con las nuevas librería se le puede sacar entre un 40-60 % más de rendimiento por poder ver cosas estilo Tekken 3 o Daytona..

Quien ha creado estás librerías?
Están desarrollando cosas interesantes?

Gracias!

Huy, no no, lo ha dicho @Sexy MotherFucker y ha dicho un 15-20%. Son unas librerías en las que colabora @BMBx64 y da información con cuentagotas, principalmente porque la cosa esta aún en desarrollo. A ver si se pasa por aquí y comenta como va el tema, pero no disponía de mucho tiempo.

P.D.: Hostia que post, con tanta gente parece el camarote de los hermanos Marx.

Ojo, que yo no he dicho que la N64 pueda con una Daytona, ¿estamos locos?. Digo que me gustaría ver lo cerca que puede llegar de ese resultado a costa de sacrificios que es muy distinto. Aunque quizás he puesto un mal ejemplo, ya que DU implica 57-60 fps para ser un auténtico Daytona, y quizás eso es pedirle demasiado a la N64 con más 100.000 polígonos por segundo y una capa de texturas, incluso a 320x224.

@aranya y si no te quieres andar con hostias de mods, con el cable s-video experimentarás una mejora ligeramente palpable en la calidad de imagen por un módico precio.

EMaDeLoC escribió:P.D.: Hostia que post, con tanta gente parece el camarote de los hermanos Marx.

¡Y también 2 huevos duros!

@Sexy MotherFucker Pues mira, una cosa que me pica bastante es que no he encontrado en ninguna parte los polígonos por segundo del Daytona en la AM2. Lo único que tengo a mano es lo que mueve la máquina, entre 300.000 y 500.000 triángulos por segundo, una burrada para la época.
Suponiendo que DU no la exprima al máximo y se vaya a los 360K, hablamos de 6.000p/f yendo a 60fps, mientras la N64 puede tirar como mucho a 1.500p/f. Hablamos de quitarle al juego 3/4 partes de los polígonos.
Ahora bien, si no somos muy avariciosos nos podemos ir a la versión de la Saturn y sin muchos cambios dramáticos irnos a los 30fps sin dificultad (posiblemente, claro) aprovechándonos de las mejoras gráficas como corrección de perspectiva y tal.
De hecho, acabo de encontrar una página comparativa muy minuciosa entre el hardware de la época y la Saturn estaba muy cerca en potencia de la N64. Así que los ports de una consola a otra deberían ser posibles, siempre y cuando se programe desde cero, ya que las arquitecturas son radicalmente distintas y es más fácil que tratar de portear a saco. Y con el límite del cartucho, claro...

Bueno, a ver si así te haces una idea y aguantas una temporada tus ganas de ports en la N64.

EMaDeLoC escribió:una cosa que me pica bastante es que no he encontrado en ninguna parte los polígonos por segundo del Daytona en la AM2.

Te refieres a la Model 2, AM#2 es el departamento de desarrollo de SEGA liderado en ese entonces por el gran Yu Suzuki.

Según se ve en emuladores, y por la documentación oficial, la Model 2 original era capaz de gestionar 300.000 polígonos quads texturados por segundo a 60 fps, lo que potencialmente quiere decir 600.000 a 30 fps, con algunos filtros, y 496x384p de resolución. Luego son 900.000 vectores sin texturas generados. Triángulos son 500.000 con texturas @60 fps, pero creo que se usaron más los primeros en los juegos de AM2 para facilitar los ports a la Saturn.

Normalmente las placas Model de SEGA siempre iban A TOPE, o casi, en cuanto a rendimiento, programadas a destajo con mucho ensamblador, y algo de C.

Hubo 2 revisiones de la placa original en cualquier caso, que mejoraban el audio y las capacidades de las FPU/Co-procesadores para datos en coma flotante, entre otras cosas.

@Sexy MotherFucker Pues si iban a tope, peor se lo pones al port...

Creo que o bien te conformas con el port de Saturn a 30 fps, que no esta mal, o con el DU arcade original sin texturas con flat Gouraud que la N64 te podría mover a 60fps en teoría.
Pero me da que perdería mucho el juego...

@EMaDeLoC el caso en que en Saturn también se pudo hacer mejor xD

Gracias anyway por intentar aliviarme. Toca paciencia e ir siguiendo y apoyando el trabajo de BMBx64 y el resto del equipo.

BTW uno de mis grandes descubrimientos de este hilo ha sido una cosa tan tonta como saber que el Conker funciona sin expansion-pak, no sé porqué yo tenía metido en la cabeza que sí. Viendo el óptimo rendimiento que tiene un juego de última tirada con esas viejas herramientas, los resultados posibles con las nuevas + uso de memoria son esperanzadores.

@Sexy MotherFucker , si, lo tengo en cuenta.

Un saludo.

radorn escribió:N64: primera revision de placa NUS-CPU-01 - 12 ICs
https://upload.wikimedia.org/wikipedia/ ... 1_F_01.jpg

PS1: modelo original SCPH-100x - 18 ICs
http://www.the-liberator.net/site-files ... eboard.JPG

SAT: no se que modelo es - 24 ICs
https://upload.wikimedia.org/wikipedia/ ... rboard.jpg

Que cucada la placa de la N64

Parece una Rasp y todo

@elneocs Aprovecho que respondes a eso para añadir que las placas de PS1 y Saturn, especialmente las revisiones mas tempranas, tambien tienen chips en la otra cara de la placa, mientras que la N64 solo tiene algunas resistencia y condensadores SMD y el conector del 64DD detrás.
Algun modelo de Saturn se aproxima a los 32 chips contando los de detrás.

Además, la mayoria de chips en la N64 son chips menores y solo 3 o 4 son microprocesadores o RAM principal. Entr el resto solo está el PIF, que es un microprocesador de 4bit (si, 4, no 8 ni 16, si no 4), y los demás son son DACs, clockgens, amplificadores,etc.
En cambio, PS1 y especialmente Saturn están llenos de procesadores y sus memorias dedicadas.

Que conste que no estoy haciendo ninguna comparacion de cual es mejor. Desde hace años ya cada vez me gustan mas PS1 y SAT. El unico proposito de esto es ilustrar que la N64 estaba diseñada con reduccion de costes en mente, y uno de los principales indicadores de coste en una placa es la cantidad de componentes, especialmente los grandes: Procesadores y memoria.

No soy ningun fan de Apple, pero hace poco vi unas declaraciones de Steve Wozniak sobre como habia diseñado el Apple II, creo, y de como "refactorizaba" el diseño para reducir costes buscando optimizar la cantidad de componentes, cambiando transistores separados por integrados que juntaban la funcionalidad de varios transitores, y cosas asi. Siempre estaba revisando catalogos de componentes, viendo como podia "compactar" el diseño un poco mas.

Sexy MotherFucker escribió:

EMaDeLoC escribió:una cosa que me pica bastante es que no he encontrado en ninguna parte los polígonos por segundo del Daytona en la AM2.

Te refieres a la Model 2, AM#2 es el departamento de desarrollo de SEGA liderado en ese entonces por el gran Yu Suzuki.

Según se ve en emuladores, y por la documentación oficial, la Model 2 original era capaz de gestionar 300.000 polígonos quads texturados por segundo a 60 fps, lo que potencialmente quiere decir 600.000 a 30 fps, con algunos filtros, y 496x384p de resolución. Luego son 900.000 vectores sin texturas generados. Triángulos son 500.000 con texturas @60 fps, pero creo que se usaron más los primeros en los juegos de AM2 para facilitar los ports a la Saturn.

Normalmente las placas Model de SEGA siempre iban A TOPE, o casi, en cuanto a rendimiento, programadas a destajo con mucho ensamblador, y algo de C.

Hubo 2 revisiones de la placa original en cualquier caso, que mejoraban el audio y las capacidades de las FPU/Co-procesadores para datos en coma flotante, entre otras cosas.

No sé yo si por ejemplo virtual cop y HotD aproveche en demasía las especificaciones del Model 2,el primero se le puede perdonar ya que creo que es el segundo juego que salió para la placa (Daytona USA fue el primero y me parece que la aprovecha mejor),pero HotD salió en su tercera revisión, y son juegos sobre railes, que lo que se dibuja en pantalla esta prefijado y más que controlado.

Salud.

¿Como va el sdk libre?, tengo curiosidad hasta donde se ha llegado ya.Supongo que los mas dificil serian los 3d por la primitiva forma de funcionar de la época,¿me equivoco?

Me estoy dando cuenta que para cuando terminen la librería si facilita el trabajo en N64 y además consigue un 30-40% mejor de rendimiento es posible que veamos juegos de la scene nuevos. Puede que incluso en cartuchada como Megadrive y Snes. Yo voy a ir ahorrando

Calculinho escribió:Me estoy dando cuenta que para cuando terminen la librería si facilita el trabajo en N64 y además consigue un 30-40% mejor de rendimiento es posible que veamos juegos de la scene nuevos. Puede que incluso en cartuchada como Megadrive y Snes. Yo voy a ir ahorrando

Claro, por eso estoy yo preguntando de vez en cuando a BMBx64 cómo va la cosa... y además me gustaría poder trastear cuando esté disponible!
Pero sobre todo quiero poder ver de qué es capaz la 64 con una librería en condiciones.

Seguro que lo primero en llegar son ports... Castlevania SOTN? FF VII ?

@bluedark el problema que veo a esos juegos es que aunque consigan que N64 doble su polycount seguimos con la estupida barrera de los 64mb por juego. Con FFVII imagino que se podría crear un save al final de lo que era cada disco e ir cargando partida en dos o tres roms, por lo que se ha dicho aquí, teóricamente los tres CD con compresión y cuatro cambios ocuparían unos 68mb o algo así.

SotN no tengo ni idea, gráficamente no creo siquiera que haga falta una librería vitaminada para hacerlo, más allá de que sea más o menos fácil hacerlo claro. Pero la música ¿Cómo va? En FFVII dijeron que era midi y esa era la gran ventaja para meterlo en un cartucho, pero en SotN no tiene pinta de ser midi ¿no?

Pero por soñar que no quede, aunque a mi me gustaría más juegos nuevos propios para N64 como hacen con Megadrive o Dreamcast (RPG por favor)

Calculinho escribió:@bluedark el problema que veo a esos juegos es que aunque consigan que N64 doble su polycount seguimos con la estupida barrera de los 64mb por juego.

Hombre, siempre puedes meter un mapper en el cartucho y ampliar el tamaño de la rom.


Pero doblar el rendimiento actual me parece demasiado optimista teniendo en cuenta lo leído. Vamos, 300k polígonos por segundo a 15fps es una salvajada que se me antoja impensable.

¿O me he perdido algo?.

@Señor Ventura por lo que han comentado en este hilo, eso que comentas es lo que hacen los cartuchos de 64mb. Tienen dos roms de 32mb con un chip que dirige.

Creo que esperan rascar un 20% de rendimiento con todo activado como ordenaba Nintendo. Pero Sexy y yo nos venimos arriba y dijimos que quitasen los filtros y el Z-buffering y que hicieran un juego con las mismas reglas que PSX y ahí se me fue a mi la pinza y dije que un 30-40% más

Señor Ventura escribió:Hombre, siempre puedes meter un mapper en el cartucho y ampliar el tamaño de la rom.

El 64drive permite a la N64 acceder directamente a la tarjeta SD a nivel de sectores LBA y tambien puede hacer DMA entre la SD y la RAM interna del cartucho. Me imagino que el ED64 hará algo similar.

Con eso y los 242MB tienes todo el "mapper" que quieras.

Calculinho escribió:por lo que han comentado en este hilo, eso que comentas es lo que hacen los cartuchos de 64mb. Tienen dos roms de 32mb con un chip que dirige.

No se si todos los cartuchos de 64 vienen en 2 chips de 32, pero desde luego no se acceden con bank-switching si no que toda la ROM está mapeada directamente al PI, cada chip respondiendo en el rango de direcciones apropiado... o quizá algun sistema de intercalado, aunque lo dudo.

@radorn la traducción al castellano es que podemos hacer juegos de 242mb máximo no? Usando compresión ¿350?

Calculinho escribió:@Señor Ventura por lo que han comentado en este hilo, eso que comentas es lo que hacen los cartuchos de 64mb. Tienen dos roms de 32mb con un chip que dirige.

Creo que esperan rascar un 20% de rendimiento con todo activado como ordenaba Nintendo. Pero Sexy y yo nos venimos arriba y dijimos que quitasen los filtros y el Z-buffering y que hicieran un juego con las mismas reglas que PSX y ahí se me fue a mi la pinza y dije que un 30-40% más

Eso iba a haber dicho en tu anterior comentario, pero al final se me pasó... que el restaras un 50% a esas expectativas para acercarse mas a lo que creo que esperaba conseguir bmbx64.

Si pueden lograr 180.000 polígonos a 30fps ya me parecerían cifras que aplastan a la competencia, otra cosa es que a ojos de hoy apenas notemos la diferencia entre 130k y 180k polígonos xD

Estaríamos hablando de unos 50.000 polígonos por segundo de diferencia, que a 30fps apenas da para dibujar una escena con 1700 polígonos mas.

Lo que realmente me hubiera gustado es saber hasta donde podría haber llegado la bestia desencadenada que iba a haber sido la nintendo 64 originalmente.

@Calculinho
242MB es lo maximo que ofrece el 64drive como almacenamiento ROM directamente accesible por el memory mapper de la consola. Pero con el acceso por LBA a la tarjeta SD es como si tuvieras un 64DD de 32GB o mas.
Eso da para hacer streaming de video con un buffer o para lo que quieras basicamente.
La CPU de la N64 puede leer directamente la SD por LBA, o puede pedir transferencias desde la SD a la RAM de la consola o pedir DMA desde la tarjeta a la RAM del cartucho que se usa para emular la ROM.
Puedes hacer cualquier cosa con eso.
Si te quieres limitar unicamente a la capacidad ROM, entonces son 242MB con el 64drive (o 64 con el modelo antiguo). Pero con la SD, tienes gigas y gigas de FAT32

Si ya hablamos de hacer repros, tienes como minimo 256 de rango de memoria por PI, y, posiblemente mas, pero eso fue un debate que tuvimos EMaDeLoC y yo hace unas semanas y no llegamos a ninguna conclusion solida.
La cuestion es que, aunque en un repro puedas meter 256, ninguna herramienta de desarrollo disponible soporta tanto actualmente, Lo maximo que hay en el mercado es el 64drive con sus 242

@Señor Ventura depende en que uses los polígonos ¿No era la N64 que por culpa de su problema con las texturas para pintarte el suelo o paredes de un escenario usa más polígonos que PSX? Me suena algo de comparativas donde PSX puede poner poligonos más grandes y texturizados y N64 para lo mismo tenía que usar parte de su potencial en poner más poligonos pequeños.

Pero bueno, una cosa es que un chaval que nació en 2005 no lo note. Yo creo que aquí todos notamos la diferencia entre un juego de 80k a uno de 120k. No sé los polycounts de los juegos de esa gen, pero vamos que yo noto Mario 64 mucho más "cuadrado" poligonalmente hablando que no Banjo o Conker's.

@radorn te iba a decir que con 242mb ya ibamos bien, pero con 32GB salvo que quieras reproducir una telenovela en FMV a 640x480 creo que sobra bastante.

En su momento se barajó calzarle a la Nintendo 64 un R-4400 a 150 Mhz gobernando la placa, pero el precio se salía de madre.

De cualquier forma ya sabemos que "simplemente" cambiándole la RAM por una más apropiada, y redistribuyendo sensatamente el DMA, de entradas obtendríamos el DOBLE (o casi) de ancho de banda para la GPU, y reduciríamos las latencias desde la CPU, siendo esto último lo que más lastra a la consola en materia de frame-rate.

A partir de ahí ya sería fantasear con otra CPU y la cantidad de memoria asignada, ya que el chipset gráfico de la consola nunca cambió, simplemente se fué actualizando reduciendo su tamaño/coste y comunicaciones sobrantes. Si acaso siendo sibaritas podríamos aumentarle la caché de texturas.

Calculinho escribió:¿No era la N64 que por culpa de su problema con las texturas para pintarte el suelo o paredes de un escenario usa más polígonos que PSX? Me suena algo de comparativas donde PSX puede poner poligonos más grandes y texturizados y N64 para lo mismo tenía que usar parte de su potencial en poner más poligonos pequeños.

Es justamente al reves. En la mayoria de juegos de PS1, a causa de su mapeado de texturas sin perspective correction, para minimizar la distorsion de las texturas, el motor está diseñado para subdividir los poligonos originales a medida que la camara se acerca para intentar mantener el mismo aspecto que de lejos.

@radorn entonces cual era el problema con las texturas de N64 y que hacían para paliarlo?

@Calculinho Yo creo que lo has dicho bien.

La psone necesita muchos polígonos para paliar el temblequeo por no poder aplicar la corrección de perspectiva, y a la n64 le vienen bien muchos polígonos para simular texturas mas grandes y detalladas.

La verdad es que 250.000 polígonos para simular un entorno de 80.000 le daría un acabado a las texturas muy, muy bruto. Texturas tres veces mas grandes, tres veces menos repetidas, y tres veces mas detalladas.

Pero claro, llegar a 250k es una quimera, ni a 15fps creo yo.

El problema principal de las texturas de N64 es que el cartucho es pequeño y no da para meter comodamente tantas ni tan grandes como quisieras, y, en segundo lugar, que el proceso de renderizado necesita que toda la textura esté metida de una tacada en una pequeña cache de 4K del RCP llamada TMEM (Texture MEMory). Si, además, usas efectos como el TLMMI, y texturas paletizadas de 8 bit, que es la combinacion mas comun, el tamano de textura se ve reducido a la mitad debido a que esas dos caracteristicas tambien ocupan memoria en al TMEM (el indice de colores o paleta y los mipmaps de la textura).

Aquí entra una cuestion de la PS1 para la que aun no he encontrado una explicacion clara, porque la PS1 tiene 2K de texture cache, y sin embargo, de alguna forma extraña, muchos juegos usan texturas mas grandes sin demasiado problema. No se muy bien como va el tema, pero QUIZÁ se deba a que la GPU tiene su propia memoria dedicada y puede leer texturas en 2 pases? no lo se.

Señor Ventura escribió:y a la n64 le vienen bien muchos polígonos para simular texturas mas grandes y detalladas.

Ah, os referis a eso... bueno, si, el tamaño por textura puede ser problematico, y, en ciertas ocasiones, se recurre a usar multiplex texturas a modo de baldosas para completar una superficie con mucho detalle. Pero tampoco es algo que se haga mucho por la cuestion de la capacidad del cartucho.
De todas formas, al menos en este aspecto, yo creo que sale mejor parada N64 que PS1.

radorn escribió:El problema principal de las texturas de N64 es que el cartucho es pequeño y no da para meter comodamente tantas ni tan grandes como quisieras, y, en segundo lugar, que el proceso de renderizado necesita que toda la textura esté metida de una tacada en una pequeña cache de 4K del RCP llamada TMEM (Texture MEMory). Si, además, usas efectos como el TLMMI, y texturas paletizadas de 8 bit, que es la combinacion mas comun, el tamano de textura se ve reducido a la mitad debido a que esas dos caracteristicas tambien ocupan memoria en al TMEM (el indice de colores o paleta y los mipmaps de la textura).

Aquí entra una cuestion de la PS1 para la que aun no he encontrado una explicacion clara, porque la PS1 tiene 2K de texture cache, y sin embargo, de alguna forma extraña, muchos juegos usan texturas mas grandes sin demasiado problema. No se muy bien como va el tema, pero QUIZÁ se deba a que la GPU tiene su propia memoria dedicada y puede leer texturas en 2 pases? no lo se.

Claro, por eso si usas 4 polígonos en lugar de 1, puedes dividir una textura mas grande y detallada en 4 partes, y hacer el proceso en 4 pasos.

Es un gasto de recursos, pero funciona, y se pueden conseguir texturas muy bestias, por eso un alto conteo de polígonos ayuda en ese sentido.

Los 4KB de la caché de texturas está dentro del propio RCP, ¿no?. Menudo fallo, si fuese externo podrían haber puesto una memoria mas grande... mas lento, pero compensaría sobradamente a tener que malgastar decenas de miles de polígonos para poner texturas mas grandes divididas en trozos mas pequeños.

radorn escribió:Aquí entra una cuestion de la PS1 para la que aun no he encontrado una explicacion clara, porque la PS1 tiene 2K de texture cache, y sin embargo, de alguna forma extraña, muchos juegos usan texturas mas grandes sin demasiado problema. No se muy bien como va el tema, pero QUIZÁ se deba a que la GPU tiene su propia memoria dedicada y puede leer texturas en 2 pases? no lo se.

No, eso es porque si el chip gráfico de la PlayStation no encuentra la textura en la caché puede pasar a leerla desde la página de texturas de la VRAM sin ninguna pérdida de rendimiento.

En cambio la N64 para procesar las texturas tiene que leerlas casi exclusivamente desde la caché, ya que el Texture Filter cuando ejecuta el filtrado bilineal necesita 4 accesos a la memoria por pixel para procesar, y teniendo en cuenta que el PUTO Z-BUFFER siempre está por ahí, si tuviese que leerlas directamente desde la ram externa el fillrate se asfixiaría todavía más.

Por eso yo soy ANTI de los filtros/buffer Z en en juegos tipo shooter, lucha, carreras; y lo que más me atrae de la scene de este sistema es ver a la Nintendo 64 liberada de cadenas y deberes "cosméticos", y ver lo que da de sí en rendimiento bruto y puro.

@Señor Ventura 15 fps en N64 es un juego fluido y disfrutable de sobra para muchos. En este mismo subforo se me ha dicho a mi que Hybrid Heaven en hi-res es perfectamente jugable y disfrutable y en los mejores casos va a 13fps con amplias caídas: https://youtu.be/QENacgOs2XU?t=7m50s

Así que ponle el polycount que quieras a 10fps estables. Esas serías las normas de N64 en la época, mucho polígono bonito, la fluidez es de pijos pixelados.

Calculinho escribió:la fluidez es de pijos pixelados.

Y de Peceros jugando en software rendered a 60 fps y 480p.

Viva el Quake sin filtros pastosos joder.

Calculinho escribió:@Señor Ventura 15 fps en N64 es un juego fluido y disfrutable de sobra para muchos. En este mismo subforo se me ha dicho a mi que Hybrid Heaven en hi-res es perfectamente jugable y disfrutable y en los mejores casos va a 13fps con amplias caídas: https://youtu.be/QENacgOs2XU?t=7m50s

Así que ponle el polycount que quieras a 10fps estables. Esas serías las normas de N64 en la época, mucho polígono bonito, la fluidez es de pijos pixelados.

¡Y que la 64 no se ve así de nítida cojones!

Dejad de hypear a la gente con vídeos de emulador.

@Señor Ventura Creo que estamos exagerando un poco con este asunto de los embaldosados. Ayudar al rendimiento no ayuda. Eso está matematicamente claro, pero tampoco creo que sea para tanto el tema.
Si la PS1 puede permitirse subdividir todo poligono viviente por proximidad, la N64 se puede permitir algun que otro embaldosado. Tampoco hay que ponerse paranoicos.

Lo de los 4K embedidos en el RCP es lo logico. Una cache interna siempre va a ser mas rapida que una externa.

@Sexy MotherFucker
http://problemkaputt.de/psx-spx.htm#gpuvideomemoryvram
Entre esa y la siguiente seccion sobre la cache de texturas, no acabo de aclararme como se pueden usar texturas de mas de 2K, que prarece que muchos juegos usan.
Tu dices que no hay penalizacion en leer de la VRAM directamente, pero ahi dice que si, y si no hubiese penalizacion, tampoco veo para que poner la cache en primer lugar.
La cuestion es que la textura mas grande que cabe en la cache de texturas de PS1 segun ese documento es 64x64 4bit. Pero yo juraria que he visto texturas mas grandes. Como leches se come eso?
Tengo vagos recuerdos de posts a medias sobre paginado y lecturas concurrentes o que se yo. Nunca he acabado de tenerlo claro.

Lo de quitar los filtros y tal, sin duda. Hay que experimentar mucho y encontrar combinaciones que maximicen el rendimiento y la nitidez, aplicando solo aquellos procesos que "salgan gratis" o aporten mucha ventaja con muy poco sacrificio.
Y ya luego hacer un crowdfunding para reunir a los mejores sceners durante un par de años y hacer un super motor middleware y algun jueguillo de ejemplo xDDDDD y que lo llamen... ¡Ultra Engine!

@radorn y aparte de eso pensar siempre con el expansion-pak ON.

P.D:

VRAM

La VRAM tiene el mismo ancho de banda que la RAM principal, unos 66.7 MB/seg. Esta compuesta como si se tratase de un enorme búfer de imagen de 1024×512 pixeles y 16 bits (2 bytes) por pixel (1MB). Se trata de una RAM de doble puerto como la de 3DO por lo que mientras se esta escaneando la imagen ya generada para ser enviada al televisor se esta renderizando la siguiente en otra parte de la memoria. La diferencia respecto a 3DO es que la VRAM es ahora memoria origen y memoria destino para no parar a la CPU por lo que es necesario cargar todos los datos necesarios para los gráficos a la VRAM antes de empezar a renderizar la escena.

Dichos datos se almacenan en forma de página de texturas. Cada página de texturas tiene un tamaño de 256×256 pixeles con una información de 4, 8 o 16 bits por pixel (este último es de 15 bits+1 bit para marcar si el pixel es transparente/no se dibuja). Esto hace que el tamaño que ocupan las páginas de texturas sea variable dependiendo de la información que almacene cada una de ellas. La información y el número de paginas de texturas que se puedan almacenar en memoria dependerá directamente de la memoria libre que le deje el búfer de imagen.

https://disruptiveludens.wordpress.com/ ... aystation/

La ventaja de PlayStation respecto a N64 es que si no encontraba la textura en la cache de texturas entonces se ponía a leerlas de la página de texturas de la VRAM sin perdida de rendimiento alguno.

https://disruptiveludens.wordpress.com/ ... intendo64/

@Sexy MotherFucker OK, o sea que basicamente es una cache transparente automatica al estilo mas clasico, no como la TMEM de N64 que hay que administrarla manualmente por software/microcodigo, diciendole "ahora carga tal o cual"

Supongo que esa cache realmente solo ayuda con texturas "pequeñas" al estilo de las de N64, pero si intenta usar mas, al final, durante el renderizado de un poligono, va a tener que acceder a la VRAM igualmente, perdiendo la ventaja de rendimiento de la cache.

Me pregunto si la TMEM del RCP tambien puede actuar como cache automatica, claro que me imagino que eso dañaría aun más el rendimiento a causa de ser memoria unificada, con bus de 8-9bit, alta latencia, y sin dual-porting... ains...

por cierto, muy buenos enlaces me pasas. lastima que las imagenes estén caidas.

Sexy MotherFucker escribió:Por eso yo soy ANTI de los filtros/buffer Z en en juegos tipo shooter, lucha, carreras; y lo que más me atrae de la scene de este sistema es ver a la Nintendo 64 liberada de cadenas y deberes "cosméticos", y ver lo que da de sí en rendimiento bruto y puro.

Decir que eres anti Z buffer, es como decir que eres anti 256 colores en pantalla, o eres anti sprites en juegos 2D, o que se yo, que puta locura nen.

@Dio_Brand
No es tan descabellado como crees, ni mucho menos tampoco.
Se abusó del Z en N64 porque venia de serie, y de otras muchas cosas.

En PS1, el crash kart implementó un zbuffer por software de alguna manera, limitado al agua en ciertas fases para lograr el efecto de ver parcialmente sumergido a tu personaje.

Se puede hacer mucho sin Z y ahorrar mucho, y luego implementarlo parcialmente para algunas cosas

Es todo cosa de ingenio y equilibrar las distintas tecnicas

El Z es como muy universal y facil, pero, si no lo necesitas, consume mucho para nada

@radorn PSX con z-buffering? ¿¡Qué será lo siguiente un juego de PSX con filtro de suavizado?! QUIERO MIS PIXELOTES!

radorn escribió:@Dio_Brand
No es tan descabellado como crees, ni mucho menos tampoco.
Se abusó del Z en N64 porque venia de serie, y de otras muchas cosas.

En PS1, el crash kart implementó un zbuffer por software de alguna manera, limitado al agua en ciertas fases para lograr el efecto de ver parcialmente sumergido a tu personaje.

Se puede hacer mucho sin Z y ahorrar mucho, y luego implementarlo parcialmente para algunas cosas

Es todo cosa de ingenio y equilibrar las distintas tecnicas

Crash kart team racing disimuló el tembleque gracias a un truco en las texturas del escenario y los modelados de personajes, pero si la maquina de Sony hubiese tenido Z-Buffer de serie como N64 se hubiese usado sin pensarlo, imaginate el ahorro de tiempo + costes + virgerias ingeniosas.

Que me digas esto de otros efectos de la maquina que comen mucho y no ayuda al resultado final, pues mira... ¿Pero el Z-Buffer? Si es una "herramienta" que es basica a dia de hoy y se sigue utilizando en los juegos modernos porque es como el ABC de las 3D.

Edit: Es como si me cojes una Super Nintendo y me dices "Bue, poner 256 colores en pantalla es innecesario y come muchos recursos, esto lo apaño yo con 64 colores y un poco de dithering aquí y alla, total seguro que da el pego..." No tiene sentido infrausar el hardware de la maquina con efectos y/o capacidades tan basicas y qué aportan tanto.

Claro que hay perdida de rendimiento, la idea de tener la textura en cache es para no leerla de memoria cada vez que tenga que utilizarse.

De la misma forma que no es lo mismo componer una sala de 3 texturas que de 50.

@Flash-Original
Está la cosa un poco parada, hoy precisamente iba a ponerme un rato, pero marathon no actualiza su github desde marzo, krom anda liado haciendo cosas.

Supongo que en algunos días podré poner novedades.

@Dio_Brand el z-buffering no tiene casi impacto en el framerate? Creía que era lo que más lastraba.

Dio_Brand escribió:Decir que eres anti Z buffer, es como decir que eres anti 256 colores en pantalla, o eres anti sprites en juegos 2D, o que se yo, que puta locura nen.

Decirme esto es olvidarse que estamos en un hilo de Nintendo 64.

@Calculinho Pues creo que los Tekken y/o algun otro juego de lucha implementan perspective correction para el suelo, que al estar tan inclinado con respecto a la camara, se benefician mucho de el. Lo siento xD

@Dio_Brand No se que crees que tiene que ver el tembleque de texturas con el Z-Buffer, pero yo no lo veo.
Yo del z-buffer no he dicho que no aporte nada. Solo digo que, habiendo aprendido un poco (poco) a lo largo de los años, he visto que muchas situaciones y algunos juegos enteros de N64 podrían haberse hecho casi enteramente sin usar Z-buffer y hubieran ganado en rendimiento. No hablo tanto de juegos de la mas alta factura si no de juegos del monton que simplemente usaron las opciones por defecto y no se preocuparon demasiado por ajustar las cosas. Tampoco les culpo, porque sus motivos tenian, pero es un hecho que en muchos juegos se hizo así pudiendo haberse prescindido de el.
Creo que el WDC es un ejemplo de juego apreciado que no usa Z, asi que ya me dirás tu...

Como dices, es una herramienta, y como tales, no todas las herramientas son las mejores para todos los trabajos, ni todos los materiales son los mas indicados, tanto por caracteristicas como por coste. El Z-Buffer sencillamente es caro, consume mucho, y si bien yo no abogo por una abolicion universal, si creo que su aplicacion universal y sin discriminacion no es necesariamente la mejor opción.
Creo que se podría exprimir mucho la maquina probando a prescindir de el.

Sexy MotherFucker escribió:

Dio_Brand escribió:Decir que eres anti Z buffer, es como decir que eres anti 256 colores en pantalla, o eres anti sprites en juegos 2D, o que se yo, que puta locura nen.

Decirme esto es olvidarse que estamos en un hilo de Nintendo 64.

Qué dios te guarde la vista.

@Dio_Brand lo dicho, ni idea de lo que hablas, ni del contexto del hilo.

Resulta que BMBx64 ya ha comentando varias veces como el Z-Buffer penaliza mucho en la Nintendo 64 debido a la pésima elección de RAM (Rambus) del sistema, reduciendo el ancho de banda a prácticamente la mitad de la mitad que de haber usado SDRAM cuando se emplea el buffer de profundidad. Muchos desarrolladores lo implementaban les hiciese falta o no, sin pararse a pensar si realmente necesitaban usarlo, o qué podían ganar no usándolo, y debido a ello gran parte del catálogo de la consola tiene un pésimo rendimiento en según qué géneros comparativamente hablando con PlayStation.

En cambio compañías como Boss Game Studios lo desactivaban porque les estorbaba más que les ayudaba cara al rendimiento, y por eso juegos como World Driver Championship consiguen los más altos polycount del sistema con una buena tasa de frames por segundo (130k @ 32-33 fps):

https://www.youtube.com/watch?v=sBUhDrnVvdg

Por eso yo en Nintendo 64 para los juegos de carreras, lucha, y cualquiera con un entorno controlable si necesidad de buffer de profundidad, soy anti Z-Buffer y anti cualquier filtro innecesario que reste rendimiento y/o ocupe valioso espacio en memoria; porque prefiero ganar tasa de relleno y reducir algo la latencia para así tener entornos más recargados de polígonos, moviéndose a más velocidad. No se trata de ser "anti" tecnología, sino de conocer los límites de un sistema y conjeturar en base a ello.

Y por eso si estuviésemos hablando de la Ps2 diría justo lo CONTRARIO, ya que este sistema sufre de un sobredibujado galopante, necesitando buffers de profundidad bien medidos como el comer. Si estuviese hablando de la Dreamcast diría que no necesita nada, pero no por nada, sino porque es un tile-render, etc.

Lo que pasa es que claro; poner gif jocosos habiendo leído una frase sin tener ni puta idea del contexto sale gratis, y luego el patinaje artístico es de medalla olímpica

@Sexy MotherFucker no te enfades Sexy, no ves que si renuncian al Z-buffering les queda la consola coja. Lo importante no son los juegos o que funcionen bien, lo importante es poder decir que usan "nombres molones": BLAST PROCESSING, TILEMAP SCALING, EMOTION ENGINE, PIZZA CON PIÑA!

Edit: Aprovecho para preguntar, especialmente a @radorn, si sabemos que el Z-buffering por hardware de la consola usándolo mal lastra tanto el framerate y que PSX lo usaba por software para determinadas cosas. Teniendo en cuenta que en fuerza bruta de CPU N64 es superior ¿No ganaría más implementándolo directamente por software y así descargando el ancho de banda de la RAM para otras cosas?

@Calculinho no me he enfadado, es sólo para que a la próxima @Dio_Brand reflexione antes de cargar contra alguien frontalmente cuando no sabe de lo que el otro está hablando. El chaval me cae de puta madre, y por eso me he molestado en explicarle mi punto. Si me hubiese caído mal o algo, directamente le ignoro