Hilo de detalles y curiosidades de N64

La verdad que es un hilo increible. Estamos muchos expectantes de saber mas detalles de nuestra consola preferida. La verdad que las aportaciones del op son la leche! A mi gracias a este hilo me ha dado por desempolvar la consola y darle al project 64 tambien. Que bien se juega perfect dark con teclado y raton!

@salvor70 No sé por qué me has editado mi anterior comentario, quizás porque te has venido arriba o porque viene especificado claramente en las normas, pero la razón que pone es errónea: No he compartido ningún enlace de ebay ni de wallapop, tan solo era una captura (sí, de ebay, sin que se vea la url ni nada) de una compra que hice hace tiempo y que no estaba alojada en ninguno de los sites que mencionas.

Estaría genial que me lo explicaras, por favor, porque ese comentario ha quedado inútil una vez que se ha borrado la imagen. Saludos.

@b0mb4ch45 , debido a los problemas que han generado en anteriores ocasiones, solemos quitar los enlaces a EBay y wallapop que muestren compras o que vayan por el tema " flipados inside".
Entiendo que lo tuyo era una captura, pero se ha editado para evitar esos problemas, ya que realmente el hilo no trata de compras o de precios de mercado. Si hubiera sido una foto tuya de lo que has comprado no hubiera habido el más mínimo problema. (O una descripción de lo que has comprado).
Lamento las molestias, pero la intención era que no se repitiesen esos problemas y se echase a perder el hilo.
Si crees que es necesario compartir tu compra en este hilo, pon una foto tuya y no habrá problemas.

BMBx64 escribió:

Agradezco los comentarios , a ver si luego pongo más material.

Una pregunta @BMBx64 en Super Mario 64, ¿siempre se renderiza a Lakitu aunque no aparezca en pantalla?, ¿Solo cuando aparece en la sala del espejo?

Según las extracciones no está cargado si no sale en pantalla, SM64 es muy óptimo con los modelados 3D y no los carga si quedan fuera del campo de visión, sin embargo las monedas rojas que son 2D si que las dejan siempre para que se vean desde cualquier distancia y sepas como encontrarlas (en cuanto a esos detalles jugables Nintendo siempre ha sido muy lista)

El punto con 3 colores es exactamente el foco de la cámara donde debería estar Lakitu


Escena original.


El efecto del espejo es geometría inversa duplica, la sala está dividida en 2, la parte donde se unen es el espejo que es un polígono semitrasparante que hace a su vez de pared para no entrar en el otro lado de la sala, Lakitu solo aparece en la parte duplicada del espejo que representa el reflejo (su punto de referencia es efectivamente la cámara, él es la cámara).


Escena original.

Muchísimas gracias @BMBx64 por la explicación. Es una duda que tenía desde 1997, jajaja, pero no había conocido a nadie que me la supiera responder, y menos de forma tan didáctica .

Recientemente ha aparecido un 64DD USA. Hasta el momento se pensaba que todas las unidades de 64DD (incluidos devkits) eran de región japonesa, pero ésta en concreto parece ser que se utilizó para mostrar demos a la prensa en algún evento.

La diferencia más obvia es que los textos están en inglés en lugar de en japonés.
Pero lo más intrigante es que junto al 64DD había un disco cuyo contenido todavía no ha sido revelado. El dueño está intentando contactar con alguien para poder dumpear el contenido o hacerlo funcionar en el hardware real. Quizás dentro haya algunas demos inéditas.

El hilo de Assemblersgames donde se dio a conocer:
http://assemblergames.com/l/threads/us- ... und.62294/

Vídeo del dueño del artilugio:
https://www.youtube.com/watch?v=b64Bx0WKh7M

Me mola mucho el efecto gráfico de la textura del logo de N64 que se ve en el minuto 7:07 del video. Es como si estuviese hecho de un material cerámico rugoso y reflectante. No recuerdo haber visto nada así en ningún juego, aunque tengo ideas de cómo podría hacerse algo similar. ¿Alguien conoce algún juego comercial donde aparezca un efecto similar?
Lo único parecido que recuerdo son unas estructuras metálicas en el Perfect Dark: https://youtu.be/hvwvX9hEsm8?t=1m58s

El descubrimiento del 64DD versión USA es toda una sorpresa. ¿Qué hubiera sido de N64 si se hubiese llegado a lanzar el DD en occidente? Gracias a @Sogun por postearlo por aquí.

Sogun escribió:Me mola mucho el efecto gráfico de la textura del logo de N64 que se ve en el minuto 7:07 del video. Es como si estuviese hecho de un material cerámico rugoso y reflectante. No recuerdo haber visto nada así en ningún juego, aunque tengo ideas de cómo podría hacerse algo similar. ¿Alguien conoce algún juego comercial donde aparezca un efecto similar?

Parece el típico efecto de postprocesado que aplican hoy en día en casi todos los juegos. Un shader de bump mapping o normal mapping para darle aspecto de volumen y relieve a una textura sobre un polígono sin necesidad de mover geometría extra. No sé cómo se logra tal efecto en una Nintendo 64, de hecho, no había visto nunca nada así en ningún juego de la consola. Los reflejos y cromados del Mario metálico (SM64), del Escudo Espejo de Link (OOT) y similares son efectos diferentes a este.

Interesante lo de la unidad usa del dd,pena que no salio de jap.

javierator1981 escribió:

Sogun escribió:Me mola mucho el efecto gráfico de la textura del logo de N64 que se ve en el minuto 7:07 del video. Es como si estuviese hecho de un material cerámico rugoso y reflectante. No recuerdo haber visto nada así en ningún juego, aunque tengo ideas de cómo podría hacerse algo similar. ¿Alguien conoce algún juego comercial donde aparezca un efecto similar?

Parece el típico efecto de postprocesado que aplican hoy en día en casi todos los juegos. Un shader de bump mapping o normal mapping para darle aspecto de volumen y relieve a una textura sobre un polígono sin necesidad de mover geometría extra. No sé cómo se logra tal efecto en una Nintendo 64, de hecho, no había visto nunca nada así en ningún juego de la consola. Los reflejos y cromados del Mario metálico (SM64), del Escudo Espejo de Link (OOT) y similares son efectos diferentes a este.

Ahora caigo que en el Blast Corps el vehículo Backslash tenía un efecto similar, pero viendo el vídeo en HD detenidamente parece que se va cambiando de textura según el punto de vista de la cámara. Se pueden ver saltos en los reflejos cuando el vehículo gira lentamente. La baja resolución y borrosidad de la consola original disimularían estas transiciones.
https://youtu.be/SbSLtkyNP6E?t=4m40s

En este otro vídeo el propio creador del Backslash meciona cómo realizó el efecto. https://youtu.be/FKS9gffc09w?t=1m53s

Es posible que el logo de N64 del menú del 64 DD utilice el mismo truco haciendo transiciones suaves entre las distintas texturas de la animación para disimular los saltos. Tendría sentido, porque posteriormente la textura "cerámica" cambia suavemente a una textura convencional. El punto de vista es siempre el mismo, por lo que se puede tener todo perfectamente controlado.

Pero es bump mapping de verdad?.

Señor Ventura escribió:Pero es bump mapping de verdad?.

No lo creo, lo más seguro es que lo consiguieran con alguna técnica similar a la que comenta @Sogun, haciendo transiciones suaves entre varias texturas iluminadas desde diversos puntos. De hecho, como él dice, es menos complejo programar algo así con un modelo, un punto de luz y una cámara que están en puntos fijos que hacerlo para un caso como el vehículo del Blast Corps.

Qué locura tuvo que ser programar algo así, y sólo para conseguir un detalle que puede incluso pasar desapercibido.

Señor Ventura escribió:Siempre me quedará la duda sobre cual hubiera sido la distancia entre N64 y dreamcast si nintendo no hubiese capado tanto su consola.

Yo me he hecho esa paja mental en ocasiones tambièn, y la ùnica certeza que tenemos a la hora de plantearnos esos "what if?" es que el RCP sería la ùnica pieza del hardware que no podríamos mover del sitio; ya que es el chipset específico que SG quiso venderles "ambulantemente" desde el principio primero a SEGA, y finalmente a Nintendo, por lo que teniendo en cuenta que toda la fase de transformación la procesa èste, dificilmente la N64 hubiese sido una màquina que llegase a procesar 1 millon de polígonos texturados x segundo (Dreamcast gestiona hasta 5 millones en juegos cómo Le Mans 24 horas segùn Null), por mucho que se pudiese aumentar el reloj a 70 Mhz.

El debate estaría en todo lo concerniente a la C.P.U, tipo de memorias, buses, cachè para texturas, formato de almacenamiento, etc. De hecho en las ùltimas fases de gestaciòn querían implementarle un R-4400 a 150 Mhz còmo C.P.U, pero al final optaron por el arrabalero R4300i, que era una especie de sub-versiòn del R4200 con el bus externo capado a 32 bits

De todas formas teniendo en cuenta la època cualquier mejora en el hardware hubiese implicado un incremento en el tamaňo de la consola, y a mí la N64 me parece preciosa y cuqui tal cual está

@Sexy MotherFucker
He visto que me citaste en el hilo ese del velo de snes, pero ando un poco perdido desde hace un tiempo, también posteabas en vandal?
--

MÁS CURIOSIDADES

El mando Hori para N64 recuerda un poco al de Gamecube pero es más pequeño, elimina el esquema 3 cuernos, por ello el gatillo Z curiosamente está replicado 2 veces como si fuera el L2 y el R2 de PSX, la cruceta es pequeña y está mal situada, sin embargo hablan muy bien de su joystick, uno de los puntos flojos del mando original de N64 y de su duración, así que puede ser una buena alternativa, pero por su rareza, bien caro es.


Además de Waverace existen juegos como DK64 que en terrenos pequeños usan animación poligonal para el agua, si salimos al mapa exterior donde se ven las islas, el agua deja de tener animación, pues la zona que tiene que renderizar es mucho más grande y prefieren usar polígonos grandes para rellenar el área.


En Turok Dinosaur Hunter el agua también tiene animación y en terrenos bastante amplios, el agua de Port of Adia en Turok 2 sin embargo no tiene.


Viendo el wire-frame de Shadowman parece que utiliza una buena distancia de dibujado, la iglesia no la alcanzamos hasta el final del nivel, pero aquí ya podemos verla representada, aunque sea de una forma simple.


El modelado la verdad es que no cambia mucho desde lejos o cerca, la parte superior es exactamente la misma, pero si cambian los alrededores.


Dentro de la iglesia se descarga todo lo de fuera como era de esperar, la puerta pega portazo si intentamos que se vea el interior y el exterior simultáneamente.


Este tipo de optimizaciones por salas lo tienen muchos juegos, en este caso Perfect Dark al abrir o cerrar puertas.


Hablando de los recortes de la consola antes de su lanzamiento, un panfleto de noviembre del 1993 con el hype de SGI.


No sé si en el foro se habrá hablado ya del mod HDMI de la consola, supongo que sí, la mejora parece importante, hace de reescalador con diferentes filtros y tiene un menú in-game que aparece con una combinación de teclas.


Una pequeña review del hdmi a partir del 12:40 (lo comparan con un mod RGB con reescalador framemeister que viene a ser de lo mejor que había antes del hdmi para la consola)
https://www.youtube.com/watch?v=qpy1M6v2_MI

El famoso mando de hori, hace mucho que quiero uno pero el precio es desorbitado,mínimo hay que desenbolsar unos 80€,así que me he tenido que confirmar con hacerle el cambio del joystick por el que es estilo del de la gamecube pero adaptado a la N64.

Yo tengo el Hori y al final acabo jugando con el original. Se me hace demasiado pequeño y no me acabo de acostumbrar a no tener la Z como un gatillo, sobretodo en los shooters. De todos modos tampoco es que le haya dado mas de una oportunidad

Algunos le han hecho overclock de 93.75 a 125 Mhz a la N64 asegurando que los juegos se ven mas con mas frames o mas "fluidos", pero no se si eso dane a la consola.

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

También es mi consola favorita. muy cerca de la Game Cube (molaría un hilo sobre esta)

Opino que le faltó algo más de potencia pero eso habría supuesto hacerla ruidosa y meterle ventilador. Mayor carga poligonal (un 50% más) y texturas el doble de ricas habrían marcado mucho más la diferencia. Qué hardware era necesario para eso no lo sé Entiendo que por costes y demás se hizo como se hizo, pero mola imaginar.
Y fallo garrafal: que no tuviera RGB de serie!!!

La intro de Wave Race 64, en aquellos tiempos, parecía vídeo, cuando la cámara está apuntando al agua es una virguería.

El primer Turok me dejó alucinado. Esos efectos de partículas que no se veían en las demás consolas (y que en Turok 2 todavía mejoraron), la animación espectacular de cada arma cuando cambiabas, el comportamiento del agua tan bien recreada cuando le disparabas... Hubieron rumores de que preparaban una versión para PSX, pero yo seguía sin imaginar esa agua pixelada, no habría sido Turok.

Tras jugar decenas de veces a Mario 64 va Rare y me hace un plataformas igual de divertido pero con gráficos marca de la casa: Banjo Esas gotitas de agua cuando saltas con Banjo en la orilla del mar son pequeños detalles que hacen a un gran juego (y consola).

Para mí, Beetle Adventure Racing fue un 'dreamer' como un piano, y es un pedazo juego con unos gráficos muy buenos, velocidad aceptable y gran jugabilidad.

Rogue Squadron me mantuvo encerrado en mi cuarto muchas noches. Y es que se jugaba de noche y con auriculares. Alucinante la fase nocturna donde hay luna llena y hacías giros 360º persiguiendo Tie Fighters . Está en mi top 10.

Lo que nunca entenderé seran los tiempos de carga de Resident Evil 2 siendo el soporte cartucho, que alguien me lo explique.

También me gustaría que alguien me explicara cómo unas consolas que viene siendo N64 o PSX, que 'piensan en 3D', dibujan un Mortal Kombat o un Street Fighter 2D. ¿Qué trucos usan?

Lo de Resident Evil 2, las puertas que se puedan saltar en el port de PC?

Creo que no en todos los ports del juego se pueden saltar las puertas, en algunos será necesidad en otros dejadez, en N64 podrían estar usando ese tiempo para descomprimir archivos dentro del cartucho, tendría que revisar y ojo que los cartuchos de N64 en muchos casos usan memorias de 5mb/s de transferencia secuencial, aunque el acceso aleatorio es mucho más rápido que el de un CD.

Los "sprites 2D" son un comando que configura el chip gráfico tanto de PSX como de N64 para un rendimiento óptimo, nunca llegan a ser "sprites" es información rectangular que se copia a una imagen 2D (framebuffer) usando texturas como bitmap o color solido para rellenado pero ahorrándose mucho cálculo, el RDP en modo 2D se pone simplemente a renderizar todo lo que se le envía, mientras el RSP no interviene demasiado.

Esos comandos tampoco son 2 polígonos de 3 vértices unidos para formar uno rectangular, aunque se puede programar de esa manera, sobretodo si queremos darles otro tipo de propiedades.
--

Dejo 2 vídeos, uno de ellos es Digital Foundry analizando el framerate de Goldeneye y Perfect Dark, resultados no muy diferentes a los que puse en la primera página del hilo.
https://www.youtube.com/watch?v=Cx3_beBwsZ0

Otro de CEN64 con un mes de antigüedad, un emulador aún en desarrollo (el sonido rasca, aún debe funcionar bastante lento), se distingue de los demás por emular verdaderamente a la consola y no a las librerías libultra, sobretodo se nota la diferencia en los bitmaps y en la consistencia en general, aunque también se notan muchos menos fallos gráficos como era de esperar.
https://www.youtube.com/watch?v=Jy8IOxcj8r4

BMBx64 escribió:Lo de Resident Evil 2, las puertas que se puedan saltar en el port de PC?

Creo que no en todos los ports del juego se pueden saltar las puertas, en algunos será necesidad en otros dejadez, en N64 podrían estar usando ese tiempo para descomprimir archivos dentro del cartucho, tendría que revisar y ojo que los cartuchos de N64 en muchos casos usan memorias de 5mb/s de transferencia secuencial, aunque el acceso aleatorio es mucho más rápido que el de un CD.

En la versión de N64 no se pueden saltar las puertas, yo esperaba que le sacaran partido al soporte cartucho y no pasara lo mismo que en PSX.


Vamos con unos dev kits. Qué enamorado estuve de esos SGI azules!

He leído que con un pequeño programa se pueden parchear las roms para cambiar el microcode con el que fueron creados. El programa que vi permitía entre Fast3d Y F3DEX.

MI duda es si de un modo semejante se podría reemplazar por los microcodes propios como el del WDC o bien el Turbo3D que se supone permitía mayor carga poligonal pero que no permitían ser usado.

Supongo que te refieres a este programa


El ucode personalizado de Boss Studios no creo que pueda intercambiarse, la mayoría de juegos usan el z-buffer, pero tanto World Driver Championship como Stunt Racer 64 usan un listado manual para incrementar el fillrate, además de estar programados de una forma muy concreta, cierta parte en la manipulación de polígonos lo hace directamente la CPU porque descubrieron que lo hacía más rápido que el RCP, una burrada.

Un ucode tampoco permanece todo el rato cargado en los 4KB de memoria, se van cargando distintas piezas de código según sea necesario.

Si algún juego permite pasar de Fast 3D a F3DEX2 es porque en realidad es una ampliación de la misma librería, "Fast 3D EXtended 2", es una librería extendida que Nintendo iba mejorando, con bugs corregidos (de cara a los desarrolladores) y mejoras de rendimiento, para ver esas mejoras de rendimiento hay que usar las nuevas funciones que trae la librería y programar en consecuencia.

En cuanto al Turbo 3D no sé ande andará, sé que desactivar el AA o el resto de filtros usando Fast 3D no tiene el incremento de rendimiento esperado, pero es porque muchos cálculos ya se han hecho de antemano para dar viabilidad a esas funciones gráficas.

Joer, y yo que me creía super cool y muy geek por saber lo que es el Clipping, Anti Aliasing, Z-Buffering y demás características que mencionaba la campaña de márketing de la consola... Se me escapa casi todo de lo que hablais!

Que buen hilo. Me encanta leer estos datos historicos de cada consola. En este caso de la N64, no sabia mucho

@BMBx64
Tío eres un crack. Mira que molan todas estas curiosidades.
He visto que también le pegas a trastear en la megadrive

Hola gracias, llevo tiempo pensando en traer el hilo de Megadrive aquí, pero enfocado de otra forma, quizás en un rato

BMBx64 escribió:Hola gracias, llevo tiempo pensando en traer el hilo de Megadrive aquí, pero enfocado de otra forma, quizás en un rato

A la espera me hallo

Edit: joder, que raudo

Estamos impacientes por que nos traigas alguna novedad de nuestra querida n64

Pues aún me quedan algunos aportes menores y bastante flojetes , si queréis saber algún detalle en concreto como lo del espejo de SM64 de páginas atrás no dudéis en preguntar, a partir de ahí puedo hacer nuevos aportes cuando tenga tiempo.

--

MÁS CURIOSIDADES

Iluminación, como se ilumina en N64?

Dado que la capacidad de cálculo de las consolas 32/64bits es limitada para dar color o iluminación a un escenario se suele pintar los vértices de un triángulo de forma manual en el escenario.

Aquí tenemos un triángulo con un color distinto en cada vértice, de un vértice a otro se produce un suave degradado fusionando los colores a tonos intermedios.


He montado un gif con 3 pasos (las 3 imágenes son de PacoChan, de otro hilo), en el primer paso es el nivel con texturas pero sin iluminación, el segundo paso es sin texturizar con iluminación goraud que se ha añadido manualmente a la escena, el tercer paso es el resultado final, el interior del cangrejo de la fase de playa de Banjo Kazooie.


En este caso además de iluminación se añade color, pero puede ser en blanco y negro para simular solo la sombra, como en la parte del suelo, donde solo se vuelve más oscuro.


Como se compone un escenario 2D de Yoshis Story?

Son tiles de 64x64x8bits = 4KB, algo que no se ha comentado hasta ahora es que a N64 no le gustan demasiado las texturas impares y desde luego se nos colgará si tratamos de usarlas con la libdragon, tendría que verificar como se porta con libultra.

Los escenarios de Yoshis Story suelen ser muy sencillos, en las cuevas por ejemplo son solo 2 planos.

Tenemos el de atrás


Y el que va por encima, que en este caso también va por encima de Yoshi.


Una vez juntos, la cámara corresponde a la resolución de pantalla, que el scroll sea más grande que la pantalla es lo que permite el movimiento.


El pobre Yoshi desmontado, no es un único sprite, va a "piezas" para generar movimientos más complejos sin usar demasiado espacio en el cartucho.


El resultado final, con efectos bastante majos, como zoom o el movimiento tridimensional al pasar página.



Aleck 64
Es una maquina arcade basada en N64 desarrollada por SETA para Japón, el hardware es exactamente el mismo, de hecho modificando la protección del CIC se pueden hacer correr algunos de sus juegos en hardware original parcheando simplemente la rom.

Imagen promocional


Tower & Shaft lanzado en 2003, también hubo una versión en GBA.
https://www.youtube.com/watch?v=yGKO-eqSTzs

Otros juegos de Aleck64 (imágenes cortesía de micro-64)

Probablemente uno de los más interesantes de la lista, pero no deja de ser como el J League Eleven Beat lanzado en el 97, en inglés, con selecciones, con mejoras gráficas y algunas diferencias menores (insert coin!!)


Vídeo del J League Eleven Beat, muy divertido por cierto.
https://www.youtube.com/watch?v=juKLoQ2Z4F4

Varios juegos de puzzles desarrollados en 2003



Wtf ok



Versión cancelada de Frogger 2
Existe una versión alpha de lo que sería Frogger 2 que más tarde fue lanzado en PSX, en la rom hay 2 niveles accesibles, uno de ellos es este del vídeo.
https://www.youtube.com/watch?v=AzOhOAfQkRk

El juego en el estado de la alpha consiste en esquivar elementos y rescatar ranas, no puede usarse la lengua y hay fallos de programación, podremos salirnos del mapa según como caemos al agua, la cual por otra parte ni siquiera esta animada.

Esta alpha incluye un curioso Frogger "retro", es probable que sea una versión emulada por el equipo de programación para trastear con la consola.


Además incluye unas cuantas herramientas, como un visor de modelados 3D, este es el otro escenario de la rom:


Oops, aunque haya selector de niveles todos fallan al cargar

Como siempre un post lleno de curiosidades BMBx64. Muy interesante el tema del color, y de cómo se montan los niveles del Yoshi's Story. Nunca había oído hablar de la recreativa con las características técnicas de N64. Siempre aprendo un montón en este hilo. Saludos BMBx64!!!

Ampliando un poco sobre la iluminación precalculada por vértices.

Es algo que según tengo entendido no consume más recursos (por defecto todos los vértices están "pintados" de blanco). En juegos como los Zeldas, Jet Force Gemini, Donkey Kong 64 y Perfect Dark se cambian estos valores en tiempo real para simular los ciclos día y noche y la luz de antorchas y disparos.

Pintar los vértices no sólo sirve para simular una iluminación. Su uso más habitual es pintar texturas en escala de grises de 4 bits (16 tonos) para dotarlas de un color concreto. Por ejemplo, las montañas del jardín principal de la entrada del castillo del Mario 64 usa la misma textura que los parapetos del puente, pero pintada en verde. O las rocas de la Montaña de la muerte en el Ocarina of Time son una textura en blanco y negro pintada de marrón.
En Perfect Dark ocurre algo curioso si activas el truco de "Oscuridad Perfecta" para jugar los niveles a oscuras. En este modo, los colores en los vértices originales se pierden para ser sustituídos por tonos negros y así simular la oscuridad. Cuando disparas y el escenario se ilumina, podrás ver las texturas en escala de grises tal y como son realmente. Por ejemplo, las montañas que rodean el comienzo del Area 51 o el techo de madera de la bodega de la Villa.

En Perfect Dark los escenarios se modelaron teniendo en cuenta cómo podía usarse la geometría combinada con vértices pintados para simular un sombreado realista. En GoldenEye ya dieron algunas muestras, pero PD es otro nivel:










Perfect Dark es una maravilla a nivel de diseño de cómo aprovechar las características de Nintendo 64 al máximo para lograr estupendos resultados. Su trabajo con las texturas es una cosa de locos. Están todas hechas para tener la mayor resolución posible, lo que significa que el 95% de las texturas del juego tienen 16 colores (4 bits de profundidad de color). Prácticamente las únicas texturas de 8 bits son las que se usan para las cabezas de los personajes. Esto permite poner el doble de texturas en memoria que si todas fuesen de 8 bits de profundidad de color (256 colores) y te puedes permitir combinar texturas para formar una imagen mayor y más definida:



Si además cuenta con 4 MB extras que te proporciona el Expansion Pak los resultados son alucinantes.


Un saludo.

Respecto a la inteligencia artificial de los enemigos debo decir una cosa... sí, estaba bien implementada pero... Aún recuerdo como en Facility en cierta habitación me ponía poner justo detrás de un soldado al cual le disparaba con el silenciador en UNA MANO y el hijo de madre solo alcanzaba hacer un gesto de dolor para acto seguido volver a su posición original ignorando totalmente el insignificante detalle de que un par de segundos antes le habían clavado un balazo en la mano sin tan siquiera voltear xD

Danimonto escribió:Respecto a la inteligencia artificial de los enemigos debo decir una cosa... sí, estaba bien implementada pero... Aún recuerdo como en Facility en cierta habitación me ponía poner justo detrás de un soldado al cual le disparaba con el silenciador en UNA MANO y el hijo de madre solo alcanzaba hacer un gesto de dolor para acto seguido volver a su posición original ignorando totalmente el insignificante detalle de que un par de segundos antes le habían clavado un balazo en la mano sin tan siquiera voltear xD

Jajaja si me acuerdo que a mi también me pasaba eso en el Golden eye

Solo el hecho de que los enemigos reaccionasen de forma diferente segun la zona en la que les disparases... Y no solo eso, podian perder su arma, agacharse a recogerla y seguir disparandote, rendirse o retorcerse de dolor e intentar escapar... Pfff es que ver eso en un juego de hace 16 años era la leche. Aun hoy sigue sin ser algo habitual en los juegos. Ese tipo de detalles hacen de perfect dark uno dde los mejores shooters de la historia sin discusion.

Razer7 escribió:Solo el hecho de que los enemigos reaccionasen de forma diferente segun la zona en la que les disparases... Y no solo eso, podian perder su arma, agacharse a recogerla y seguir disparandote, rendirse o retorcerse de dolor e intentar escapar... Pfff es que ver eso en un juego de hace 16 años era la leche. Aun hoy sigue sin ser algo habitual en los juegos. Ese tipo de detalles hacen de perfect dark uno dde los mejores shooters de la historia sin discusion.

Completamente de acuerdo

Siempre soñé con una versión mejorada de Goldeneye, sin ralentizaciones. Los de Rare eran tan bestias que llevaban todas las máquinas que tocaban al límite, pero algunas veces demasiado No creo que haya ningún otro shooter de esa generación que muestre a tantos enemigos en pantalla en cuanto a objetos 3D se refiere. Tal vez Doom 64, pero los enemigos no son 3D.

A los entendidos sobre el tema me gustaría que explicaran un poco los beneficios de que una consola fuera 64bits respecto a las competidoras de 32bits.

Apenas se usan datos de 64bits, la libultra los usa para algunas instrucciones concretas del SO, pero en los juegos se usan datos de 32bits, porque son suficientes y porque reducen el espacio, etc

Si quieres compararla con PSX a nivel de datos algo más importante que los bits es la precisión, N64 puede trabajar con datos en coma flotante, el GTE (el coprocesador de PSX) que hace toda las operaciones de vértices transforma la perspectiva a enteros, una rotación de matriz de 3x3 y coordenadas int de 32bits, no permite hacer movimientos con corrección de subpixel y va pegando saltos, lo cual se traduce a inestabilidad del mundo 3D, a animación 3D a saltos..

N64 es superior animando un modelado que PSX, sobretodo cuando son movimientos suaves y lentos como puede ser la respiración, lo cual juega un papel muy importante en animaciones localizadas de corto recorrido como las de Goldeneye o Perfect Dark.

Este cubo sirve como ejemplo en la diferencia de fluidez
https://www.youtube.com/watch?v=pQMCDpomTK8

Sin embargo muchos juegos se programaban en PSX y luego se porteaban a N64 o a PC, muchos tienen tablas precalculadas en enteros que no eran fáciles de traducir, así que incluso algunos juegos de N64 podrían tener animación a saltos, juraría que los Fifa, pero no en el caso de juegos exclusivos.

En este link se puede leer que causaban hasta bugs en el sistema de colisiones del escenario.

Otra cosa es la ausencia de Z-buffer que hace que los polígonos se peleen entre sí para ver cual se pinta delante, básicamente van con un listado que se reorganiza en cada frame, pero que no es eficaz desde todas perspectivas y tamaños de un polígono, esto es algo que en N64 hacen también manualmente en el World Driver Championship, pero claro es una maquina con mejor precisión de datos, con corrección de perspectiva y permite polígonos gigantes, reduciendo ese listado y por tanto la probabilidad de error, apenas se nota que no usan Z-buffer.

De todas formas Goldeneye y Perfect Dark tiran mucho de CPU, la llevan al limite, que sea una CPU de casi 100mhz ayuda y mucho a que estos juegos fueran así de complejos.
--

Otra cosa que vengo leyendo es que se comenta que N64 no puede poner texturas más allá de sus 4KB de texturas, lo cual no es del todo correcto.

El rasterizador básicamente pinta lo que le metas en esa memoria, el como es absolutamente programable, puedes estirar la textura a todo el polígono, puedes hacer un tileado y puedes interrumpir ese tileado para recargar otra textura.

En PSX por ejemplo se usan páginas de textura, se puede cargar una página de textura en la VRAM de un tamaño máximo de 256x256 (trabaja con datos de 8bits), luego esa imagen se descompone "automáticamente" en bloques de cache de 2KB, que es la cache de texturas de PSX, generalmente los juegos ya se diseñan con texturas que caben en un solo paso cuando buscan rendimiento y todo eso accediendo solo a un pozo de 1MB de datos, este proceso en N64 es manual principalmente porque tienes 4 o 8MB de datos globales, hay código, hay framebuffer, hay texturas, hay sonido en esa memoria.

Por poner un ejemplo tenemos las texturas de Donkey Kong 64, son de 128x128, obviamente no caben en los 4KB, muy probablemente sean 4 texturas tileadas de 64x64.


Y para renderizarlas podrían usar un algoritmo inteligente de salto impar, para no tener que recargar una, luego la otra y luego volver a la anterior, lo cual desciende mucho el rendimiento, se habla de la mala latencia de la RAM, pero la cache va como un rayo, no lo he mirado a fondo pero podría ser una opción.

El tema de las textuas en Nintendo 64 me ha interesado mucho desde que empecé a hace mapas para GoldenEye y Perfect Dark.
Claramente la caché de 4 kB es una limitación muy grande (como mucho te permite texturas de 32x32 de 8 o 16 bits de profundidad de color con todos los efectos activados). Creo que 8 kB tampoco hubiese sido suficiente, y que 16 kB sería el tamaño ideal. Pero texturas 4 veces más grandes requieren un almacenamiento 4 veces superior y más memoria RAM para poder manejarlo todo. Quizás no pudo hacerse mejor en aquellos años.

He investigado muchos juegos juegos que aparentemente tienen texturas que superan la limitación de la caché y siempre me he encontrado que dichas texturas en realidad son imagenes compuestas por varias texturas encajadas en varios polígonos. Por ejemplo, las texturas de las rocas y las palmeras del Donkey Kong 64 que ha puesto en el mensaje anterior BMBx64 son en realidad 4 texturas de 64x64 y 4 bits de profundidad (16 colores) que forman una imagen de 128x128 píxeles y de más de 50 colores. Un curro soberbio.
El problema de hacer esto es que necesitas más polígonos para plasmar estas texturas. Éste es otro ejemplo similar del Donkey Kong 64. Observad que la imagen total se compone de 6 texturas (dos a la ancho y 3 a lo alto) también de 64x64 y 4 bits de profundidad de color y que se emplean 12 polígonos para plasmarlas.


Una de las ventajas que tiene la Nintendo64 respecto a la primera PlayStation es que puede repetir una textura en un mismo polígono una gran cantidad de veces (hasta crear una imagen de 2048 x 2048 píxeles). Esto permite usar polígonos gigantes, repetir la textura muchas veces para tener una imagen nítida y ahorrar una burrada de carga poligonal.
Supongo que PS1 puede hacer lo mismo pero sin corrección de perspectiva ni precisión subpíxel el resultado es desastroso, tal y como puede verse en este vídeo que simula cómo se vería el Super Mario 64 en la primera consola de SONY.
https://youtu.be/TuH7RDIDZN4?t=1m48s

Para disimular estos problemas la PS1 usaba varios polígonos para plasmar una única repetición de la textura, por lo que su gran poderío a la hora de generar polígonos en espacios abiertos quedaba anulado
.
Sin embargo en entornos más cerrados como juegos de carrera o en el modelado de los personajes como en los juegos de lucha era donde las características de PS1 destacaban.

En resumen. Que estas "texturas de 128x128" que pueden verse en DK64 y muchos otros juegos tardíos de RARE requieren de una gran cantidad de polígonos para poder lucirlas y precisamente la N64 no va sobrada en ese aspecto. Hay que tenerlo todo muy bien pensado para que el resultado final no cogee de ningún lado, pero por suerte los desarrolladores de RARE eran unos genios.


En GoldenEye ya se pudo ver un ensayo de esto en el nivel de Aztec.
-La sala donde empiezas. Los iconos están formados por 4 texturas de 128x47 de 4 bits en escala de grises. La diferencia entre las texturas en escala de grises y las de color (en 4 y 8 bits) es que no parten la caché por la mitad para almacenar la paleta, permitiendo mipmaps y filtrado trilinear a resoluciones altas. De hecho, 128x47 es el máximo de resolución para este tipo de texturas que permite todos los efectos.
Como veis, un escenario tan sencillo al final requiere de una gran cantidad de polígonos para lucir este tipo de texturas con alto nivel de detalle.



Ahora un detalle de uno de los pilares de la sala. Normalmente los ladrillos sin dibujo son una textura de 64x64 de 4 bits en escala de grises, pero en este caso una de las caras del pilar tiene una versión en alta resolución de esta textura compuesta por 4 texturas de 128x47. Se puede ver que el dibujo de la textura es el mismo pero que el nivel de detalle aumenta una burrada, porque estamos comparando una textura de 64x64 con otra de 128x188 (en realidad 128x185 porque en las uniones de los polígonos se repiten los píxeles de la textura para que no se note el paso de uno a otro).




Jet Force Gemini también haría un gran uso de estas "multitexturas" y los escenarios adoptarían formas muy orgánicas para aprovechar la gran cantidad de polígonos que se generan. Pero en lugar de utilizar texturas de 16 colores como Donkey Kong 64 o Perfect Dark, inexplicablemente emplearían texturas de 16 bits de color (que no requieren paleta y aprovechan toda la caché, pero alcanzan la misma resolución que las texturas de 8 bits paletizadas ocupando el doble de espacio en RAM y el cartucho).



Realmente la diferencia entre una textura de 16 bits y otra de 8 bits paletizada para estas resoluciones tan pequeñas es inapreciable. Jet Force Gemini podría haber tenido mayor variedad de texturas. Mantener el colorido que ofrecen 256 colores frente a 16 ya es una tarea más dificil, pero RARE lo hizo en otros juegos como ya hemos visto. Con algo más de trabajo, JFG podría haber tenido texturas con un nivel de definición 4 veces superior.

Las texturas también se pueden "espejar" y es algo que algunos juegos utilizan muy bien como Rush 2049. Lo bueno de estas texturas espejadas es que también pueden repetirse gran cantidad de veces en el mismo polígono y se pueden espejar tanto en vertical como en horizontal al mismo tiempo.



Es algo que ya hacía Super Mario 64 en la rosa de los vientos.



Si os fijáis las texturas de los cuadros que dan acceso a los niveles están formadas por dos texturas de 64x32 con 8 bits de profundidad de color. Este tipo de texturas no permiten mipmaps ni por lo tanto filtrado trilinear, pero como no las vamos a ver desde mucha distancia no se van a pixelizar al hacerse pequeñas.
Sin embargo, los retratos de Bowser y Peach están formados por cuatro texturas de 32x32 de 8 bits de color que sí permiten mipmaps y además comparten la misma paleta. Gracias a esto se consigue el efecto del retrato cambiante. La textura original es la cara de Bowser pero los mipmaps son los de la cara de Peach. No los genera la consola como en la mayoría de los casos, sino que los propios desarrolladores lo han asignado así. Al ver el cuadro desde la distancia y ser el tamaño de las texturas en pantalla más pequeños que su resolución, se activan los mipmaps y por tanto se ve la cara de Peach. Según nos acercamos se transiciona a la textura original y se ve el retrato de Bowser. Al conocer esto pude replicar el efecto en mi conversión del mapa a GoldenEye:



Vídeo del truco corriendo en la consola



Con todos estos ejemplos creo que queda claro que no hay texturas de más de 4kB. Me quedaba la duda de los fondos, pero todos los que he visto recurren a polígonos estirados que ocupan toda la pantalla para colocar trozos del fondo.





Los fondos del Super Mario 64 son alucinantes, creados a partir de imágenes de 256 x 256 píxeles, pero casi ninguno luce tan bien en el juego final.



BMB64 dice que algunos fondos están directamente dibujados por la CPU. Creo que se refería al fondo del menú de StarCraft 64 que está a 640x480 y supongo que 16 bits de color.
Me pregunto si se puede combinar un fondo de esos en una parte jugable. Por ejemplo, en un juego de lucha para que se vea como el Tekken 3 de PS1. No ahorraríamos muchos polígonos para el fondo y poder usarlos en los personajes, pero igual dibujar el fondo con la CPU sería contraproducente.

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

Hay varios juegos de Nintendo 64 con popping de escenarios. GoldenEye tiene alguna parte donde se nota.



También la distancia de dibujado puede quedarse corta en ciertos puntos de Archives. Se nota mucho menos en la consola original.



Que por cierto, tanto en Perfect Dark como en GoldenEye hay algo parecido al listado que PS1 utiliza por la ausencia de Z-Buffer. No creo que esto signifique que estos juegos no usen Z-Buffer, pero debe de ser algo complementario.
En escenarios se usa principalmente cuando hay polígonos con texturas con transparencias. Los polígonos se renderizan en orden y puede darse el caso de que algo que esté detrás aparezca delante de otros elementos transparentes. Esto se ve muy bien en barandillas o en el nivel de Cradle.



También puede ocurrir en objetos y armas aunque sean polígonos sólidos. La verdad es que conseguir que quede perfecto da auténticos quebraderos de cabeza, y en escenarios puede ser imposible de arreglar para todos los puntos de vista.

En PD se ve que tuvieron más cuidado a la hora de colocar este tipo de elementos, pero en la primera barandilla baja que de la azotea del edificio DataDyne puede verse.

Buen aporte

Si lo que quieres decir es que no puede renderizar más de 4KB de información por paso eso es correcto.

Pero puedes interrumpir la repetición de texturas recargando otra en la cache de texturas, lo que pasa es que es muy difícil de controlar, invertir el espejado no es tan difícil pues ya viene implementado en las funciones de la libultra, es algo mucho más genérico y concreto, ahora si quieres recargar texturas se debe hacerlo todo a mano.

En mi motor 2D me sale más a cuenta buscar en el array de pantalla cuantas texturas se van a repetir y renderizarlas de una vez, que recargar textura por tile, sin embargo no en todas las condiciones se consigue mejor rendimiento con esto, sobretodo en mapas donde la mayoría de tiles son distintos, así que tengo varias configuraciones de renderizado dependiendo del mapa.

Esto hablando de 2D, en 3D debe ser aún más difícil de controlar y entiendo que separen las texturas con polígonos, así es como funcionan la mayoría de motores, es decir no solo en tu aporte de ahora, en el anterior ya se veía como funcionaba Perfect Dark, también asumo que cargar con 100 o 200 polígonos más el escenario no es demasiado problematico, el Fighting Force 64 ya invierte 700 en el suelo, principalmente porque es como lo hace PSX, pero no es lo más óptimo en N64 sin embargo lo que más aumenta el polycount son los objetos 3D, en PSX la recarga de texturas se hace desde la VRAM en formato propio y es mucho más fácil de controlar, pero tampoco me consta que se lea y pinte desde VRAM se pasa a su cache de texturas.

En cuanto pintar en el framebuffer con la CPU se podría hacer, pero yo no lo haría desde luego xD, no en un juego 3D, de hecho la libdragon viene con ejemplos donde limpian el framebuffer con la CPU, limpiar el framebuffer si la pantalla se va a renderizar al 100% tampoco es necesario.

Soy un analfabeto total en lo que se refiere al funcionamiento de las máquinas.
Puedo llegar a entenderlo si alguien me lo explicase paso a paso y puede que incluso ya conozca algunos terminos por separado, pero ni idea de cómo relacionarlos.

¿Qué es eso de las texturas por pasos o interrumpir la repetición y recargar otra? Entiendo que te refieres a que si en un polígono dices que la textura se repite dos veces (UVs de 0 a 2), hay una forma de programar que en la segunda repetición en lugar de usar la misma textura te la cambie por otra. ¿Es algo teórico o se ha hecho en algún juego? ¿Y en cuestión de rendimiento cómo se compararía con el método tradicional de meter más polígonos?

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

Mi búsqueda en esto de las texturas era por saber si había algún juego que pudiese meter en un polígono una textura que superase los 4kB de la caché.
Por ejemplo, quiero hacer una habitación y gastar tan solo 2 polígonos para el suelo que formen un rectángulo y repetir una textura de baldosas en él. Las posibilidades más comunes son texturas de 8 bits de color de 32x32 de resolución y texturas en escala de grises de 4 bits de color de 64x64, que son las texturas más grandes que caben en la caché y te permiten usar mipmaps.
Hay que tener en cuenta que para que una textura pueda repetirse sus dimensiones tienen que ser potencia de 2. Una textura de 48x48 si intentas repetirla te va a crear píxeles de basura hasta llegar a los 64 píxeles y luego te pondrá la textura bien. Una textura de 64x48 se repetiría bien en horizontal pero obtendrías basura en vertical. Lo bueno es que se puede espejar una vez sin obtener basura.
Así que lo que yo busco es algo así como una textura de 128x128 que me permita repetirla varias veces en esos dos polígonos.

Más concretamente. Si la habitación mide 4'80 x 6'40 metros y cada baldosa tiene 40 cm de lado, una textura de 32x32 en la que hay dibujada una baldosa tendría que repetirla 12 x 16 veces y todas las baldosas se verían igual. Con una textura de 64x64 podría hacer 4 baldosas diferentes con el mismo nivel de detalle y la repetiría 6 x 8 veces. Sin la limitación de la caché podría tener una textura de 128x128 que me permitiría hacer 16 baldosas diferentes y darle mucha variedad al suelo, repitiéndose 3 x 4 veces en esos dos polígonos. Para lograr lo mismo con la limitación de la caché necesitaría contruir el suelo con 384 o 96 polígonos.

Ahora mismo estoy haciendo un mapa que tiene una gran extensión de hierba y mucha distancia de dibujo, por lo que el patrón de la textura se repite una barbaridad y tampoco es que se diferencien las briznas de hierba, jeje. Estoy usando una textura de 64x32 en 4 bits de color, pero voy a probar con una textura de 64x64 en escala de grises pintada de verde a ver si obtengo un mejor resultado. Me vendría de perlas algún método para meter texturas más grandes. La carga poligonal ya es muy alta y no puedo renunciar al filtrado trilinear porque sin él todo sería un amasijo de píxeles.

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

Aumentar el número de polígonos en el escenario no es demasiado traumático en entornos cerrados y donde la carga poligonal se puede controlar mejor. Ya hemos visto que un soldado de GoldenEye con su arma son unos 460 polígonos, así que gastar 500 polígonos en una habitación en lugar de 40 por poner números al azar sería el equivalente a renunciar a un enemigo. También hay que tener en cuenta que un escenario requiere menos recursos que un personaje que tiene IA, animaciones y puede que iluminación propia

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

Una cosa que quería meter en mi mensaje anterior pero que al final se me pasó respecto a cómo trabajan las texturas N64 y PS1. Usaré el Resident Evil 2 como comparación.



Las texturas de PS1 tienen mayor resolución. La textura de la cabeza tiene 127x104 píxeles mientras en Nintendo 64 se emplean dos texturas de 32x64 que formarían una imagen de 64x64.
Obviamente no hay ningún polígono ni en la versión de PS1 ni en la de N64 que contenga la textura completa. El modelado de la cabeza de Claire seguramente esté formado por varias decenas de polígonos. Para Nintendo 64 podrían haber respetado la resolución original de la imagen con texturas de 64x32 y 64x8 tal que así.



Siempre se dice que la memoria del cartucho está tan llena que ya no cabe nada más. De haber tenido más espacio se podrían haber conservado todas las texturas como en el original, aunque el filtrado bilinear disimula muchas carencias.
Siempre me hizo gracia que se destaque la resolución de la textura de la cara en PS1 cuando la mayor parte del tiempo va a estar renderizándose a un tamaño muy inferior y sólo en los primeros planos se le sacaría provecho. E incluso en los primeros planos, con el baile de píxeles que mostraba la PS1, sería más agradable en la versión de N64.

La cuestión es. Ya hemos visto que N64 no podría manejar una textura de ese tamaño en un único polígono. ¿Pero podría la PlayStation o también está limitada por su caché de 2 kB?

Sogun escribió:¿Qué es eso de las texturas por pasos o interrumpir la repetición y recargar otra? Entiendo que te refieres a que si en un polígono dices que la textura se repite dos veces (UVs de 0 a 2), hay una forma de programar que en la segunda repetición en lugar de usar la misma textura te la cambie por otra. ¿Es algo teórico o se ha hecho en algún juego? ¿Y en cuestión de rendimiento cómo se compararía con el método tradicional de meter más polígonos

Bueno, todo lo que hace el RDP es pintar de la información que hay en la cache, pero por si solo el rasterizador no hace nada, hay que ir enviándole instrucciones y ahí entra el engine / librerías.

El problema es que no sé a que nivel maneja el engine que usas el hardware de la consola y cuales son sus limitaciones, si usas todo a partir de un editor o programas de alguna forma sobre ese engine, en ese caso el experto eres tú , yo te puedo comentar de mi experiencia programando directamente sobre el RDP en C.

La idea de usar la cache de texturas es con la intención de que se repitan para acelerar el pintado, luego está la limitación, el RDP lee de ahí y no de otro lado, tienes que ir enviándole la información en "bloques" o piezas, esos bloques son las texturas de tamaño concreto que comentas, pero al RDP eso le da igual, si lo pones en modo primitivas (modo fill color) te va a pintar cualquier tamaño pues usará un color en lugar de información limitada de una memoria temporal, internamente se puede manejar de diferentes maneras, con polígonos tal y como dices puedes formar un conjunto de texturas "más grande".

Si por cada paso vas recargando una textura, sea un tileado 2D (por ej.) o en distinto polígono no le estás sacando partido a esa memoria y estás accediendo más veces a la RAM de peor latencia, es decir la cuestión no es si una imagen grande se divide en varios polígonos o no, la verdad es que no lo tendría que haber explicado por ahí, sino más bien que simplemente una imagen se puede "trocear" para trabajar con las limitaciones de cache de diferentes maneras.

También cuando recargas una textura tienes que hacer una serie de pasos, comprobar si el RDP está listo para recibir instrucciones, limpiar la cache de la textura anterior, cargar la nueva, a no ser que la textura ocupe lo mismo, esto en un frame se puede llegar a repetir tantas veces como texturas diferentes se quieran mostrar reduciendo el rendimiento.

En Super Mario 64 por ejemplo esos fondos se ven mal porque se estiran más de la cuenta, si hubieran usado unos más grandes ocuparían más espacio en el cartucho, que esa es otra de las limitaciones.

En lo que comentas de RE2 coincido, por las extracciones los modelados eran iguales, luego la representación de texturas juraría que se ven mejor en la ropa en el caso de PSX, pero no en pequeños polígonos, el escudo de Leon del hombro por ejemplo se ve mejor en N64 y otros detalles que requieren de más precisión.

En muchos juegos con escenarios abiertos en 3D no pasan de las texturas de 64x64 y 16 colores, que viene a ser lo mismo que en N64, caber en la cache para repetirse y acelerar renderizado, por otro lado no dejan de ser maquinas limitadas de fillrate.

Menudos cracks, me pierdo, supongo que sois programadores y sabeis del tema... A ver si os animais a abrir otro hilo pero de Game Cube!

Siempre tengo presente la calidad de las texturas de Banjo Kazooie, que aún sin hacer uso del Expansion lucen formidables y el juego está repleto de detalles que jamás se vieron en las consolas de 32-bit.

Probe, Iguana, Rare y Factor 5 para mí el cuarteto que más partido le sacaba al hard de la 64.

Sentía curiosidad por ver como se veía RE2 en mi tele en N64 con RGB mod y PS3 con HDMI (RE2 PSX), la captura es un poco horrenda en cuanto a colores.

Las extracciones del framebuffer en el caso de RE2 eran solo correctas para los escenarios pero no para los modelados, a juzgar por los dientes de sierra la resolución es muy distinta, también el traje cambia un poco, parece un chaleco antibalas en N64, los patrones de ropa en PSX son como simétricos, por ejemplo las piernas, en N64 hacen una cosa rara como aprovechando diferentes trozos de textura de aquí y allá para componer el cuerpo, se nota que iban al límite de espacio con el cartucho, es curioso que la cara se vea mejor a pesar de tener la mitad de resolución de textura prácticamente desde todos los ángulos, el escudo del hombro en N64 solo se ve al ponerse de perfil.


Sobre el tema de como configurar el rasterizador he encontrado 2 ejemplos que olvidé comentar.

En el Fifa 99 por ejemplo el tablero del campo está formado por muchos polígonos, sin embargo no se usa un polígono para cada color de césped del campo como se podría intuir, sino que éste se sitúa en el centro de los 4 colores.


En ISS98 usan polígonos gigantes con tileado de texturas, a destacar como configuran el RDP para sombrear la textura del campo sin aplicar polígonos extra.


No son aportes demasiado buenos, pero prometí traerlos de todas formas..

COPA DEL MUNDO FRANCIA 98
He descubierto algo interesante con las canciones de este juego, resulta que siempre se cortan sobre el minuto o así y van sonando en una sucesión de forma aleatoria mientras estamos en el menú, hasta ahí bien.

Si presionamos volumen en opciones cuando la canción está haciendo el fundido para cambiar a otra forzaremos a que siga sonando, resulta que la duración de las canciones va mucho más allá, en algunas precisamente los trozos recortados son la mejor parte con secciones totalmente distintas.


He buscado un poco en internet y no hay nada al respecto, la música subida a diferentes sitios viene con el recorte que hace el juego, en la intro si tendría sentido pues es un sample metido en un cartucho de 12MB, pero no en el resto de canciones, un misterio..
https://www.youtube.com/watch?v=yOYdQKfffEE

PORTS DE DOOM 1 Y 2
Es un port de Doom Source (el código original liberado por ID) para N64 usando la libdragon, puede correr los WADs de las versiones shareware como de las completas, el port cobra sentido cuando Doom 64 es algo completamente distinto, como curiosidad también permite el uso del ratón (el que venía con el pack 64DD), el vídeo está grabado del hardware original.
https://www.youtube.com/watch?v=ygIZoTyTygc

CONKER BAD FUR DAY (Betas)
Existen 2 roms del juego que se liberaron hace un par de años con algunas diferencias.

La versión ECTS fue una versión preparada para el evento, en cada slot de partida hay 4 capítulos diferentes, el acceso a opciones y capítulos está bloqueado, aunque se pueden usar códigos para acceder a zonas incompletas, es muy inestable y acaba colgándose tarde o temprano.

La versión DEBUG es una versión más completa del juego y sin algunas censuras que hubo en la versión final, aunque también es algo inestable y no podrá finalizarse de principio a fin.

Dentro de la rom hay cosas tan disparatadas como Hitler o científicos experimentando con soldados en una tétrica escena, son escenas fáciles de encontrar así que dejo 1 sola.
https://www.youtube.com/watch?v=FyC4UL12aBA

También encontramos la cola de Pikachu, el juego tiene una secuencia donde un mafioso le pega una paliza, algo que no gustó mucho a Nintendo.


Es algo que Chris Seavor comentó en Twitter:

Ah yes, the Pokemon tail ! That was part of a cutscene we had to cut.Nintendo weren't too keen on having their baby bashed

Irónicamente Nintendo sacó a sus peluches a darse de hostias en el anuncio de Smash Bros
https://www.youtube.com/watch?v=K783SDTBKmg

La versión debug como era de esperar también tiene un menú para trastear que se activa pulsando los 4 botones amarillos a la vez.


El menú es bastante interesante, no solo tiene los aburridos dumps de memoria, sino también estados y estructuras para entender como se hizo el juego, si se colgara (que es muy probable) podríamos trazar el problema, pues se lanza el debug automáticamente.


Por ejemplo si nos vamos a Task Working podemos ver los eventos que el juego corre simultáneamente, he pausado en la zona del cementerio donde saldrán zombies que tendré que limpiar con una escopeta, esto es básicamente el ID del script que maneja ese evento, siendo 1 script no hay problema pero en otras áreas hay varias misiones simultaneas activas, saber el ID nos permitirá averiguar si hubo un problema al correr un script en concreto.


Los objetos tienen estructuras globales, se utilizan arrays de forma genérica, la lista de variables hace scroll si pulsamos hacia abajo, desde colisiones con Conker a variables de estado como bucear bajo el agua, como era de esperar usan coma flotante para las coordenadas y desplazamientos (comentado en la página anterior).


En esta versión si que se nos permite acceder a opciones y cheats desde el menú principal, escribiendo:
WELDERSBENCH - desbloquea todos los capítulos.
SKIP CUTSCENES - salta o permite saltar intros.
INFO - muestra memoria disponible y el framerate.

En zonas pequeñas el juego es capaz de funcionar a 30fps sin caídas, como la habitación donde conseguimos la sarten para golpear a la llave.


Aunque generalmente el juego se moverá a 20fps, con picos a 30fps al llegar a los rincones del escenario y con caídas que van desde 15 a 7 fps al girar la cámara bruscamente en zonas muy cargadas.


VRU
Unidad de reconocimiento de voz lanzada en el 2000, solo disponible en América y Japón.


1) Se conecta en el puerto número 4 de la consola, no puedes conectar un VRU japonés en una consola americana.
2) Solo hay 2 juegos que le saquen partido al aparato, venía incluido en Hey You Pikachu!
3) Existen complicaciones para detectar voces adultas.

Bio Sensor
Se trata de un accesorio con aspecto de controller pak, es no oficial pero licenciado por Nintendo.


1) Venía con el cartucho Tetris 64 y solo salio en Japón en el 98.
2) El juego tenía un modo "bio" donde según las pulsaciones del corazón aumentaba o reducía la velocidad de juego, detectaba trampas como ausencia de pulsación o cambios demasiado bruscos.

Perfect Head
Una función descartada de Perfect Dark que permitiría al jugador escanear su cara y ponerla en el juego mediante 2 accesorios, el Transfer Pak que permite conectar cartuchos de GB/C y Gameboy Camera, la cámara tomaba fotos en resolución 256x224 aplicando antialias internamente y reduciéndola a 128x122 a 4 colores de escala blanco y negro en la Gameboy original.

Haciendo búsqueda sobre la rom no queda código de la función, pero sí de alguno de los mensajes y textos que utilizaba el menú, en las betas existentes del juego tampoco queda rastro, al ser muy cercanas de la versión final.


--
Ojo al baile de Donkey Kong


Y una fumada de Super Mario 64, el funcionamiento de las monedas explicado de una forma científica
https://www.youtube.com/watch?v=iPILIf7ru48

En el caso del VRU, ¿Se sabe el motivo por el cual un VRU JAP no funciona en una consola USA? Para los cartuchos ya se sabe que cambiaron de sitio las patillas de la consola, pero quitandolas en una consola NTSC ya sea JAp o USA se pueden usar juegos de la otra zona NTSC, ¿El VRU lleva algun hardware dedicado a ese control?

@BMBx64 Hace un par de dias pusieron algo de una moneda imposible en Mario 64, ¿has visto algo de eso?

Adiós EOL, una pena en lo que os estáis convirtiendo.

Saludos.

Sí, lo de las monedas está puesto al final del post, me pregunto si no hay forma de poner vídeos de youtube que aparezcan de forma directa en el foro en lugar de un link

ALCAMJI escribió:En el caso del VRU, ¿Se sabe el motivo por el cual un VRU JAP no funciona en una consola USA? Para los cartuchos ya se sabe que cambiaron de sitio las patillas de la consola, pero quitandolas en una consola NTSC ya sea JAp o USA se pueden usar juegos de la otra zona NTSC, ¿El VRU lleva algun hardware dedicado a ese control?

Por lo visto el juego también lee de que región es el VRU, igual además del ID hay algunas diferencias más en el VRU como el DAC, el análisis de voz se hace por software, supongo que el juego de cada región tendrá una forma distinta de analizarlo.

BMBx64 escribió:Sí, lo de las monedas está puesto al final del post, me pregunto si no hay forma de poner vídeos de youtube que aparezcan de forma directa en el foro en lugar de un link

El iconito de la flecha que aparece al final de los enlaces de Youtube sirve para ver los vídeos en el propio hilo

ah vale, no me habia dado cuenta.

hay rom compilada de doom1 y doom2???

@BMBx64 tambien una duda que me asalta, oficialmente el expasion pack es de 4MB, subiendo a 8MB el total de la RAM, el caso es que recuerdo que algunos fabricantes se atrevieron a sacar expansion pack de 8MB los cuales al final no sirven de nada y se calientan cosa mala, ¿hubieran sido utiles, o con 8MB ya era mas que de sobra?