Hilo de detalles y curiosidades de N64

@Diskover con este programa: https://gbatemp.net/threads/n64noaapatc ... ms.590245/

SuperPadLand escribió:

Señor Ventura escribió:@EMaDeLoC Si que parece haber una diferencia de resoluciones también, ¿no?. A tenor de los jaggies en las piernas de claire en el vídeo, diría que la ps1 funciona a 320x240, y la n64 a 640x480.

En N64 nada funciona a 640x480, excepto Chess64 y algún que otro menú. El RE2 sin expansion pak va a 320x224 y las FMV a 240x117. En PS1 son 320x240 para todo. Con expansion pak en N64 sube la res en algunos fondos, no en todos, alternando entre cinco res diferentes, la alta más habitual 362x214.

El juego in-game con mayor resolución, aparte del Chess, o al menos uno de ellos, sería Hybrid Heaven a 576x448, pero con un rendimiento de 5-14fps.

El que menos F-Zero a 296x208, pero 60fps.

Fuente: Este hilo.

https://www.reddit.com/r/Games/comments ... games_ran/

Falkiño escribió:Pues perdona, es que recuerdo leérsela a él también y me quedé con ella

Tranquilo, si luego de que yo se lo comentara él iba confirmando que así era al verlo en otras plataformas. Es normal la confusión.
En la naturaleza de los CRT si emborronas un poco la imagen el pixel de baja resolución desaparece y parece que las imágenes son de mayor resolución. El mejor ejemplo lo tenemos con los vídeos de PS1, que estan a 320x240 y se ven de lujo en un CRT. Míralos en un PC y se te caen los ojos. Con la N64 buscaban el mismo efecto y dependiendo del juego se consigue.

@Señor Ventura Según un análisis de Conker en este post, 362x214.
El juego salta muchas veces de vídeo progresivo a entrelazado y viceversa. Como RE2 no es muy exigente en modelados, se aprovechará el entrelazado para subir un poco la resolución de forma artificial según el escenario. Pero habría que hacer un análisis en profundidad de esto.

EMaDeLoC escribió:

Sogun escribió:En este tipo de juegos sí que se echa en falta que la caché sea más grande para tener texturas de 64x64 a 16 colores con todos los filtros activados y poder repetirla como patrón en superficies para suelos.

Pero si sí que se puede ir a 64x64 a 16 colores:
64x64x4bits/8bits(1byte)=2048 bytes, más los otros 2KB para la paleta.
¿Lo de 32x32 no será un límite de los motores de los juegos que mencionas?

Me refiero a tener texturas de ese tamaño (64x64) con filtrado trilineal. Ya he explicado que es un caso concreto para texturizar suelos en juegos en primera persona donde quieres que las texturas tengan algo de detalle. Se puede conseguir actualmente con texturas en escala de grises que sirven muy bien para simular construcciones en hormigón o similares. Y se puede adaptar para otros materiales pintando los vértices de los polígonos con las texturas en escala de grises. Para juegos con cámara en tercera persona no supone tanto problema las opciones que da la N64.

16 colores son suficientes si puedes elegirlos. El 99% de las texturas de Perfect Dark son de 16 colores. Sólo las caras de los personajes y puede que alguna textura suelta son de 256 colores. Pero en escala de grises de 4 bits no puedes hacer eso: estás limitado a 16 intensidades predeterminadas y espaciadas de forma equidistante en el espectro. Tienes casi blanco, 4 tonos claros, 6 tonos intermedios, 4 tonos oscuros y negro. No puedes usar las 16 intensidades en tonos oscuros para hacer un degradado disimulando las transiciones de color.
Me viene a la cabeza una persona que estaba creando personajes para Perfect Dark y había creado unas texturas impresionantes para un esmoquin en escala de grises. Las había dibujado con su propia paleta de 16 intensidades y todas las transiciones eran perfectas, pero al importarlas a la rom la tonalidades se adaptaban a los "saltos" de intensidad y la textura acababa destrozada. -> hilo de shootersforever en cuestión.
Y una textura en escala de grises pintada por vértices queda muy plana en comparación con lo que se puede conseguir variando un poco los tonos.

Si quieres representar algo un poco complejo como un empedrado y quieres evitarte el amasijo de píxeles bailones que supone la falta de filtro trilineal, ya estás en apuros. Pongo como ejemplo imágenes de una prueba de un mapa de Counter Strike que ya publiqué en este hilo, pero que sirve para ilustrar a lo que me refiero. Las pongo en secreto porque son imágenes grandes. Hay que fijarse en la textura del camino, aunque en el resto de texturas del escenario también pueden apreciarse cosas que he mencionado arriba.


Todas las texturas son versiones reducidas de la textura original de 256x256 a 256 colores.
En la primera imagen la textura es de 64x64 a 16 colores y aunque es evidente la pérdida de detalle se pueden diferenciar las distintas piedras. Pero esta textura se pixela a media distancia por la falta de filtros y puede llegar a ser molesto. Este baile de píxeles hace que llegue un punto en que es imposible ver qué está representando la textura.
En la segunda imagen la textura es de 32x32 a 256 colores. Ya no se diferencian las piedras y sólo se aprecian borrones. Ni siquiera se llega a apreciar que tenga más colores que en el anterior caso porque los tonos son muy parecidos. Esta textura tiene filtros, pero la textura nativa ya es borrosa así que se pierde cualquier detalle a media distancia.
En la tercera imagen la textura es de 64x64 en escala de grises a 4 bits (16 tonos como máximo) y pintada como mejor pude para asemejar los colores originales, pero no encontré la forma. Tendría que haber retocado la textura porque después de transformarla no tenía intensidades de gris cercanas al blanco y cualquier color que probara se oscurecía demasiado. La textura ni siquiera tiene 16 tonos de gris sino 14. Le faltan los dos más claros. No se pixela y mantiene detalle en la distancia, pero es muy fea de ver.


En estos casos en concreto es donde digo que hubiese hecho falta una caché más grande. Porque necesitas ese tamaño de textura para representar algo de detalle, pero no puedes apreciar ese detalle porque la falta de filtros te revuelve la textura.

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

Del caso que estáis comentando del Resident Evil2 y las diferencias de texturas con sus ventajas e inconvenientes.. hay en este hilo una captura comparativa de @conker64 hecha sobre harware real y buena salida de vídeo. Ahí se demuestra que la versión de Nintendo 64 gana por goleada porque la resolución de la pantalla es demasiado pequeña para las texturas tan grandes de PS1. La falta de filtros, corrección de perspectiva y precisión subpixel hacen invisibles los detalles de las texturas de mayor resolución. A ver si alguien rescata la captura.
Y también sería otro ejemplo de lo importantes que pueden llegar a ser los mipmaps, aunque en esta comparativa hay más cosas a tener en cuenta.

También la problemática que tienen el tema de las texturas, aparte de todo lo que dices, es que por lo que yo entiendo, para hacer TriLinear Mip Mapping, hace falta que dibuje en modo 2 cycle, lo cual ya lastra el rendimiento.
Lo que no tengo muy claro, es si una vez que activas el 2 cycle para pintar X superficie, tiene suficiente tiempo para hacer varios efectos que sólo se puede hacer en ese modo o si hace falta otra pasada, por ejemplo:
El modo 2 cycle se tiene que activar si quieres estos efectos:
- Trilinear Mip Mapping.
- Doble textura.
- Enviroment mapping.
- Mezcla de vertex color pintado en polígonos y una fuente de luz.
- ¿Niebla?
@Conker64, tienes idea si se pueden hacer varios efectos de este tipo en ' una pasada" de 2 cycle, del tipo, TLMM y doble textura o mezcla de vertex color y fuente de luz y doble textura.
Salud.

@Sogun de las tres fotos que has puesto ¿Alguna tiene impacto en el rendimiento del juego o daría igual? Si la respuesta es afirmativa yo elegiría la que menos lastre el rendimiento, en caso contrario elegiría la primera suponiendo que la N64 se vaya a usar en CRT y con cable compuesto, sino la tercera que aunque dices que es oscura y luce mal, a mi más bien me parece que luce diferente; pero no mal. No creo que hubiera sido un problema recibir una versión de Counter Strike en N64 con esa calidad y tonalidad.

Sogun escribió:Me refiero a tener texturas de ese tamaño (64x64) con filtrado trilineal.

Vale, me ha costado pero ya te entiendo. Te refieres a tener una textura con paleta personalizada con la que puedas usar mipmapping, que estás confundiendo en tu post con filtrado trilineal.

Por si alguien se pierde:
El mipmapping consiste en reducir una textura en sucesivas mitades y usar cada tamaño dependiendo de la distancia y ángulo de la cámara:

Eso consigue que a la distancia se suavicen los píxeles y la perspectiva quede más natural
Sin mipmapping:


Con mipmapping:


También evita el moaré en ciertas circunstancias:


El filtrado trilineal permite fusionar los mipmaps para que no se noten saltos en la texturas:
Filtro bilineal a la izquierda, trilineal a la derecha:


El filtrado trilineal es un cálculo que hace la GPU y no ocupa espacio, pero los mipmaps son texturas que se han de guardar en alguna parte para poder usarlas.
En el caso de la N64, de los 4KB de caché (TMEM), cuando se activan los mipmaps se divide en dos quedando libres 2KB para la textura y el resto para guardar los mipmaps.

El problema que señala Sogun es que cuando se usa un modo de color de una textura con paleta, tambíen la caché se divide en dos y se usan 2KB para guardar la paleta de color. Como no se puede usar la misma memoria para dos cosas distintas, o usas texturas de menos resolución con mipmapping, o texturas de mayor resolución con problemas de moaré en la distancia.

Aclarado esto, creo que la mejor solución no es doblar la caché, que habría supuesto un problema técnico considerable al ocupar 4KB de TMEM un buen cacho del RDP. La solución ideal habría sido crear un espacio para las paletas de las texturas. Además habría sido relativamente barato, pues 256 x 16bits de color (RGBA) = 512 bytes. De esta forma se podría usar los 4KB y tener texturas con paletas de 16 de hasta 90 x 90 o con paleta de 256 colores de 64x64, en vez de 64x64 y 48x48 respectivamente.

Pero habiendo lo que hay y como no se puede rehacer la consola, ahora lo que toca es trabajar y hacer pruebas. Es parte del trabajo del artista y diseñador de niveles, sabiendo las limitaciones de las texturas y el mipmap, usar las técnicas adecuadas en cada momento. Por ejemplo, crear los pasillos con cierta profundidad para usar texturas de 64x64 que no requieran de mipmapping.

Sogun escribió:Me viene a la cabeza una persona que estaba creando personajes para Perfect Dark y había creado unas texturas impresionantes para un esmoquin en escala de grises. Las había dibujado con su propia paleta de 16 intensidades y todas las transiciones eran perfectas, pero al importarlas a la rom la tonalidades se adaptaban a los "saltos" de intensidad y la textura acababa destrozada. -> hilo de shootersforever en cuestión.
Y una textura en escala de grises pintada por vértices queda muy plana en comparación con lo que se puede conseguir variando un poco los tonos.

Por lo que leo parece un problema con el programa para convertir al formato de N64.
Con la parte superior del smokin parece que el problema es que ha recortado los hombros en la propia textura con un alpha, y al hacer eso la textura ha de convertirse en Intensidad-Alpha y no en solo Intensidad, y al meterle alpha automaticamente pasa de 16 a 8 colores.
No sé si con la parte de atrás del smokin le habrá pasado lo mismo. Pero también es que me parece que le está pidiendo mucho a la consola o no sabe como manejar el sistema de intensidades. Lo suyo es que si la espalda va a tener un conjunto de grises, que los vertices estén pintados en el gris más claro y mediante las intensidades añadir detalle. Esto requiere ir probando continuamente a compilar un modelo y probarlo en la consola.

Sogun escribió:Tendría que haber retocado la textura porque después de transformarla no tenía intensidades de gris cercanas al blanco y cualquier color que probara se oscurecía demasiado. La textura ni siquiera tiene 16 tonos de gris sino 14. Le faltan los dos más claros.

Pero es que con intensidad trabajas con el color base del vertice y este será el máximo valor de intensidad de ese color. Te vale para poner una textura a un cesped, una pared de cemento o una puerta como el Ocarina of Time (imágenes de Conker de aquí):



Es decir, diferentes tonos de un mismo color. No puedes obtener blancos de unas piedras porque el valor del vertice tendría que ser blanco y los distintos tonos de blanco son grises, no color piedra. Como mucho habría que escojer un tono de piedras muy claro y luego ser creativo con la textura para que parezca un brillo.

Yo sé que lo ideal es que la consola trabajara de otra forma que fuese más cómoda para el diseñador y pudiese dar rienda suelta a su creatividad. Pero también es parte de la creatividad saltarse las limitaciones de una máquina para conseguir resultados que parecían imposibles.

dirtymagic escribió:También la problemática que tienen el tema de las texturas, aparte de todo lo que dices, es que por lo que yo entiendo, para hacer TriLinear Mip Mapping, hace falta que dibuje en modo 2 cycle, lo cual ya lastra el rendimiento.

Correcto. No sé hasta que punto vale la pena insistir en mipmapping trabajando a 240p para verse en un CRT, especialmente para determinadas texturas porque si son de colores parecidos, no se va a notar tanto la pixelación en la distancia.

@EMaDeLoC
Yo tenía entendido que el filtro bilineal sólo actúa cuando la textura ocupa más píxeles en pantalla que su resolución nativa. Si sólo hay filtro bilineal, cuando la textura es más pequeña en pantalla que su resolución original, entonces "se eliminan los píxeles intermedios" y aparecen dientes de sierra y baile de píxeles con los movimientos de cámara.
Por ello el filtro trilineal actúa cuando la textura es más pequeña en pantalla. Se interpolan los distintos niveles de mipmap según el tamaño de la textura en pantalla. Si no se interpolaran dos niveles de texturas entonces tendríamos esos cortes tan bruscos de la parte de la izquierda de tu imagen de ejemplo. Por eso siempre hablo de filtro trilineal y no sólo de mipmaps.
He recordado un vídeo de DF retro sobre el Unreal Tournament donde muestran esa falta de interpolación entre mipmaps pero también lo llaman "bilinear filtering" así que puede que yo tenga el vocabulario confundido, pero creo que son cosas distintas y se ajusta más a como yo lo llamo.

Se me había olvidado comentar de que la caché se vuelve a dividir por la mitad cuando hay que guardar mipmaps, así que en texturas con paleta de colores estamos limitados a 1 kB. Los 4 kB se organizarían de la siguiente manera:
-2 kB para la paleta de colores ¡un despilfarro!
-1 kB para la textura en sí.
-1 kB para los mipmaps de la consola cuando se generan automáticamente. (ocupan bastante menos de 1kB).
Pero si creamos de antemano nuestros propios mipmaps podemos aprovechar los 2 kB que no se gastan en almacenar la paleta de color, pudiendo ganar algo de resolución. Crear nuestros propios mipmaps también puede mejorar su definición en pantalla y evitar algunos artefactos que pueden ocurrir cuando se generan automáticamente.

Tu solución de almacenar la paleta en otro sitio hubiese sido ideal. Podríamos aprovechar los 4 kB de la caché para texturas más grandes (aunque 64x64 me parece adecuado para jugar a 240p) y con más colores. Se podría dejar una misma textura en la caché e ir cambiando la paleta en ciertas situaciones para ganar tiempo de proceso y espacio de almacenamiento y RAM. Unos artistas realmente creativos harían cosas impresionantes con esta posibilidad.



Respecto a la textura del esmoquin, he creado esta imagen que creo que explica muy bien visualmente cómo se realiza el proceso de conversión a textura en escala de grises de 4 bits.

La textura original tiene 16 colores (grises) distintos pero están elegidos como si fuese una textura con paleta de color. Cuando se convierte a IA de 4 bits los colores se adaptan a las 16 intensidades y muchos se quedan en el mismo nivel. La textura final se queda en sólo 8 colores.
Por eso decía en mi mensaje anterior que con 16 colores bien elegidos puedes hacer cosas muy buenas, pero que las texturas en escala de grises de 4 bits te limitan muchísimo aunque luego puedas colorearlas.

EMaDeLoC escribió:

Sogun escribió:Tendría que haber retocado la textura porque después de transformarla no tenía intensidades de gris cercanas al blanco y cualquier color que probara se oscurecía demasiado. La textura ni siquiera tiene 16 tonos de gris sino 14. Le faltan los dos más claros.

Pero es que con intensidad trabajas con el color base del vertice y este será el máximo valor de intensidad de ese color. Te vale para poner una textura a un cesped, una pared de cemento o una puerta como el Ocarina of Time

Me refería a que me pasó algo parecido que con el esmoquin. Al convertir la textura a IA 4 bits, mi intensidad más clara era 208. Por este motivo no supe atinar con el color con el que pintar los vértices para que se asemejara más a la textura original, porque siempre estaba contaminada con un tono grisáceo. Si hubiese alterado el contraste antes de la conversión para tener las 16 intensidades en lugar de 14, seguramente hubiese quedado mejor.

Sogun escribió:Yo tenía entendido que el filtro bilineal sólo actúa cuando la textura ocupa más píxeles en pantalla que su resolución nativa.

La verdad es que no lo sé. Tendría sentido para ahorrar rendimiento, pero Conker hizo una prueba con un juego que le dejaba desactivar el filtrado y el rendimiento era el mismo. Por lo visto le sale gratis. Creo que matematicamente este activado o no el resultado es el mismo si la texturas ocupa menos píxeles en la región de la pantalla que su resolución original.

Sogun escribió:Por eso siempre hablo de filtro trilineal y no sólo de mipmaps.

Ya, pero como dije, el filtro trilineal no te ocupa memoria de la TMEM, los mipmpas si.

Sogun escribió:He recordado un vídeo de DF retro sobre el Unreal Tournament donde muestran esa falta de interpolación entre mipmaps pero también lo llaman "bilinear filtering" así que puede que yo tenga el vocabulario confundido, pero creo que son cosas distintas y se ajusta más a como yo lo llamo.

No no, tu concepto es el correcto, no hay más que mirar la wiki:

Trilinear filtering is an extension of the bilinear texture filtering method, which also performs linear interpolation between mipmaps.

A veces las palabras y terminos son tan parecidos que se hacen un lío. O que no lo han estudiado tan rigurosamente como dicen...

Sogun escribió:Se me había olvidado comentar de que la caché se vuelve a dividir por la mitad cuando hay que guardar mipmaps, así que en texturas con paleta de colores estamos limitados a 1 kB. Los 4 kB se organizarían de la siguiente manera:
-2 kB para la paleta de colores ¡un despilfarro!
-1 kB para la textura en sí.
-1 kB para los mipmaps de la consola cuando se generan automáticamente. (ocupan bastante menos de 1kB).
Pero si creamos de antemano nuestros propios mipmaps podemos aprovechar los 2 kB que no se gastan en almacenar la paleta de color, pudiendo ganar algo de resolución. Crear nuestros propios mipmaps también puede mejorar su definición en pantalla y evitar algunos artefactos que pueden ocurrir cuando se generan automáticamente.

Que se pudiera volver a dividir no lo sabía, o no lo recordaba si se dijo en el hilo.
Demasiadas divisiones, se hace poco práctica una textura tan pequeña y se desperdician los efectos.
Sigo sin tener muy claro si tiene un sentido práctico los mimaps para la resolución de la consola. Para suelos extensos de texturas repetidas tiene sentido, pero debido a la resolución no sé si acabará pasando igualmente lo mismo aunque haya mipmaps.

Sogun escribió:Tu solución de almacenar la paleta en otro sitio hubiese sido ideal. Podríamos aprovechar los 4 kB de la caché para texturas más grandes (aunque 64x64 me parece adecuado para jugar a 240p) y con más colores. Se podría dejar una misma textura en la caché e ir cambiando la paleta en ciertas situaciones para ganar tiempo de proceso y espacio de almacenamiento y RAM. Unos artistas realmente creativos harían cosas impresionantes con esta posibilidad.

Me habría gustado ver ese tipo de efectos en la consola como en la anterior generación. Es un truco excelente para aprovechar una textura.

Sogun escribió:Respecto a la textura del esmoquin, he creado esta imagen que creo que explica muy bien visualmente cómo se realiza el proceso de conversión a textura en escala de grises de 4 bits.

La textura original tiene 16 colores (grises) distintos pero están elegidos como si fuese una textura con paleta de color. Cuando se convierte a IA de 4 bits los colores se adaptan a las 16 intensidades y muchos se quedan en el mismo nivel. La textura final se queda en sólo 8 colores.
Por eso decía en mi mensaje anterior que con 16 colores bien elegidos puedes hacer cosas muy buenas, pero que las texturas en escala de grises de 4 bits te limitan muchísimo aunque luego puedas colorearlas.

Vale, ahora lo entindo mejor. Pensé que al activarse el alpha por error se había reducido la paleta de 16 a 8 intensidades.
Pero comprende que el error está en hacer el smoking con una paleta personalizada en vez de con las intensidades reales con las que trabaja la consola. En tu ejemplo la paleta personalizada provoca que la consola se salte el tercer gris más oscuro. Lo suyo habría sido dibujar el smokin directamente con los valores de intensidad, no esperar que el programa sea "listo" y adapte la textura según lo que quieres. Con la textura de la espalda al no haber tantos valores tan separados en la escala, se podría aprovechar mejor las intensidades y tener 16 niveles de gris oscuro.

Y como dices a una paleta de 16 colores bien elegida se le puede sacar mucho jugo. Pero cada tipo de textura servira para determinadas situaciones.

Todas estas cosas hay que estudiarlas y hacer pruebas durante el diseño del nivel. Si solo modificas texturas no tienes opción a cambiar el modelado para redistribuir los triángulos y, por ejemplo, usar dos texturas para hacer el camino empredrado del nivel de Counter Strike que pusiste antes, para usar dos texturas de 32x32 y 16bits con mipmapping en vez de limitarte a una.

@EMaDeLoC desactivarlo en algún juego igual no afecta porque la máquina va sobrada, pero desactivarlo sí que mejora el rendimiento porque el modder ese que optimiza sus hacks de Mario 64 para funcionar en consola hizo el vídeo explicando como lo logro paso a paso y uno de ellos era desactivando filtrado.

@SuperPadLand Entonces es que en ese otro juego que yo mencionaba tenía el cuello de botella en otra parte.

@EMaDeLoC igual lo entendí yo mal, hablo del vídeo de Super Road Star creo que se llamaba el hack. También es cierto que en ese vídeo muchas cosas que hacía tenían una mejora muy leve, pero todo suma claro. La única que realmente tenía un impacto grande sino recuerdo mal fue bajar la resolución.

@SuperPadLand
El filtro que desactivaban en el Super Star Road era el antialising y sólo en algunos polígonos. También se eliminaba la niebla, aunque no recuerdo si era en todos los niveles o sólo en algunos.
Super Mario 64 no usa filtro trilineal ni mipmaps el 99% del tiempo. Diría que sólo se emplean en el retrato de Peach que cambia a Bowser mostrando un uso creativo de esa tecnología.

En N64 puedes decidir polígono a polígono qué efectos quieres que se apliquen. Cosas como antialising, niebla, corrección de perspesctiva, z-buffer, pintado de vértices o los distintos filtros de texturas no son algo que dependan de un controlador general que se pueda activar o desactivar como si fuese un juego de PC (aunque supongo que también está la opción). Un ejemplo muy claro son los edificios que rodean el escenario del primer nivel de Perfect Dark, que no tienen filtro de texturas mientras que todos los demás sí están filtrados (no es el único juego que lo hace).

@EMaDeLoC
Con lo que ya no estoy tan familiarizado es con las opciones de 1-CYCLE y 2-CYCLE. Sé que algunos efectos gráficos como el filtro trilineal requieren de ambos ciclos (se prepara una parte de la información a procesar en el primero y se terminan de hacer los cálculos en el segundo), pero tampoco me queda claro si hay un máximo de efectos sencillos que se pueden hacer en 1-CYCLE pero que al haber demasiados en un mismo polígono se necesitan los 2 ciclos para procesarlos todos. Esto podría explicar por qué no hay mejoras en el rendimiento a pesar de quitar algunos de los efectos, porque tienes que esperar a que acabe el segundo ciclo aunque no lo uses del todo.
Una analogía para que se entienda mejor lo que quiero decir: si cada ciclo puede hacer 8 cosas, y todos los efectos activados necesitan 16 cosas pues estás ocupado el 100% del tiempo de los dos ciclos. Pero si quitas algunos efectos y necesitas 10 pasos, sigues necesitando empezar el 2ª ciclo para calcularlo todo y hay un tiempo de espera que pierdes. Tendrías que quitar más efectos para necesitar como mucho 8 cosas y usar sólo 1 ciclo. Y en ese caso irías el doble de rápido. Pero supongo que eso no implica duplicar los frames, ya que hay más cosas que afectan al rendimiento.

¿Qué clase de polígonos podríamos tener en 1-CYCLE? ¿Sería posible algo mejor que lo que se ve en PS1? Por ejemplo, polígonos texturizados con corrección de perspectiva y sombreado gouraud, sin antialising, ni z-buffer, ni niebla. Serían como polígonos de PS1 pero con corrección de perspectiva que ya hace mucho (y presupongo que la precisión subpíxel viene de serie, pero podría ser otra cosa que se pueda activar). ¿Serían posibles en 1-CYCLE?


Ya por último respecto a los juegos que desactivan efectos gráficos para hacer la gracia y verse como un juego de PS1. ¿Hay alguno que se note alguna mejora en el rendimiento? Los juegos de Acclaim como Turok y Extreme-G solían tenerlos, pero no recuerdo que mejorara nada.

@Sogun
2 CYCLE es para cuando quieras realizar 2 operaciones distintas que estén relacionadas con la misma superficie, trabajar con varias texturas de forma simultánea, aplicar 2 tipos de efecto distinto a la vez sobre la misma superficie, los modos complejos del color combiner (el Mario de metal), etc porque cada comando requiere un set de parámetros para inicializar que no cubres con 1 sola llamada, en plan textura A con estos efectos + textura B con estos efectos, o textura A con estos efectos + efecto completamente distinto que requiere de otro tratamiento pero está relacionado con la textura o superficie anterior.

1 CYCLE ya de por sí tiene acceso a la mayoría de efectos, luego hay reestricciones como comentas para casos únicos, hay 3 modos de niebla que requieren 2 CYCLE en las superficies afectadas (solo 1 de ellos se puede utilizar en 1 CYCLE), el ya comentado trilinear, etc ahora no me acuerdo de todo, pero hay más.

El Extreme-G con el truco sigue usando 1 CYCLE, es básicamente llamar a set_other_modes con un parámetro distinto en el filtrado de textura (sample_type: 0 inactivo, 1 activo), de la lista que monté cuando estuve pasando los comandos de binario a demo:


Se puede acceder a todo esto independientemente del modo que estés usando y establece el comportamiento general de todas las superficies a partir de ese momento (lo puedes llamar tantas veces quieras, por ejemplo en Perfect Dark entendemos que lo llama en los edificios de fuera para desactivar el filtrado y lo vuelve a llamar dentro para activarlo, probablemente lo llame unas cuantas veces más para establecer efectos, en las superficies que no use Z como las típicas barandillas que parecen de papel), pero claro, si no usas el modo apropiado puedes esperar desde comportamiento imprevisible, que no tenga efecto, cuelgue generalmente si tratas de tocar Z y no tienes un buffer preparado.

Luego este es solo 1 de los comandos, pero es el más potente digamos, para preparar 1 solo triángulo hay que llamar a unos cuantos más.

No sé si esta respuesta cubre lo que preguntaba dirtymagic.

@Señor Ventura
Puede que los resultados que saca en los vídeos no sean correctos en todos los casos, la resolución tendría que mirarla cuando tenga un rato (igual ya la tenga por aquí), si puedes échale un ojo a los comentarios del vídeo que hay algunas buenas respuestas.

Decoro con imágenes la lista de juegos "suaves" que hice el mes pasado, son fotos sacadas con cámara de móvil muy a mi pesar, así que la calidad no es para tirar cohetes, pero me apetecía ilustrar (Hardware original, RGB, OSSC)

Automobili Lamborghini



Cruis'n Exotica
En realidad es incluso más colorido, bueno no, es como un pastel derramado por toda la pantalla, me gusta la definición de la montaña de la segunda imagen sin embargo




F-1 Pole Position 64
Pues muy sencillo él


F-Zero X / 64DD
Complicar los escenarios? No gracias, que luego tengo que mostrarlos 4 veces a la vez



Mario Kart 64



Monster Truck Madness
Muy redonditas las ruedas


Multi Racing Championship
Es raro hasta en captura, lo de la rueda con todo lujo de detalles ha salido de pura casualidad, estaba intentando tomar panorámicas con una mano en el mando y otra en el móvil, desconozco si se ponen así de detalladas desde algo más de distancia, pero es un buen detalle




Ridge Racer 64



S.C.A.R.S



Snowboard Kids


Snowboard Kids 2


Stunt Racer 64


Twisted Edge Extreme Snowboarding
No es tan feo, pero que le vamos a hacer


Tony Hawk's Pro Skater, 2, 3
Agrupo los 3 por lo horrendo de las capturas



Top Gear Rally
Lo había recomendado ya? Quizás debería volver a hacerlo...



World Driver Championship






Wipeout 64
Aquí no han salido bien, lo dejo pendiente junto a la lista de los "disfrutables"

El Twisted Edge Extreme Snowboarding es uno de esos juegos de Boss que tenía un formato raro para el audio y estuvo como 10-15 años sin sonido en emuladores. A mi no me gustó nada, en todo caso.

Me encanta el colorido de Stunt Racer 64. Luego ya el diseño es cuestión de gustos.

Buff, que bajón ese Top Gear Rally. Recuerdo ver unas primera capturas en las revistas que eran impresionantes... para luego salir "eso"... Que no digo que no esté mal del todo, pero...

No sabía que había un juego de racing acuático para la model 2 de sega:
https://youtu.be/0Cecq6shr5A?t=49

Y aquí el wave race 64:
https://youtu.be/1_ULO4VQ91U?t=101

@Conker64 contento con el OSSC no?

bluedark escribió:Buff, que bajón ese Top Gear Rally. Recuerdo ver unas primera capturas en las revistas que eran impresionantes... para luego salir "eso"... Que no digo que no esté mal del todo, pero...

Seguramente esas capturas vienen de una demo técnica que hizo Boss Game Studios en estaciones de Silicon Graphics para que Nintendo les diera luz verde al proyecto:

Development of the game started in July 1996, after the company created a non-interactive demonstration that featured two- and four-wheel drive vehicles racing through different driving conditions.[8] The demonstration was enough to convince Nintendo of America that Boss could develop a game for the Nintendo 64 console. Although the demonstration was developed on Silicon Graphics workstations that were more powerful than the Nintendo 64 and included vehicles that were modeled in 15,000 polygons, Boss was confident that their finished game would be very similar, stating that technical aspects such as lighting effects could be ported easily.

https://en.wikipedia.org/wiki/Top_Gear_Rally#Development_and_release

15.000 polígonos en los coches, anda que no se fliparon...
Seguramente esas imágenes que has puesto vendrían de la confirmación del desarrollo, cuando no tenian nada empezado o mejor para mostrar.
También según me pareció oir como le añadieron al juego la opción de personalizar la pintura del coche, los modelos los hicieron más simples.

No es el primer caso de imágenes "engañosas" y creo que la mayoría vienen de ahí, de estar desarrollando en las estaciones antes de pasar a la consola.

A mi el Top Gear Rally 2 me moló que es el que tengo anotado, desconozco porque descarté el primero a estas alturas.

@Conker64

Acojonante cómo se ve World Driver Championship. La iluminación es espectacular.

Uno curioso era el Rally Challenge 2000, que tenía unos reflejos bastante avanzados para la época, parecidos a los del Ray Tracers de Playstation (aunque RC2000 reflejaba lo que tenías detrás, mientras que Ray Tracers reflejaba lo que tenías delante, por algún motivo que se me escapa).



También tenía el típico efecto blur sin medida cuando pulsabas C-algo en las repeticiones, como Ridge Racer.

Genki: ¿Cuánto blur quieres?
Nintendo: Sí

El Rally Challenger 2000, es un juego que tiene un rendimiento bastante bajo, no sé si será por el render to texture de los cristales, aunque lo más seguro, por que cuándo extraes la geometría , saca 2000 polígonos clavados, pero el framerate es horrible, cuando esta estabilizado no creo que supere los 20 fps y a la mínima que derrapas y sale humo o tierra por delante de la cámara pega unos bajones de cojones, es una pena porque aunque los escenarios no son muy recargados, el modelado de los coches y los reflejos de los cristales, hace que sea resultón gráficamente, eso sí en emulador, en N64 no me parece que deje una buena sensación por culpa del framerate.
Salud.

Doriandal escribió:Uno curioso era el Rally Challenge 2000, que tenía unos reflejos bastante avanzados para la época, parecidos a los del Ray Tracers de Playstation (aunque RC2000 reflejaba lo que tenías detrás, mientras que Ray Tracers reflejaba lo que tenías delante, por algún motivo que se me escapa).

Si refleja lo que hay delante puede que solo esté reutilizando el framebuffer (o región del mismo), aplicándolo a la textura, que dándole perspectiva y tal igual cuela, para mostrar lo que hay detrás es más parecido a un retrovisor (creo que el mismo RC2000 lo tiene en la cámara interior), con una escena montada en un buffer auxiliar que ya consume bastante más.

RiGaL escribió:Acojonante cómo se ve World Driver Championship. La iluminación es espectacular.

Las imágenes aparecen un poco quemadas, pero ese escenario en el amanecer es genial

SuperPadLand escribió:Contento con el OSSC no?

Posi, pero con este calor no me fío de ponerlo demasiado, queda calentito al tacto de la mano

--

He conseguido probar el Choro Q 64 2: Hachamecha Grand Prix Race, que tenía pendiente y va peor que el primero. (Aquí Penny Racers)

También he aprovechado para copiar el Misión Imposible americano, a ver si ya llega ese análisis, aunque me tocará empezarlo de 0, lo jugaba en PAL (no le gusta a la tele), que menos, para algo que doblan al español... aunque no tenga demasiado diálogo.

MVG ha sacado un vídeo hablando sobre el hito técnico que fue el Wave Race 64 en su momento y que se mantiene a día de hoy.



Nos desgrana un poquito del desarrollo y de como están implementadas las olas en el juego.
Las imágenes del juego son en buena parte de emulador de Switch Online y del Project64. Echo en falta imágenes de hardware original, pero bueno.

@Conker64

He visto las imágenes que has puesto, cómo juegas a Cruis'n Exotica? a mí me sale en blanco y negro y difuminado al ser NTSC, mi consola es PAL claro está, con el ED64plus se puede ejecutar pero no me sale a color.

Lo mismo pregunto una chorrada pero...

@Kabanya Diría que es más cosa de la tele que de la consola. Busca una tele que soporte NTSC

Que no se vea en color un juego en formato NTSC es porque el televisor no lo soporta por compuesto. Cosa bastante corriente en los tv PAL de mediados de los 90 hacia atrás, por eso la gente se compraba el cable RGB de PSX para ver en color los juegos NTSC, porque si la TV soporta RGB se ve a color sea NTSC o PAL, la problemática es que N64 no tiene salida RGB de serie ( excepto las PAL Francesas) y hay que hacerles un mod.

Salud.

@txefoedu @dirtymagic @Kabanya
Si pones un juego NTSC en una consola PAL, el vídeo se emite a 60Hz (o casi 61Hz) pero la codificación de color sigue siendo PAL, puesto que el chip interno de vídeo sigue siendo para PAL. Viceversa para una consola NTSC corriendo un juego PAL.

Hay televisores que no aceptan estas mezclas de región de frecuencia por un lado y codificación de color por el otro, aunque te acepten NTSC y PAL y sean modernos. A veces si el televisor acepta PAL60 (o NTSC 4.43) funciona, pero es a veces.

La única solución es hacerle mod RGB a la consola. Conker64 ya la tiene modificada.
Bueno, y obviamente también puedes jugar solo a juegos PAL, o comprar una consola NTSC si tienes un televisor que lo soporte.

Las PAL francesas no tienen RGB de serie, hay que añadirle unos componentes que faltan o hacerle el mod de amplificador simple. No puedes enchufar un cable RGB y listo, que es lo que se entiende como "de serie".

EMaDeLoC escribió:
Las PAL francesas no tienen RGB de serie, hay que añadirle unos componentes que faltan o hacerle el mod de amplificador simple. No puedes enchufar un cable RGB y listo, que es lo que se entiende como "de serie".

Vaya,pensaba que las francesas al ser PAL Secam, estaban obligadas a sacar RGB por ley, de ahí que fueran diferentes al resto de PAL,pero ni por esas 😅😥, perdonad la confusión.

Salud.

@dirtymagic Estás en lo cierto de que por ley se tenian que conectar por RGB, pero por lo visto se flexibilizó para aceptar vídeo compuesto. Nintendo ya tenía encargadas las placas base con soporte RGB pero al enterarse de que no era obligatorio, dejó de poner todo lo relacionado con el RGB que pudo. Los componentes podían costar 1 dolar en total por consola, pero si multiplicas por 10.000, pues es un dinero que se ahorró.

No hay nada que perdonar, no ibas tan errado. La NES francesa si tiene RGB de serie, aunque en realidad es vídeo compuesto sacado por RGB y se ve igual de mal.

De Wave Race, el detalle que más me gustó (comentado por aquí hace tiempo) fue el de que las estelas de las motos dependieran del peso de los pilotos, un puntazo. Cosa que estaba mal en el vídeo de Digital Foundry en su día. Ambos vídeos hablan de cosas diferentes, supongo que combinando ambos se pueda sacar algo interesante.

Gracias a todos por las aclaraciones, lo probé en mi tele antigua y funciona bien los NTSC, hasta se ve mejor que en la tele nueva, pero bastante mejor, y eso que la nueva tiene menos de un año y supuestamente es compatible con NTSC, la vieja marca OKI chusquera y se ve mejor...

He visto el mod RGB pero me da palo poder estropear la consola, es la versión naranja transparente y se ha encendido como mucho 10 veces.

Lo del NTSC es porque quería jugar a la trilogía cruisn y no sabía que cruisn exótica solo está NTSC, lo jugaré en la tele chica.

EMaDeLoC escribió:No hay nada que perdonar, no ibas tan errado. La NES francesa si tiene RGB de serie, aunque en realidad es vídeo compuesto sacado por RGB y se ve igual de mal.

La NES no tiene RGB en ninguna de sus versiones domésticas.

La NES francesa tiene salida por cable SCART o EUROCONECTOR, y solo lanza señal de vídeo compuesto.

https://es.wikipedia.org/wiki/Euroconector

No confundamos al personal, por favor, que luego se montan unos chochos...

Diskover escribió:

EMaDeLoC escribió:No hay nada que perdonar, no ibas tan errado. La NES francesa si tiene RGB de serie, aunque en realidad es vídeo compuesto sacado por RGB y se ve igual de mal.

La NES no tiene RGB en ninguna de sus versiones domésticas.

La NES francesa tiene salida por cable SCART o EUROCONECTOR, y solo lanza señal de vídeo compuesto.

A ver...
Nos asomamos a este blog donde abren una NES francesa:


Dentro de la caja del modulador RF, pues no hay modulador RF (no hay ni salida de antena, está el conector propietario de Nintendo), lo que hay es un chip marcado como Sony V7021.
Si buscamos el datasheet de dicho chip, encontramos el siguiente PDF y en la primera línea de la descripción pone:

V7021 is a decoder IC used to convert composite video signals into analog RGB signals.

Lo que en español es:

V7021 es un circuito integrado decodificador usado para convertir señales de vídeo compuesto en señales RGB analógico.

Es decir, que la PPU saca vídeo compuesto, el chip V7021 lo convierte en RGB y sale por la consola.
Sale RGB, pero sigue siendo calidad de vídeo compuesto, pero sigue sacando RGB.

Diskover escribió:No confundamos al personal, por favor, que luego se montan unos chochos...

Si, por favor, no confundamos al personal sin haber hecho antes una búsqueda de 5 minutos por Google.
Gracias.

@EMaDeLoC @Diskover os prohíbo discutir que me caéis bien los dos

Yo a mi rollo terminando de poner las imágenes que faltaban (prometo que es la última tanda):

Wipeout 64
Pendiente de la lista de juegos suaves, creo que la captura lo representa muy bien, sinceramente veo el F-Zero a otro nivel, muy discreto este trabajo.


--
Ahora la lista de "disfrutables":

Excite Bike 64
En baja resolución que es donde funciona suave, escenarios que favorezcan las fotos, los oscuros del estadio me hacen un Tony Hawk, yo creo que el juego está un peldaño por encima de la mayoría en cuanto a texturizado de escenarios.




Hydro Thunder 64
Los reflejos siempre me han parecido un efecto bastante barato que da un toque espectacular a los circuitos.



Mickey's Speedway USA
En la gran mayoría de cielos de este juego se usan degradados sin texturizar como el de la imagen, quizás en su momento intentaban demasiado texturizar con cielos 3D estirados hasta el infinito cuando esta técnica da un resultado muy limpio, a coste mínimo.


Road Rash 64
Praderas con vacas y Hulk Hogan, se puede jugar al busca la pareja (todos los participantes están repetidos como mínimo 1 vez)



Vigilante 8 - 2nd Offense
Random dither a pantalla completa, por ello parecen escaneos de revista en lugar de fotos, creo que ya lo comenté en su día, el motor es inteligente y en las superficies más lejanas no texturiza, luego hace blend al acercarse.





Wave Race 64
Terribles capturas (aunque ya que las pedía EMaDeLoC ahí van algunas), lo más llamativo es lo cerca que están los marcadores de los extremos de la pantalla, pero por otro lado hay franjas negras alrededor de la pantalla, nada importante, creo que en general los juegos de conducción hay que verlos en movimiento, en especial estos que son los más suaves del catálogo, por ejemplo en Wave Race se veía todo vacío según donde hacía las capturas, al final todas las fotos son orientadas apuntando a edificios o planos concretos.

Justo @Conker64 comentaba el Road Rash 64 y se ha volcado un prototipo del mismo:


Vídeo del prototipo grabado con un puñetero emulador

¿Y si resident evil hubiese salido en nintendo 64?...

@Señor Ventura al igual que PSX no podia sacar un golden eye, una n64 al igual que en el caso anterior no podria haber sacado una mejor version de resident evil, simplemente por limitaciones de memoria.
Podrian haberlo sacado pero hubiera sido como esos cartuchos de Neo Geo con esos precios prohitivos, era posible pero inviable economicamente.

En este caso,apuntan a re4.Pero,hay que recordar,que re0,iba directo a N64.

Está bastante bien conseguida la atmósfera de RE4 , eso sí, lo más seguro es que habría que bajar la distancia de dibujado con una niebla más cercana, si quieres poner a Leon y 2 o 3 enemigos.
Posiblemente se adaptaría mejor con el motor de JFG que ya es un shoter en 3er persona con apuntado cercano a la cámara del RE4, al fin al cabo el editor de GE/PD es compatible con el JFG.

Salud.

@dirtymagic pero si lo hace en FPS se ahorra renderizar a Leon, lo que permite meter uno o dos enemigos más. La ambientación está muy lograda por cierto.

Segastopol escribió:@Señor Ventura al igual que PSX no podia sacar un golden eye, una n64 al igual que en el caso anterior no podria haber sacado una mejor version de resident evil, simplemente por limitaciones de memoria.
Podrian haberlo sacado pero hubiera sido como esos cartuchos de Neo Geo con esos precios prohitivos, era posible pero inviable economicamente.

El RE4 es en 3D no en fondos pre-render y es original de GC no de PS1. Ambas se quedan cortas para mover una versión fiel del RE4, pero la que menos pena daría sería N64. Pero vamos que es un juego que le queda grande hasta a DC.

mcfly escribió:En este caso,apuntan a re4.Pero,hay que recordar,que re0,iba directo a N64.

El cual hubiera tenido mejor calidad de los fondos pre-render y FMV en PS1 o SS. Y mejores modelos 3D de personajes y enemigos en N64. Y unas cargas de 5 segundos como poco al cambiar de personaje en PS1, en SS quizás con la expansión de RAM no, pero a saber.

Y en enemigos también influye la cantidad en pantalla que igual en N64 te pone 5 zombies diferentes sin despeinarse y en PS1 todos iguales o ralenizadose (como pasa en RE3 que si hay hordas de 5-7 zombis con un barril al lado para que quede bonito, pero que duren poco en pantalla xD):



En el gif no se nota, pero en PS1 eso se ralentiza y la consola pide papas.

@SuperPadLand
Lo decía por ser más similar al original, aunque creo que hace años que en el motor de GE se puede cambiar la cámara, pero sí, en teoría tendría mejor rendimiento sin renderizar a Leon, pero también en un FPS tienes que detallar más las texturas, al acercarte tanto, en 3era persona, no hace falta detallar tanto y puede ayudar al fillrate, la N64 hay que estar constantemente balanceando entre detalle y rendimiento.
Salud.

Segastopol escribió:@Señor Ventura al igual que PSX no podia sacar un golden eye, una n64 al igual que en el caso anterior no podria haber sacado una mejor version de resident evil, simplemente por limitaciones de memoria.
Podrian haberlo sacado pero hubiera sido como esos cartuchos de Neo Geo con esos precios prohitivos, era posible pero inviable economicamente.

salio RE2 para N64, no veo razon alguna para que no se pueda hacer el RE1 igual o incluso mejor que el de PSX

jordigahan escribió:

Segastopol escribió:@Señor Ventura al igual que PSX no podia sacar un golden eye, una n64 al igual que en el caso anterior no podria haber sacado una mejor version de resident evil, simplemente por limitaciones de memoria.
Podrian haberlo sacado pero hubiera sido como esos cartuchos de Neo Geo con esos precios prohitivos, era posible pero inviable economicamente.

salio RE2 para N64, no veo razon alguna para que no se pueda hacer el RE1 igual o incluso mejor que el de PSX

Hoy en dia sin limitaciones de memoria seria posible, estamos de acuerdo

Muy interesante el hilo.

es mas, me atreveria a decir que apretando un poco se podria meter en una snes quitando los videos.

Segastopol escribió:@Señor Ventura al igual que PSX no podia sacar un golden eye, una n64 al igual que en el caso anterior no podria haber sacado una mejor version de resident evil, simplemente por limitaciones de memoria.
Podrian haberlo sacado pero hubiera sido como esos cartuchos de Neo Geo con esos precios prohitivos, era posible pero inviable economicamente.

Si se pudo hacer con RE2, se podía perfectamente hacer con RE1.

Vamos a ver, que los Resident Evil de PSX no son ningún portento técnico. Vas sobrado.

Estaba pensando, que teniendo en cuenta que la N64 tiene acceso al framebuffer y hay muchos juegos que hacen uso de él, en un juego con cámaras fijas, ¿sería posible usar escenarios con una carga poligonal muy alta ( 50.000 polígonos por escena por ejemplo) renderizar un frame usarlo de fondo y solo actualizar los objetos activos (personaje, enemigos, objetos, efectos)y mezclarlo en framebuffer final y hasta que no haya un cambio de camara no volver a renderizar el escenario, supongo que consumiría mucha RAM, pero no creo que fuese tanto problema con el expansión pak y se podría tener escenarios con una calidad similar a un escenario prerenderizado ocupando menos espacio en el cartucho. ¿creéis que sería posible? o la latencia de la RAM lo impediría o simplemente sería complejo de programar @Conker64

Salud.