Hilo de detalles y curiosidades de N64

Responder
1…75, 76, 77, 78, 79
EMaDeLoC escribió: @Señor Ventura No existe "escala de grises" como textura en la N64, sino Intesidad o Intensidad con Alfa. Esta intensidad se refiere al color del triángulo o polígono. Si el triángulo es blanco, el valor 255 será el blanco y el valor 0 será el negro, siendo los valores intermedios una escala de grises. Pero si el triángulo es verde, 255 será el verde puro, 0 el negro y los valores intermedios los pasos de este verde al negro. Y así con otros colores que se pinte como rojo, azul, morado, naranja, etc, y supongo que también si cada vertice es de un color y se hace un degradado.
En cierta forma vendría a ser la "luminosidad", pero luminosidad es erroneo y confuso. Si el triángulo es de color azul oscuro, el valor 255 no va a dar un azul luminoso, solo el mismo azul oscuro.


¿Esto afecta a todo el polígonos homogéneamente?, o puedes variar el grado del color con mas precisión (estaría genial por pixel, pero me da que no va a ser así).



edit: Ah, ¿entonces si?, que confundido estoy...
@Señor Ventura Puedes pintar los vertices del triángulo o polígono de colores distintos, el RCP (y cualquier GPU) pinta la transición de colores entre distintos vertices. Luego la textura aplica la intensidad de cada color según donde caiga el pixel en dicho polígono.
Creo que, en el ejemplo que he puesto, en la caja de la izquierda, han hecho que los vertices de arriba sean un poco más oscuros que los de abajo, lo que hace un efecto de sombra, pero la textura sigue siendo de intensidad y los vertices color marrón.
Un ejemplo práctico sería una textura tipo hierba, y en el polígono pones un lado verde y otro marrón claro, y parece que hay una transición entre tierra y hierba.
@EMaDeLoC
Está claro que aparte de configurar la textura en CC, programa como actua, parece como que pinta los vértices en una escala de grises en tiempo real como si fuera iluminación, y dependiendo del grado de gris pinta una máscara de un patrón o otro, está muy bien pensado, lo otro es el "bump-mapping" que ya se a mostrado por aquí.
De todas maneras,tanto lo de Kaze, el "bump" y lo que yo he mostrado , todo usa 2 cycles, y 2 texturas,aunque lo de Kaze sea en "diferido" y no mezcle las dos en CC, al final pinta una textura y luego elimina partes con una máscara que es otra textura.

Salud.
SuperPadLand escribió:@radorn hola que es NTSC-M?


NTSC-M un nombre semi-técnico del NTSC original. la M viene por el "system M", la designación internacional que se le dió al sistema de TV en blanco y negro original Americano al que luego se le añadió el color NTSC retrocompatible.
NTSC-J en jerga de señal de video, es la designación informal que se le da a la variante Japonesa de NTSC, que principalemente tiene un nivel de señal para representar el negro diferente al NTSC-M.
Las consolas de los 90, mas allá de que alguien me enseñe una que no (y no digo que no la haya), todas generaban una señal NTSC-J en vez de NTSC-M. Un decodificador ajustado para los niveles de NTSC-M, al recibir una señal NTSC-J, mostrará una imagen mas oscura y, si el receptor es digital, además, se perderán los detalles finos en zonas oscuras al reducirse esa cola de grises a negro.

En estos enlaces lo explico mas detalladamente:
1: Diferencias NTSC-M y NTSC-J
2: Un poco de lo mismo con incapié en captura digital
3: ejemplo ilustrativo

BONUS - Diferencias regionales N64
@radorn ah vale no sabía que se llamaba así, pero entiendo que te refieres a lo que yo llamaría como NTSC-U de USA. [+risas]
@SuperPadLand NTSC-U es mas una designación de región para videojuegos, entiendo que primeramente implementada por Sony para la PS1 (alguien sabe si otros lo hicieron antes?). Pero si hablamos de normas de video, NTSC-M sería un nombre mas correcto. Entiendo que no es un término habitual para muchos, pero bueno, yo hablo así y si alguien pregunta se lo explico. Así se aprende :)
Con esta demo la N64 va al límite XD.


Descripción:
Something a bit different and non-tiny3d.
This demo implements a basic ray-marcher running on the CPU and RSP.
The CPU does the basic loop per pixel incl. ray construction and the final shading,
whereas the RSP does the loop per ray to determine the distance.
Since i pre-run the first ray, CPU & RSP can run mostly in parallel.

SDFs on the RSP are baked into the ray-loop for performance reasons, so each SDF is a copy of the entire loop.
The CPU does the same to save a few instructions.
In the end, a set of constexpr-structs define what functions a scene will use.

Since the shading is done on the CPU, there is a bit more freedom for effects.
For example texturing can be done with any texture size and generated UVs.
The textures on models are 256x256 RGBA16, and the skybox a whopping 1024x512 pixel (equirectangular mapped image even).

As far as practical use-case go... well not much tbh.
Even the basic loop for the raymarcher without actually checking a SDF is slow.
So the only thing i may look into in the future is to make an optimized skybox-only version.

_________

Note: If you want to emulate this ROM, please use ares or gopher64.
Input is also very delayed, so hold down buttons for a bit.

_________
0:00​ - Basic SDF
1:06​ - Point Light
1:47​ - Stripes
2:22​ - Normal Mapping
3:27​ - Octahedrons
3:45​ - Simple Env-Mapping
5:04​ - Skybox / Sky-Reflections
@doblete ¿por qué se supone que me tiene que impresionar ese pase de diapositivas con vsync galopante en algunos tramos?
@Sexy MotherFucker La gracia es darle a la N64 un trabajo típico de los servidores de gráficos de Silicon Graphics de donde viene parte de su diseño principal.
Vamos, como poner al nieto a labrar el campo del abuelo. Tiene gracia, pero no futuro práctico.
Sexy MotherFucker escribió:@doblete ¿por qué se supone que me tiene que impresionar ese pase de diapositivas con vsync galopante en algunos tramos?



Lo explica en la descripción, pero vamos que la sorpresa es que lo mueva, como el Doom de Megadrive a 0,5fps. Es un techo entiendo, a partir de ahí podrás rebajar y mirar otras aplicaciones.
EMaDeLoC escribió:Vamos, como poner al nieto a labrar el campo del abuelo. Tiene gracia, pero no futuro práctico.


Ah vale, ya lo pillo:

Imagen

Para que se crea importante.

Señor Ventura verá en esto un potencial sin desarrollar en los videojuegos, el cual nos perdimos.

Nintendo 64; la FollaDreamcases.
Pues veo en eso una máquina con potencia para hacer todo eso incluso mas rápido de lo que esperaba, por lo que celebro que hay cpu para lo que quieras en un entorno de juego normal.
Con potencia para hacer demos a diapositivas, sí; sin colisiones, IAs, etc. Y confundirlo con algo remotamente cercano a la siguiente generación, o extrapolable a juego real.

Pero tío, que me estás poniendo un vídeo de los mundos de yupi literalmente tras decir algo que no es lo que esperabas como para ponérmelo [qmparto]

Para ti esta demo es despreciable porque no renderiza lo que renderizaban estaciones de trabajo en tiempo real y a 60 frames por segundo, lo cual si que compete que te pongas ese vídeo a ti mismo [rtfm]
Señor Ventura escribió:Pues veo en eso una máquina con potencia para hacer todo eso incluso mas rápido de lo que esperaba, por lo que celebro que hay cpu para lo que quieras en un entorno de juego normal.



No estoy entendiendo bien lo que tratas de decir, pero su creador dice esto:
As far as practical use-case go... well not much tbh.
Even the basic loop for the raymarcher without actually checking a SDF is slow.
So the only thing i may look into in the future is to make an optimized skybox-only version.


Como testeo de máximos de algo "imposible" se mueve más que bien, porque saca varios fps. Como ya dije, el Doom en MD iba a 0,5 y es un logro que lo mueva al menos xD
@SuperPAdLand Pues justo eso, que esperaba que renderizara esas imágenes todavía mas lento de lo que lo hace. No es poca cosa lo que se ve ahí.
Sexy MotherFucker escribió:@doblete ¿por qué se supone que me tiene que impresionar ese pase de diapositivas con vsync galopante en algunos tramos?


No tiene que impresionar, simplemente es para la curiosidad.
Acerca de la demo anterior del Ray-Marching, el autor da una explicación en uno de los comentarios:

Usually you render objects with triangles, which get rasterized into pixels.
Here you do it the other way around checking for each pixel on screen if an objects is there.

For that you shoot a ray into the scene per pixel from the camera position.
Each ray then steps though the scene checking if it hits something.
If it does, it also check the direction the surface points at (normal vector) and can then apply shading.
In this case some color effects or fancy texturing.

The special part about raymarching compared to e.g. ray-tracing is the way objects are described.
Instead of meshes out of triangles, objects are just mathematical functions telling you how close you are to them (called SDFs).
Or in other words, if i give it a point in 3D space, it tells me how far away the closest point on the surface is.
So the raymarcher can then stop if the distance becomes small enough for me to consider it a hit.
Note that it has no idea where objects are, or even the direction, it can only check the distance.

A sphere for example can be described as:
"sqrt(x*x + y*y + z*z) - radius"
Where xyz are the position of the ray.

The special thing that makes raymarching "fast" is that instead of stepping the ray at small fixed steps,
you can always step by the amount the SDF returned.
Since you know that that distance is the closest thing to possibly hit.

But on N64 as you can imagine it is painfully slow, since there are many (looped) steps i have to do per pixel.


Lo que se está renderizando no es una malla de polígonos generada a partir de vértices en el espacio, sino formas geométricas descritas por fórmulas matemáticas. Por eso las formas son tan simples. A cambio la superficies son perfectamente curvas. Fijaos que no se notan segmentos en las aristas y que la iluminación es por píxel.

Pero la principal peculiaridad de la demo es que en lugar de montar la escena en la parte del espacio que puede ver la cámara y empezar a dibujar y descartar las formas que hay delante y detrás para dibujar la imagen final, lo que hace es lanzar un rayo desde la cámara por cada píxel de la pantalla y comprobar si choca con algo para poder dibujarlo. Cuando el rayo choca con la superficie luego tiene en cuenta la normal de esa superficie para aplicar texturas y otros efectos.

Se supone que esta forma de renderizado es rápida, pero en Nintendo 64 es lentísima supongo que por los problemas de fillrate que tiene la consola y que todo se hace secuencialmente y no es posible hacerlo en paralelo. Quizás alguien lo pueda explicar mejor.
Yeah i tried skip some of the calculations for repetition, but the issue i was running into was that it ironically increased cost.
One main difference to modern hardware is that the CPU/RSP are single core processors.
So each pixel/ray happens in sequence (well the RSP is vectorized, so some calculations can do 2 rays at once).
But adding one instruction per ray means i pay it per-pixel, whereas modern hardware / GPUs can offset the cost since you only pay it once per batch as they actually run in parallel.


Esto no se puede aplicar en juegos, pero el autor comenta que sí que se puede sacar partido a los skyboxes. Por lo que entiendo de la descripción son como cubemaps de 1024x512 píxeles de resolución. Supongo que RGBA16, como las texturas de la demo, pero eso no lo especifica.
Por comparar, el skybox de los Zeldas está formado por medio cubo troceado en cuadrados para acoplar 93 texturas de 8 bits de profundidad de coloar de 32x32 píxeles de tamaño. Estas texturas se acoplan para formar una imagen de 512x192 píxeles.
Yo creo que no es para nada así, el ray-maching es mucho más exigente en figuras que no sean esferas o cubos donde el raytracing es más rápido, está claro que esto para un juego como que no, pero no me parece banal, a lo mejor abre camino a algo a medio camino y potente para el estándar de N64.

Salud.
Curiosidades Mario Kart 64:

Lo de aumentar la velocidad por encima de la del jugador cuando se quedaban rezagados es lo mas asqueroso que tenían los juegos de carreras antes. Dan ganas de apagar la consola.
@Señor Ventura de antes y de ahora, que es imposible despegarte de ningún rival en los últimos Mario Kart.

Ya puedes hacer la carrera perfecta usando 50 setas turbo, que en cuanto te lancen la concha azul, eres rebasado al momento por 5-6 corredores fácilmente. No se despegan de ti ni aunque hagas tiempos de speed run.

Es una de las cosas que más odio en juegos de carreras.
A ver si entre tanto técnico podéis echarle un ojo a porqué Indiana Jones elimina un nivel sin el expansion pak. Dejo aquí el comentario donde lo informo: hilo_juego-del-mes-5agen-octubre-indiana-jones-and-the-infernal-machine-n64_2473785_s2300#p1756273313

Y aquí el vídeo donde lo vi:
@SuperPadLand No tenía ni idea de que Indy se saltaba un nivel sin el EP.
Supongo que será demasiado grande en algo... texturas, geometría, elementos interactivos... ni idea. No recuerdo si llegué a pasarme el juego ahora mismo, pero creo que si que jugué ese nivel con los vagones de carga sobre railes.
Jo, mi memoria ultimamente es una anténtica porquería. Que asco da ser viejo...
Por lo que veo en los videos, es posible que sea que el nivel se cargue entero en RAM y sea muy grande para la memoria de stock.

Salud.
No lo he jugado mucho, pero ya que este juego hacía streaming, parece que la velocidad de – streaming de la ROM+descompresión (sumada a la no linealidad del nivel) - es más lenta que la velocidad de la vagoneta entre puntos de carga.

Con la expansión podrían tener más secciones en RAM o quizás el nivel entero.
Otro vídeo muy técnico de Kaze explicando como funciona el mezclador de sonido de SM64, y de casi cualquier otro juego de N64:
3926 respuestas
Responder
1…75, 76, 77, 78, 79
Volver a Consolas clásicas