Hilo de detalles y curiosidades de N64

@Conker64
Esto es una extracción de la caverna que aparece en el menú. Hay otras habitaciones que no están conectadas físicamente. Unos 9k polys tiene el export.
Imagen

Aquí se puede ver el clásico efecto de reflejo antes de que los cubemap y el raytracing vinieran a atormentarnos.
Imagen

Dentro de la taberna si tomamos, si posicionamos la cámara en la entrada y descartamos los polys que no tocan, se nos quedan en unos 4200:
Imagen

Después hice una captura nada más empezar el juego, en esta posición:
Imagen

Prácticamente todo el nivel se manda al RSP, no parece haber mucho o ningún culling antes (la escena entera son unos 3600 triángulos):
Imagen

El modelo de Conker son 844:
Imagen

El modelo utilizado para su sombra son 131:
Imagen

La sombra parece funcionar proyectando un cubo sobre el escenario (desde el foco de luz en dirección a la posición de Conker) y generando nueva geometría en los puntos de corte, una cámara renderizará el modelo de la sombra desde la posición desde donde se proyecta ese cubo a una textura que luego se aplica sobre esa nueva geometría generada.

La escena inicial parece renderizar unos 1900 polys:
Imagen

@Sogun Curiosamente implementé ese método en mi homebrew aquí lo explico brevemente (https://youtu.be/BvG-71v-b0o?t=30) También funciona en N64 aunque el video es de la versión de hace un año (https://youtu.be/NFK9DnI3cPk?t=53).

Básicamente funciona como has mencionado, puedes agrupar texturas en filas, columnas o ambas siempre que el número de estas sea 1 o una potencia de 2. Por ejemplo puedes agrupar 4x4 quads, el sistema generará una única textura para la 4x4, cuatro texturas para el primer agrupamiento (2x2) y luego 16 texturas individuales (en el caso de que fuesen todas diferentes). Después el sistema morphea del de 4x4 al de 4x(2x2) y luego al de 16x1 dependiendo de la distancia a la cámara, el morphing se hace en screen space y también se hace morphing de los colores de los vértices. En Jak & Daxter esas agrupaciones se pueden hacer por triángulos también, en el caso de CTR solo para quads y con la única combinación de 2x2.

Como comentaste te quita la gestión manual de los mipmaps (en 64 lo gestiona el sistema solo, pero así tampoco tienes que usar ningún bloque de la cache con eso).

También te permite descartar grandes polígonos de golpe (puedes determinar si por ejemplo un 4x4 no está mirando la cámara y hacer backface culling de 16 polígonos de golpe, lo mismo para el frustum culling)

Aunque hay también un gasto extra por el morphing que en otros juegos no se haría.

En cuanto a datos del CTR, al parecer lo que más consume del juego es la IA de los enemigos. En el modo free-roaming he capturado unos 2500 triángulos:
Imagen

Dentro de carrera solo he llegado a ver 2000. Una cosa interanste es que la gente que está trabajando en el dcomp al parecer tienen una versión que corre a 60 en hardware real: https://www.youtube.com/watch?v=d9psliWJ0es&ab_channel=Darkaiser pero no he podido comprobar su veracidad.
Misscelan escribió:Esto es una extracción de la caverna que aparece en el menú. Hay otras habitaciones que no están conectadas físicamente. Unos 9k polys tiene el export.
Imagen


Ah sí, la habitación de arriba creo que es la de Berri, Conker llama desde la taberna en la intro, siempre me ha encantado eso de poner diferentes estancias y luego desplazar la cámara para hacer el cambio de escena.
Imagen

La entrada que pones de la taberna, creo que era uno de los picos de geometría de esa escena, en su momento jugué con el debug activado durante largo y tendido (aunque se colgaba), y si mal no recuerdo ese momento funcionaba sobre los 17-20, 20 es bastante común en los puntos de estrés, aunque fluctúa como una montaña rusa.
Imagen

EMaDeLoC escribió:¿Pero sí estaban seguros de que podían optimizar el código, porqué no lo optimizaban desde el principio?
A mí me suena más a marketing. En plan "mira el juego que hemos hecho en PS1 y solo hemos explotado 3/4 de su potencial!! eh! eh! mira aquí, a la PS1!! no, no mires la N64!! Aquí, la PS1!"


No sé, puede ser lo que comentas pero yo lo veo bastante común, mis códigos a lo largo de los años cada vez han ido a mejor, más pequeños, más flexibles, más rápidos.. si tengo que montar ej. un plataformas normalmente me leo algo que ya haya hecho, como hice el motor de tiles, como interactúan los sprites con esos tiles para hacer las colisiones, las cuestas e inclinaciones.. y normalmente es en ese momento cuando me pongo a retocar.

Luego por otro lado si tienes fechas que hay que cumplir, se te puede encender la bombilla, pero muchas optimizaciones requieren cambios en muchas partes, como no estés fino y te olvides de algo viene la catástrofe, a veces es mejor eso de que si algo funciona no lo toques.

Suena raro, porque ahora te sacan los juegos rotos sin optimizar y lo hacen al final, pero antes no podías cargarte toda la producción de cartuchos o CDs por ello, optimizar puede traer errores.

Yo creo que cuando hablan pueden referirse a esto, o ser puro humo como comentas, a veces es en los siguientes juegos de la misma plataforma cuando se aplican esas mejoras y deberían ir mejor / verse mejor, o similar, aunque no siempre es el caso, o no siempre son el mismo equipo y la cosa se cae.

O´Neill escribió:@Conker64 podéis hacer un hilo con ese tipo de información (cantidad de polígonos que sacaban estás consolas ps1,Saturn,n64, dreamcast,etc)?

Me parece interesante ver lo que realmente sacaban estás máquinas y lo que nos vendían las compañías, aún recuerdo la publi de ps2 y sus 75 millones de polígonos xD


No sería mala idea, en su momento tenía pensado algo así, en models resource se pueden conseguir muchos modelados y visualizarlos con blender, para escenas y datos reales ya haría falta más análisis, más gente que participe.

Los modelados a partir de cierto nivel dejan de tener sentido, de 1000 a 10000 las diferencias son enormes, de 10000 a 20000, ya se reducen y así, pero de la generación 32bit a la 128bit es cuando se produjo todo ese maravilloso salto. (esta imagen es un clásico de internet, como gol de señor, pero sirve)
Imagen

Lo de los 75 millones también me suena haberlo leído, ahora no recuerdo que Hobby Consolas fue, pero era entre el 2001 y el 2002, con una comparativa de todas las "128bit".

De hecho llevé la revista al instituto y todos quedaron maravillados con PS2 y esos números, se acompañaba una captura del Tekken Tag, en un escenario lleno de césped, que comparado con las 4 hojas que te ponían las 32/64bit parecían trillones, nadie dudaría de esas cifras.

Sogun escribió:Otra prueba que hice fue comparar el rendimiento de los niveles vacíos de GoldenEye en ambos motores gráficos. Se movían básicamente igual, normalmente a 30 fps y bajando a 20 en los mismos sitios. Había zonas en las que en GE bajaba a 20 pero PD se mantenía a 30, y otras zonas donde pasaba al revés. Especialmente curioso el caso del final del nivel de Bunker, la zona exterior donde acaba el nivel. En GE se mueve a 60 fps si no miras a la puerta del bunker, pero en PD en todo momento funciona a 30 fps. Es como si GE sólo tuviera en memoria los trozos de nivel que se ven directamente (y está cargando y descargando parte del escenario constantemente) mientras que PD además gestiona trozos del escenario cercanos aprovechando que usa más RAM (se ve que para ayudar en la descompresión de datos).


Me suena que vi un vídeo donde se eliminaban muchos elementos de las fases de Goldeneye, se dejaba solo el escenario y luego se medía el rendimiento, no sé si se puso aquí o lo vi yo por casualidad en Youtube.

Pero esa parte del Búnker que comentas salía y iba a 60.
3701 respuestas
171, 72, 73, 74, 75