Hilo de detalles y curiosidades de N64

Aracnoid
MegaAdicto!!!
1.341 mensajes
desde may 2013
en Transilvania
@BMBx64 por casualidad, tu no sabrás como rescatar las partidas guardadas de los cartuchos para poderlas jugar en el emulador (no quiero volver a pasarme todo el Zelda OOT)

Saludos y a seguir con este fantástico hilo!
DiGiCharatFan escribió:@BMBx64 esto lo sabras, que hace esactamente el PIF? a parte de ser el CIC seleccionando la región.

Lo digo poruqe en el grafico donde se meciona pone PIF CONTROLLER, que mas controla?


En ese bus tienes SI(serial interface) y PI(peripheral interface), se usa SI para enviar instrucciones directamente a la RAM de PIF, puede leer / detectar mandos y los periféricos como la memoria o el rumble, también controla el botón de reset y como bien dices lee la protección de los cartuchos, se retorna un resultado que rellena los registros de SI para usarlos después.

Aracnoid escribió:@BMBx64 por casualidad, tu no sabrás como rescatar las partidas guardadas de los cartuchos para poderlas jugar en el emulador (no quiero volver a pasarme todo el Zelda OOT)

Saludos y a seguir con este fantástico hilo!


Cartucho original o flash? Aún así el Zelda OOT tiene bastantes cheats para situarte casi donde quieras. [360º]
--

GEOMETRÍA
Existe un plugin (lemD3D8) que en modo debug permite hacer un dumpeo de la escena poligonal presente, su único problema es que hace a su vez de render gráfico, la compatibilidad con los juegos y los detalles están limitados a ese plugin concreto, si bien existen herramientas que sacan los modelados del DirectX, pero este sirve para generar escenas globales.

Si se quiere saber la cantidad exacta que se renderiza por frame es necesario tener en cuenta el descarte de polígonos que quedan tapados, eso varía de un juego a otro, de un micro código a otro, los personajes mostraran más polígonos estando de cara que de espalda, pues muchos se concentran en el rostro y otros detalles frontales.

El plugin no saca solo la información de la cámara, sino toda la geometría cargada en ese momento, incluso la que no vemos, esta es la fase del desierto de Mario 64, como se ve el juego es muy simple en ese aspecto, todo ese mapa no llega a 2000 polígonos, el protagonista de Turok 2 contiene más, como se vio páginas atrás.
Imagen

En Goldeneye utilizan cerca de 460 polígonos por soldado (en esta escena he eliminado todo salvo el soldado).
Imagen

Aunque lógicamente no todos van armados con el mismo rifle (o llevan sombrero), así que lo he separado del modelado, 52 triángulos, se puede deducir por tanto cuanta geometría mueve un NPC cuando va desarmado.
Imagen

Lo óptimo son unos 3000-3500 polígonos por frame, como podemos imaginar aquí se esta triplicando esa cifra y la consola sufre, no solo por geometría, el código de colisión, IA y física de tanto soldado a la vez.
Imagen

Ahora Perfect Dark, la cámara esta situada un poco más arriba del brazo, existe el modelado del brazo al completo, el arma y la mano, además del puntero láser, tanto en el arma como en el cuerpo del enemigo.
Imagen

Ya solo la mano y el arma son 527 polígonos.
Imagen

Hay mejora en los enemigos, en Perfect Dark los modelados tienen más polígonos, una mejor distribución en el cuerpo y en la cara, los soldados usan 200 polígonos más que en Goldeneye.
Imagen

Los resultados de Fighters Destiny 2 son un poco decepcionantes, en escena completa el juego mueve unos 2000-2200 polígonos, los escenarios constan de unos 50-100 polígonos, si interpretamos el framerate y la escena nos salen unos 60-66K, hay juegos por encima de ese rango.
Imagen

Si descartamos el escenario y el otro jugador vemos que los personajes apuntan a un modelado de rango 900 pol, eso es sin contar la sombra, la cual consume 108 polígonos en este caso, si sumamos 2 luchadores de 1000 tendríamos esos 2000, con ese poco margen de detalle para escenarios o partículas que no suceden en esa captura de render.
Imagen

En Mace por ejemplo hay más detalle en los escenarios, desde este angulo que he cogido el escenario parece un estudio de grabación [sonrisa] , cerca de 2000 polígonos solo para el escenario.
Imagen

Y los personajes tienen una geometría similar, 1019 en este caso, que sigue estando en el rango de los 1000, aunque el bajo framerate hace que sea mejor elección el estilo de Fighters Destiny (y probablemente entra en juego la manera en la que esta escrita el código), la cuestión es que hay geometrías muy superiores en juegos de otros géneros, sin Namco sacándole jugo a la consola es difícil imaginar que podría haber salido de exprimirla un poco más en este género en concreto.
Imagen

Ahora un vistazo a Fighting Force, según las cifras extraídas del Fighting Force de PSX que supuestamente es la misma geometría serían 3024 pol/frame (en PSX se pueden saber cifras exactas de renderizado).
Imagen

He borrado todo excepto 2 personajes, la chica tiene 600 polígonos, parece que el juego mueve ese rango para los personajes e igual o algo menor para los enemigos.
Imagen

Ahora veamos el despilfarro del suelo, 770 polígonos, sabemos que la consola puede usar polígonos muy grandes gracias a la corrección de perspectiva, o incluso Saturn hace una especie de modo7 o plano abatido en muchos juegos donde el suelo es simplemente una superficie plana para no renderizar esa cantidad innecesaria (como en la beta de este juego).
Imagen

Un vistazo al campo de Fifa 99, resulta interesante ver que faltan jugadores o incluso la portería, en ese momento la cámara estaba picada enfocando a una pequeña región del campo, es de imaginar que los objetos dinámicos como jugadores los recoloca fácilmente en el campo cuando sea necesario.
Imagen

Y que hay de los jugadores? 320 polígonos aprox. al menos con este tipo de rostro, peinado, etc, si nos fijamos en su sombra no están haciendo el método de FD2 o Mace, sino que están usando un buffer interno para representarla.
Imagen

Conker son 1200 polígonos, en el LOD más cercano (el de la intro)
Imagen

Conker justo antes de entrar a la taberna, la geometría a nivel global de escenario sería 6 veces superior a Super Mario 64, esto es sin descarte poligonal, habría que deducirle cerca del 30%
Imagen

548 polígonos el prota de Misión Imposible.
Imagen

Los modelados de Pokemon Stadium 2 son bastante normales en geometría, pero están muy bien hechos con esa cantidad, Steelix son 714 polígonos.
Imagen

Los renders los estoy sacando o bien en wireframe o en flat shading para que se vean las caras, aunque en los juegos están usando sombreado goraud que quedan más redonditos, además de mejor iluminación y color.
Imagen

Por cierto los wires engañan bastante si no se sabe la tasa de frames, en Mortal Kombat 4 los escenarios son más complejos que Fighters Destiny, con columnas o estructuras simples, todo eso sería bajo si no fuera porque el juego va a 60fps, como curiosidad la sombra es la misma para todos los personajes.
Imagen
Aracnoid
MegaAdicto!!!
1.341 mensajes
desde may 2013
en Transilvania
Editado 1 vez. Última: 7/06/2016 - 19:52:17 por Aracnoid.
Aracnoid escribió:@BMBx64 por casualidad, tu no sabrás como rescatar las partidas guardadas de los cartuchos para poderlas jugar en el emulador (no quiero volver a pasarme todo el Zelda OOT)

Saludos y a seguir con este fantástico hilo!


BMBx64 escribió:Cartucho original o flash? Aún así el Zelda OOT tiene bastantes cheats para situarte casi donde quieras. [360º]

Cartucho original, el tema seria copiar la partida del cartucho original y meterla para jugarla en emulador y/o en flashcard.

¿Como se pondrian esos cheats tanto en emulador como en flashcard?

(Buenísimo el último post)

Saludos y gracias
Aracnoid escribió:Cartucho original, el tema seria copiar la partida del cartucho original y meterla para jugarla en emulador y/o en flashcard.

¿Como se pondrian esos cheats tanto en emulador como en flashcard?


Te pongo la opción más fácil, en el emulador PJ64 cuando cargues Zelda OOT te vas a sistema/cheats y debería salirte una lista, en "have" eliges el inventario y el juego te deja progresar según las cosas que vayas añadiendo, si lo editas bien puedes dejarlo bastante parecido a la partida que tengas en el cartucho. [oki]
Imagen

--

LIBULTRA Y MICRO CÓDIGOS
Dentro del RCP hay el RSP para cálculos y otras instrucciones, con 4KB para código personalizado y el RDP, el rasterizador.

Para crear una escena 3D hay toda una serie de pasos para asegurar un buen rendimiento.

Scissoring box
El rasterizador elimina las porciones que quedan fuera de esta caja, esto puede usarse como pantalla, como el típico mapa o radar en una región de la pantalla,etc

Reject box
Imagen
Es otra caja del tamaño relativo a la pantalla, se puede elegir de proporción 1 a 6.

Lo que hace es rechazar los polígonos que salen de esa segunda caja, con que sea 1 solo vértice todo el polígono entero será descartado antes de ser renderizado, esto choca con la idea de querer usar polígonos muy grandes para grandes superficies (algo que se puede ver en el render de Super Mario 64), sin embargo los escenarios se configuran en modo clipping y no llegan a salir de la pantalla pues se subdividen, viene después explicado.

Cabe destacar que estas cajas solo determinan coordenadas X/Y, para Z existe otra variable de profundidad.

Jet Force Gemini tiene un buen ejemplo en la pantalla de selección de personaje, la cámara gira alrededor de los personajes, decidieron que lo mejor para componer la escena era un ratio de 6:1.
Imagen

Zelda Majoras Mask usa 2:1, si nos fijamos en el lado izquierdo la función de rechazo ya se ha comido unos cuantos triángulos que eran paredes rectangulares, por otro lado la máxima geometría que puede mover el juego sin tener caídas de rendimiento parecen ser 4000/pol frame, como nota el juego se ahorra el algoritmo de frameskip cuando funciona a 20fps y en los primeros frames de caída.
Imagen

3D Clipping
Consiste en recortar un polígono subdividiendolo en 2, el margen de maniobra es el espacio muerto entre la caja de recorte de la pantalla y la de rechazo, es decir si un triangulo está mitad dentro de la pantalla la parte que queda fuera de la pantalla es eliminada tras ser subdividida, esa es la idea, que el rasterizador no pierda tiempo.

Sin embargo todo esto consume recursos y hasta la propia Nintendo lo desaconseja para uso global.
3D clipping is expensive and should be avoided. Methods employed by the host application which can reduce the amount of geometry that gets clipped are a good idea. Crude visibility determination algorithms, geometric level-of-detail, and careful scene construction can help improve clipping performance dramatically.

The clipping algorithm is sensitive to large numbers and overflows.


Es de suponer que juegos donde usen polígonos pequeños para formar el escenario usen un ratio de descarte algo más grande pero eviten clipping como Fighting Force (porque muchos polígonos serían subdivididos en muchos más, lo cual también aumenta el polycount a nivel interno) y juegos como Castlevania 64 que usa pocos pero gigantescos le saquen más partido a esto con el clipping.
Imagen

Back-Face Polygon Culling
Es lo que permite establecer que caras están delante y cuales detrás con respecto a la posición de la cámara, permite descartar polígonos que queden detrás de un modelado.

Veamos un ejemplo, que es todo este desastre de lineas? Efectivamente vuelve a ser Conker.
Imagen

El wire es esta escena (con framerate incluido)
Imagen

Vamos a darnos una vuelta por el buffer enviado a DirectX.. como se puede ver al modelado de Conker lo han troceado cuando mira en primera persona pero eso es parte del proceso de rechazo fuera de pantalla, dando una vuelta se puede ver que hay algunas caras descartadas de la geometría que pintan, recordemos que esta rutina es efectiva para los polígonos que tienen un set "back-face" el cual es dinámico, si damos la vuelta al objeto ya no será la parte de atrás sino la de delante, todo esto necesita de cálculo.
Imagen

Ahora sabiendo que el clipping requiere mucho cálculo que recomienda Nintendo? Como ya se comento lo que trata la geometría son los micro códigos, cuando se habla de Fast 3D o F3DEX es una serie de micro códigos, luego hay unos cuantos especializados para distintas tareas que hay que cargarlos de forma secuencial.
Because microcode loading increases overhead, discretion in loading is recommended to obtain good performance. For practical purposes, this means intermittently switching between the microcode types used for rendering. As an example, a clip-capable microcode such as F3DLX would be used for rendering landscapes and fast microcode such as F3DLX.Rej used for rendering characters. As with previous releases, switching between F3DEX and L3DEX when rendering lines can be done without CPU involvement.


F3DLX tiene todas las funciones de clipping y culling, se aconseja para escenarios, que son los que usan polígonos grandes y superficies donde hay que rellenar muchos pixels, para realizar las funciones también necesita recopilar información previo paso y realizar muchos cálculos de la proyección de la escena.

F3DLX.Rej para personajes, este código es mucho más liviano pues lo único que contempla es el rechazo de polígonos al salir de la pantalla y no se hace clipping, haciendo G_CULL_BACK aumenta el rendimiento especialmente cuando se acercan objetos a la pantalla pues no se renderiza la parte que no se ve del polígono, G_CULL_FRONT sirve para eliminar las caras que queden demasiado cerca de la cámara, es indispensable eliminar no solo porque taparían toda la imagen sino porque es drástica la caída de rendimiento de cualquier elemento que se acerque demasiado a la cámara, parece que los emuladores no hacen G_CULL_BACK en muchos casos o no queda demasiado claro al sacar las extracciones poligonales, en los emuladores de PSX si que se hace el descarte de caras y las cifras de escena son más exactas.

Otros datos a tener en cuenta extraídos del SDK.
Triangle Rejecting Process
- Triangles which are entirely inside the rejecting rectangle are drawn.
- Triangles which stretch from inside the rejecting rectangle to outside, or those that are entirely outside the rectangle, are rejected.
- The rejecting box is 2-6 times the size of the screen rectangle. By default, the rejecting box is 2 times the size of the screen rectangle. The range can be changed using g*SPClipRatio. Values from FRUSTRATIO_2 to FRUSTRATIO_6 can be specified. In the Z direction (the depth direction of the screen), rejection is performed according to the Far plane. No rejection is performed according to the Near plane.
Please see "Rejection Processing" below, for additional information.
- Because of reject processing, a large triangle may not be rendered if one of its vertices falls outside the screen, even though it should appear in the screen.
- Reject processing with F3DLX.Rej and F3DLP.Rej can allow faster processing of “2 Triangles” commands. When making DL, it is advantageous to use g*SP2Triangles, if possible.
- The gspF3DLX.Rej.o version provides texture perspective correction, while gspF3DLP.Rej.o version does not. F3DLP.Rej is slightly faster than F3DLX.Rej.
- Both F3DLX.Rej and F3DLP.Rej do not support G_CULL_BOTH.


Un ejemplo de como el número de personajes afecta a la geometría sería Tony Hawk 3, al ser un solo protagonista invierte mucho cálculo en la geometría del escenario.
Imagen

Test
Con toda esta teoría vamos a probar un test de ejemplo que viene en el SDK, imágenes extraídas de hardware original.

En el test se pueden elegir diferentes figuras geométricas como cubos o triángulos.
Imagen

La barra de abajo corresponde a los recursos usados de los diferentes componentes, agrandar un objeto más de la cuenta consume mucho más de lo esperado.
Imagen

Este menú corresponde al color combiner, se pueden aplicar colores o texturas a una superficie y otro tipo de combinaciones, el consumo aumenta al poner todo este texto en pantalla, quizás esta siendo renderizado por software?
Imagen

Una buena configuración permite este tipo de efectos.
Imagen

Este es el menú del RSP, aplicar goraud shading le sale gratuito a la consola según este test.
Imagen

Una iluminación básica aumenta algo la carga de recursos, ahora hay que imaginar que pasa en juegos como Forsaken 64.
Imagen

Veamos Forsaken 64 en acción
Imagen

También combina los colores de todas las fuentes y saca tonos intermedios.
Imagen

IGN: Forsaken 64, set for an April 98 release, looks great. Running at 60fps (frames per second) in single-player mode and a smooth 30fps with up to four people playing, it's also fast.

The Nintendo 64 version of the game will feature exclusive new levels and weapons as well as more sophisticated AI (artificial intelligence) than its PC predecessor.


En realidad el juego corre a 30fps en N64, en PC servia como benchmark para las tarjetas gráficas de la época.
Imagen

Con G_CULL_BACK desactivado (lo que descarta polígonos que quedan detrás o tapados) el consumo se dispara, es de imaginar que los juegos deberían tener este set activado, aunque este micro código es realmente antiguo.
Imagen

Con el Z-buffer desactivado hay un ligero aumento de rendimiento pero se producen errores de prioridad en los modelados, habría que hacer un listado manual como en World Driver Championship, no es de extrañar que la mayoría de compañías no se calentaran la cabeza y tiraran de esto aún perdiendo fillrate.
Imagen

2Cycle permite hacer efectos interesantes como los reflejos del agua en Zelda OOT, permite combinar 2 texturas, solo aumenta la carga de proceso del RDP, no del RSP.
Imagen

Imagen

En el menú de VI (Video) tenemos diferentes apartados uno de ellos son correcciones de gama, algo que esta presente en algunos juegos de la consola, activarlo o desactivarlo no supone ningún tipo de cambio de rendimiento y un filtro para el dithering que evita que se vea el tramado de pixels, en este caso activarlo si consume recursos, ahora no recuerdo pero creo que hay juegos que permiten activar o desactivar esto en las opciones.
Imagen

Imagen

Imagen

Optimizaciones para objetos que están parcialmente fuera de la pantalla (Scissoring box, mencionado arriba).
Imagen

Imagen
redribbon
MegaAdicto!!!
4.182 mensajes
desde jun 2001
en B´ham
Impresionantes tus post, de verdad [tadoramo]

Tienes alguna curiosidad que comentar del Diddy Kong Racing? Yo flipé en su dia con él, lo considero bastante mejor que Mario Kart 64, muchos mas circuitos, un modo historia genial con jefes y todo, varios vehiculos, etc

El juego iba fatal de frames en muchos momentos, sabes si con expansión pack iba mejor? Habría alguna posibilidad de jugarlo en algun emulador con unos 30fps estables?
Sí, todos los juegos de Rare tienen cantidad de material curioso dentro de los juegos, se nota que estaban en una etapa muy creativa, el Diddy Kong Racing tiene niveles de test que hasta luego aparecen en Jet Force Gemini, ya miraré de hacer algo más visual.

He seguido añadiendo cosas con la libdragon, el rumble es muy fácil de usar, próximamente OGG lo cual sería un lujo si no consume demasiada cpu.

Me ha dado por revisar cual es el rendimiento de PSX en 2D para ver que tal voy, pues al igual que N64 o bien acepta rectángulos o polígonos planos, el primer caso es mucho más rápido pero no se pueden rotar los sprites.

He comparado un test real de N64 con las especificaciones dadas sobre sprites de PSX, con el siguiente resultado:
PSX: Sprite 16x16 Textura 16bits - 667*60fps
N64: Sprite 16x16 Textura 16bits - 1520*60fps

A falta de compararla con Saturn es una buena bestia en 2D, para no dar demasiado la brasa con detalles técnicos vamos con unas cuantas betas y juegos no lanzados.

BETAS Y PROTOTIPOS

Dinosaur Planet
No hay mucho que comentar teniendo casi una hora de vídeo, tras ser cancelado se le hizo un lavado de cara y acabó apareciendo en Gamecube como Star Fox Adventures.
https://www.youtube.com/watch?v=cOVBRJToVDY

Eternal Darkness
No lucía nada mal en N64.
https://www.youtube.com/watch?v=LWeXnBH8Ohs

También fue cancelado en N64 para acabar saliendo en Cube.
Imagen

Los personajes quedaron bastante puntiagudos y había cierta sensación de port, aunque las cifras de polígonos entran en el rango de lo que sería la generación 128bits, existe una entrevista con Silicon Knights (que ahora no encuentro) donde comentaron que aprendieron a colocar mejor los polígonos para Twin Snakes, en Eternal Darkness podrían haber hecho los modelados usando menos recursos, se especifico que la protagonista principal tenía más de 4000 polígonos, efectivamente revisando el modelo las cifras eran correctas.
Imagen

Una muestra de Alex Roivas en N64 con la misma pose, las animaciones no eran muy diferentes.
Imagen

El juego iba a correr a 640x480*, igual que en Cube, sin embargo a 30fps en lugar de 60, en un cartucho de 32 o muy probablemente 64MB, existen incongruencias con los escenarios, no queda claro si iban a ser en tiempo real o prerenderizados, en muchos casos parecen demasiado complejos para correr en la consola, en una entrevista de IGN del año 2000 se puede leer lo siguiente:

Unlike Resident Evil 2 for Nintendo 64, though, Eternal Darkness runs on a fully 3D engine, enabling complete freedom of movement and, because backgrounds aren't pre-rendered, a totally scalable camera system. What this means for the player is 3D environments that are totally interactive and look beautiful.


Con otro texto que le sigue después
The game utilizes a rock-solid 3D engine that outputs pre-rendered-quality visuals -- and by this we mean extraordinarily detailed textures and polygon models -- but with full freedom of movement and interactivity with the environments.


Si repasamos los vídeos es cierto que hay escenas con movimiento 3D.
https://www.youtube.com/watch?v=koBEIdTuaIQ

Aunque las partes jugables de la beta muestran cámaras estáticas en prácticamente todos los vídeos, con momentos donde la cámara rota (min 1, podría ser precalculado o FMV sobre el escenario?), si bien esta demo es del 99 y la entrevista del 2000, podrían haber cambiado mucho las cosas de una versión a otra o podrían referirse a partes prerenderizadas montadas sobre una base 3D como REmake (para proyectar luces y sombras).
https://www.youtube.com/watch?v=7WIDWoefpAc

Resident Evil Zero
No me lo digas.. otro juego trasladado de N64 a Gamecube, aquí podemos verlo en vídeo presentado en una feria.
https://www.youtube.com/watch?v=-Sb9J8BFma4

Twelve Tales Conker 64
Antes de que el juego se convirtiera en la aventura para adultos que conocemos, no es el clásico vídeo de las cintas promocionales, sino de 30 min (13:16, suena la canción de Jet Force Gemini), cabe destacar lo fluido que se mueve.
https://www.youtube.com/watch?v=M6ceNFV2yz4

Wildwaters Extreme Kayak
Juego cancelado de Looking Glass Studios, aunque algunos detalles lucen bien el juego se ve que estaba bastante incompleto en ese punto.
https://www.youtube.com/watch?v=IpTegSY4HY8

Mini racers
Mismo equipo encargado del juego anterior, este luce en un estado mucho más avanzado, no pudo lanzarse por la caída de la compañía en la bancarrota.
https://www.youtube.com/watch?v=qfjMKoJwc-0

Tamiya Racing 64
Es un prototipo antes de convertirse en "Mini racers".
https://www.youtube.com/watch?v=qggeXAHWcHk

Glover 2
Otro juego cancelado por perdidas de la compañía, especial atención al dialogo del Furby en el 1:45, samples de la gallina del Zelda OOT, cuescos y más.
https://www.youtube.com/watch?v=uV1QfIu8-Sg

Dragon Sword
Casualmente de la misma gente que hizo Glover 64, tiene bastantes bugs aunque es jugable, el vídeo esta grabado de un emulador, pero no hay mucho donde coger en youtube.

En el estado de la beta el juego consiste en ir avanzando y cargarse los totems que van apareciendo, si no nos cargamos los totems irá creando enemigos infinitos además de una barrera que no se puede pasar (algo que no se ve en el emulador), aunque no queda claro la forma en que hay que cargárselos, a veces con varios golpes, a veces parece que toman muchos más, igual hay que golpearlos cuando crean enemigos o cuando se activan ciertos interruptores, en el segundo nivel hubo un totem que por mucho que le golpeara nunca se rompía, si por cualquier motivo mueres, cuando vuelve a salir el jugador se volverá incontrolable, si volvemos al menú y empezamos partida seguirá siendo incontrolable, hay que tener la suerte de hacerlo todo en una sola vida y de alguna forma cuidadosa para que los totems se vayan rompiendo sin problemas.

https://www.youtube.com/watch?v=fh8uKt-LGtU

En el 0:37 del vídeo anterior se ve el protagonista de pie sin moverse, en realidad ahí iba una intro, que es la que se ve en este vídeo, hay algunos cambios para que hubiera 2 jugadores atados en lugar de uno, es probable que en el estado de la beta no llegaran a finalizarlo.
https://www.youtube.com/watch?v=gaVKFPFzQJE

Tommy Thunder
Por lo visto no fue ni anunciado, se presenta en un estado muy beta, no hay sonido pero podemos escuchar el ruido dependiendo de los colores de la pantalla a causa de un mal cable.
https://www.youtube.com/watch?v=xC9uJovJujk

40 Winks y ODT
Estaban bastante avanzados en su desarrollo, es más casi completos, se puede encontrar la beta de los mismos, aunque también existen las versiones completas de PSX donde si se lanzaron.

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

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

Riqa
Fue un juego presentado en el E3 del 99 desarrollado por Bits Studios, fue cancelado porque avanzaba más lento de lo esperado y la consola ya estaba llegando a su fin de ciclo, el juego parece que tiene un ligero auto apuntado y se usan los C amarillos para desplazarse lateralmente a la vez que corre, lo cual da un aspecto raro a las animaciones de la protagonista que recuerda a Lara Croft, parece que en ese estado de desarrollo ya se movía muy fluido.
https://www.youtube.com/watch?v=5_B-wh4vApw

Jungle Emperor: Kimba
También cancelado, tenía unas interesantes animaciones para el agua.
Imagen
1985a
MegaAdicto!!!
2.502 mensajes
desde nov 2012
en /home/$USER/tmux
@BMBx64
Me gustaria ver un analisis de The Legend of Zelda: Majora's Mask.
Porque a nivel de poligonos se nota tanta diferencia con su antecesor. En especial, la nariz.
BMBx64 escribió:3) Donkey Kong 64, este ya es un caso conocido, tuvieron que usar la expansión y incluirla con el cartucho porque el juego tenía un bug y se colgaba aleatoriamente (estarían pisando memoria reservada?), es un fallo que incluso puede estar presente en algunos módulos de expansión no oficiales, por lo que se recomienda comprar el oficial.


Curioso, se supone que las direcciones reservadas deben venir especificadas en la documentación. ¿Documentación incompleta o desistieron de revisar miles de líneas de código?
1985a escribió:@BMBx64
Me gustaria ver un analisis de The Legend of Zelda: Majora's Mask.
Porque a nivel de poligonos se nota tanta diferencia con su antecesor. En especial, la nariz.


:Ð

Ya veo.

AxelStone escribió:Curioso, se supone que las direcciones reservadas deben venir especificadas en la documentación. ¿Documentación incompleta o desistieron de revisar miles de líneas de código?


Bueno.. lo de las direcciones reservadas es solo una teoría, es cierto que siempre hubo falta de documentación, especialmente del RCP a bajo nivel, a Rare le costó pasta el tema del Expansion pak en DK64 para no querer revisar el código de arriba a abajo.

Muchas cosas que hay en este hilo tienen alguna explicación o cita original en alguna parte (2:40):
https://www.youtube.com/watch?v=VgtAXCaSlpk

In a recent Director's Commentary video for Conker's Bad Fur Day (embedded below, at 2:40), Chris Marlow, one of the game's programmers, let slip some behind-the-scenes details that reveal the true reason for the Expansion Pak's inclusion with Donkey Kong 64. According to Chris, there was a glitch in the game that caused it to "randomly crash...in the 4 meg only version," which apparently didn't occur with the Expansion Pak installed. Unable to track down the cause, Rare was forced to include the memory expansion for free "which cost [Rare] a fortune." Though as fellow Rare colleague Chris Seaver pointed out in that same video, it actually worked out in Perfect Dark's favor (released the following year), as that game "definitely needed it" in order to run most of its modes, which helped avoid most customers from having to purchase the accessory separately.
1985a
MegaAdicto!!!
2.502 mensajes
desde nov 2012
en /home/$USER/tmux
Ah, de otro juego que me gustaria ver un analisis, es de Conker's Bad Fur Day. Que tiene de especial el efecto del cañon o la bazuka, que en emuladores, cuesta trabajo emular correctamente????