Hilo de detalles y curiosidades de N64

Responder
1…29, 30, 31, 32, 33…72
@BMBx64 Pues yo en la imagen no noto lo que señalas
En cuanto a libdragon¿ no estabais mudando a lib64 por estar echo en ensamblador?
@Flash-Original las flechas en la imagen señalan la altura a la que la linea horizontal de pixels está repetida. Fijate bien. En una imagen de color de 15/16-bit con dithering como las que suelen producir las consolas de la 5ª generacion, es especialmente evidente, porque se pierde el "punteo" que produce esa tecnica.

@BMBx64 Yo ya pensaba que te habias olvidado xD
Interesante comparacion. La verdad es que si que han conseguido una gran fidelidad. Ese problema de las lineas repetidas a saber a que se debe. ¿Pudiera ser por intentar estirarla al ser PAL? ¿Pero si fuera eso la ratio de 240:288 es 5:6 así que tendría que haber muchas repeticiones y solo hay 3 o 4.

He corregido la imagen emulada para coincidir con la del hardware y poderlas comparar directamente.
Hay diferencias interesantes. Con un visor como IrfanView, pones las imagenes en el mismo directorio, y rotas entre las 2, con el visor maximizado y la opcion de "use resample for fitting" desactivada, para ver bien los pixelotes.

Imagen Imagen

Una de las cosas mas evidentes es que la imagen del hardware tiene mas brillo, probablemente mas del que debería. En la zona inferior izquierda, triangulado entre la seta, la rana y el punto de la hierba, hay una zona de verde claro que parece antinaturalmente fosforita en la n64 pero mucho mas natural en el emulador. Además, el algoritmo de dithering no es igual entre el emulador y la consola. En ciertas zonas se ven diferencias bastante claras. En general creo que el dithering del emulador es de mayor precision, y da resultados mas suavizados y naturales.

Tambien parece que el calculo de Z es mas preciso en el emulador, porque hay ciertos ejemplos de z-fighting que aparecen en la consola pero no en el emulador, como la clavija del banjo de Banjo (ejem), que se ve un pixel de ella a traves del mastil en consola, pero en el emu no. Tambien parece haber diferencias de Z bastante potentes en la oreja del jabali, pero no sabría decir cual es la mas correcta en ese caso.

Finalmente esta la diferencia de la catarata, que muestra una diferencia de desplazamiento de la textura, pero a saber a que se debe eso en concreto... puede que hasta sea aleatorio el estado inicial. No se.

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

Al subir las imagenes al ftp, vi el antiguo archivo de framebuffers que mencionaba, y he ido al post donde estaba el link a actualizarlo. Es un post de aquella serie de posteos continuos donde comentabamos todo tipo de cosas. viewtopic.php?p=1745962817
Hay muchas curiosidades (valga la redundancia) desperdigadas por aquella tanda de posteo a lo bestia.
@radorn
Lo de la imagen mal estirada puede ser, los juegos PAL suelen dar más problemas, tengo que mirarme todavía aquellos posts [360º] .

El nuevo angrylion está acelerado por OGL, no me extrañaría que use una profundidad de Z-Buffer superior a 16bits, que es la de N64, hay versiones antiguas del plugin que renderizan por software, pero se rompen con el Banjo Kazooie y no puedo sacar capturas.
--

Sobre el Z-Buffer he encontrado un texto de uno de los desarrolladores de Crash que quizás os resulte interesante:

The N64 hardware has something called a Z-Buffer, and thanks to that, we were able to design the terrain and visuals however we wanted. (Super Mario 64 – 1996 Developer Interviews)

This was a huge advantage for them. In contrast, for Crash Bandicoot -- which came out for the PS1 at the same time -- we had to use over an hour of pre-computation distributed across a dozen SGI workstations for each level to get a high poly count on hardware lacking a Z-buffer.

A Z-buffer is critical, because sorting polygons is O(n^2), not O(n lg n). This is because cyclic overlap breaks the transitive property required for an N lg N sorting algorithm.

The PS2 got Sony to parity; at that point both Nintendo and Sony had shipped hardware with Z-buffers.


Did you consider any other alternatives? Curious if you had any other ideas that you sidelined as being too crazy.

No, that idea was crazy enough. :) The collision detection system and camera control code were also insane. Mark Cerny helped me make the collision code fast enough. Very clever assembly language tricks there, and we used 2K of "scratchpad" static RAM built in to the PS1 (for some reason) to make it fast enough.

Can you expand on how the precompute trick works further? So you're precomputing the order of the scenery/level polygons because of their predictable movement but how does that combine with objects with unpredictable movement (Crash, enemies etc.) when you render a frame? Did the limitations of this trick limit the gameplay you wanted?

I've been meaning to write a blog post about this, but here's a brief summary.

We wrote a software renderer for the SGI that exactly replicated how the PS1 hardware would render. I wrote an imperfect clone for Crash 1, then Stephen White wrote a pixel-accurate one for Crash 2. (This is why Crash 1 has "crispies", as Andy called them -- little pixel-sized glitches in the background -- and Crash 2 does not.)

When computing a level, we'd sample N points along the rail as we moved the camera forward through the level. At each point, we'd render the entire scene using the software renderer, then recover the rendered list of polygons, in sorted order, from the (software) Z buffer. We'd then store this sorted list of polygons for each of the N frames, using delta compression between frames to keep the size manageable. The pre-computation phase would choose N empirically, based on much change happened from frame to frame in any given section of the level; basically it would make N as large as it could be without blowing out the page allocation (which was in turn determined by how fast we could read from the CD).

This handled all the polygons in the background, which was completely static. For foreground objects like Crash, enemies, gems, etc, we'd bucket sort them in as we rendered the background. This required manual tuning in some cases, so we had an editor where we could manually adjust the "push-back" (i.e., bucket adjustment) for each object in real time while playing the game. These magic values were then stored with the associated objects as part of the level data. If we couldn't make an object sort in right via bucket adjustment, we'd change the background slightly until it worked. In other words, it was a massive hack. :)

In terms of gameplay, we took our inspiration primarily from Donkey Kong Country, which had linear gameplay. So the rail model actually worked really well for the gameplay we were trying to achieve. (DKC is still an awesome SNES game; check it out if you haven't played it recently.)


How did Spyro end up getting past this limitation to have a free roaming camera with a good poly count?

The Hastings brothers (who were actually down the hall from us when we were writing Crash) are really awesome coders. Even so, however, I don't think Spyro for PS1 actually had anywhere near Crash's effective polygon count. Crash himself was over 750 polygons, which was not bad for an entire frame of a PS 1 game.


--
Montaron el motor del juego replicando el funcionamiento de PSX pero con un algoritmo de ordenación por software bastante pesado (z-buffer) en estaciones de trabajo de SGI y sacaron un listado de toda la geometría estática ordenada para cada avance de cámara (frame) que sucede en el juego, para cada nivel.

Esa lista queda como datos del nivel preprocesados, luego en tiempo real los van cargando y editando con los objetos móviles como Crash, con diferentes truquillos para sacar el frame final, con lo cual consiguen más cosas en pantalla y a mayor precisión de las que podría si PSX tuviera que ordenar todo eso en tiempo real en su CPU.

Ese tipo de listas tan complejas no hay que hacerlas llevando el Z-Buffer de serie en N64.

@Flash-Original
Todos estos nuevos descubrimientos pueden emplearse de mientras en libdragon para empezar a trastear, montar un engine 3D que maneje cámara, colisiones, etc.. [oki]
@BMBx64
Vaya historia lo del Crash Bandicoot. Ya había leido alguna explicacion sobre el tema, pero mucho mas superficial aun que esta y no tenia muy claro de que iba el mambo. Ahora si que lo tengo claro.
La verdad es que nunca me planteé buscar hacks/mods de los Crash de PS1, pero viendo el panorama, no me sorprendería nada que nunca lleguen a hacer niveles nuevos para esos juegos. En la mayoria de juegos de N64 los niveles consisten en geometria visible, geometria de colision, y objetos repartidos por el escenario que interactuan o activan eventos y demás. Todo eso es mas o menos factible para un esfuerzo de hacking "casero". No veo yo a nadie matandose a desentrañar los secretos del formato en streaming con diffs e interpolacion entre "frames" que requieren los niveles de Crash Bandicoot, y mucho menos desarrollar la herramienta para generar esos datos...

Igual me cuelo, pero hacerle la ingenieria inversa a semejante castillo de naipes se me antoja una tarea tan gigantesca y sin garantias, que no creo que nadie esté tan loco de intentarlo si quiera.

La comunidad ROMhack agradece la bendicion celestial que supone el que N64 tenga Z-Buffer, por mucho que se coma el rendimiento xD.

Y ya que sacamos ese tema. Aparte de hacks "basicos", tipo mejoras, arreglos, "undubs", traducciones, etc... La verdad es que no soy capaz de recordar ni un solo juego 3D de PS1 para el cual haya hacks o mods extensivos, con nuevos niveles y tal, igual que los hay en juegos de N64 como GoldenEye, Perfect Dark, Banjo Kazooie, los dos Zeldas, Super Mario 64, Diddy Kong Racing...
No pongo en la lista los mods de F-ZERO X porque en ese juego los niveles son un suelo, un cielo, un fondo, y un circuito flotando en medio de todo ello, el cual no esta modelado directamente en 3D, si no que está formado por piezas deformadas siguiendo un esqueleto. Las piezas incluso ahorran detalle a distancia. Es bastante diferente en cuanto a motor y "metadatos" que un mundo 3D poligonal abierto como los de los otros juegos de la lista.
El caso es que, hasta me he revisado todos los hacks de PS1 que tienen en ROMhacking.net, y lo unico que he encontrado que si quiera intervenga en el contenido 3D son una serie de hacks para Tekken en los que ponen personajes nuevos, y no tengo nada claro hasta que punto es realmente geometria nueva y no simple hackeo "superficial" de material existente, porque el tamaño de los parches es irrisorio.

O sea, que hasta donde yo puedo ver, no parece que haya hackeo 3D en PS1 como lo hay en N64, y me pregunto si se deberá a las complejidades de lidiar con el motor de calculo de orden de dibujado. Igual todos necesitan metadatos precalculados para eso... no tan extensivos como Crash, claro, pero si algun tipo de asignacion pre-calculada para ahorrar procesos durante la ejecucion.
@BMBx64 @radorn
Tengo una teoria sobre las dobles líneas de las capturas.
Como sabemos, en la N64 se fija el framebuffer dando la resolución horizontal, pero la resolución vertical surge de un cálculo, creo recordar entre la resolución horizontal dada y la escala vertical y horizontal que también se añaden a los registros del VI. A lo mejor no es así exactamente, no lo recuerdo bien, solo recuerdo que era un lío tremendo. [+risas]
El caso es que al obtener la resolución vertical por un cálculo, es posible que el emulador en ciertas condiciones tenga una disparidad de resultados.
En este caso la resolución vertical en la consola es 215. Es posible que el emulador tenga un bug a la hora de calcular resoluciones impares o el cálculo a bajo nivel lo haga de forma distinta a como lo hace la N64. Ahora mismo lo que se me viene a la cabeza es que las divisiones entre 2 se hagan en el emulador o en la consola por desplazamiento de bits a la derecha(shift), que es una forma de hacer divisiones con potencias de dos ultrarápida pero perdiendo toda información de decimales, generando errores de precisión. Sea como sea, esto crea una disparidad entre la resolución de renderizado, 213 lineas, y la de imagen, 216, por lo que el renderizado se estira hasta llegar a 216, repitiendo una linea cada 72 píxeles, justo un 33% de la imagen.
Se puede ver en la rana de la parte inferior como el emulador ha dejado de renderizar dos lineas que sí estan en la consola, lo cual significa que el renderizado emulado esta incompleto y fotograma se ha estirado para encajar con la resolución mal calculada del framebuffer.
Esto no creo que pase con todos los juegos, solo con determinadas resoluciones y relaciones de aspecto.

BMBx64 ya que estás por aquí, una cosa que quería preguntar, sin ánimo de desviar la conversación que ya hay.
Abrí un hilo sobre ports hipóteticos y me planteé la posibilidad de crear un escenario con fondo de tiles, tipo Starcraft, pero en el que los personajes en vez de ser sprites fuesen en 3D. Sé que en N64 puedes poner un personaje 3D sobre un fondo 2D, o crear un fondo 3D y usar sprites como en Command&Conquer, pero, ¿un fondo 2D generado por tiles?
No creo que haya limitaciones técnicas para ello, pero como no recuerdo ningún juego de N64 que haga esa combinación de tiles más 3D, me gustaría si podrías resolverme la duda. [ayay]
Acabo de flipar con la entrevista de lo de Crash, siempre había pensado que fue un juego "sencillo" de programar por eso de no tener cámara y ser niveles lineales. Pero sobre todo por haberse ya inventado una especie de z-buffer por software en el primero que es de 1996, no sé en que hilo comentamos que el CTR usaba z-buffer por software para el agua y algunas cosas, pero no tenía ni idea de que ya había juegos de primera hornada que habían paliado esa carencia de hardware ¿Habrá más?


Por otro lado yo venía con una petición para cuando quieras analizar algún juego: Destruction Derby 64. Es una versión bastante mala del primero de PSX (1995) que no sé bien porqué la sacaron en 1999, es decir cuando en PSX ya había salido en 1996 el Destruction Derby 2 y faltaban meses para que sacaran el Destruction Derby Raw. El caso, es que sino me falla la memoria es el único juego de coches de N64 que tiene un sistema de daños en tiempo real o como se llame, vamos que cuando chocas ves saltar por los aires trozos de los coches, abolladuras, etc. De los de PSX he podido encontrar algo de información sobre este sistema de daños, al parecer usaron un sistema bastante simple en 2D para detectar las colisiones, lo que se traduce en que da igual a la altura que te den la hostia, la abolladura se va a producir siempre con la misma forma (creo, porque estaba en inglés lo que leí). A lo mejor en este de N64 usaron algún tipo de colisiones 3D.
@EMaDeLoC
La verdad es que yo no se casi nada de las tecnicas matematicas que mencionas.
Una objeccion que tengo a tu explicacion es que si el responsable de las lineas extra fuese el proceso renderizador, sabiendo, segun marshallh me contó en su momento, cómo el proceso de dithering se hace por "magic square" para poder obtener una imagen de 15/16 bit con dithering en una sola pasada (el otro metodo sería renderizar a 24, añadir la señal de dithering y ya entonces reducir la profundidad de color a 16, lo cual daría una calidad mayor, pero sería intolerablemente lento), entonces la linea extra tendría contenido real con dithering. Pero la imagen que tenemos duplica la linea una vez ya está el framebuffer terminado, cosa que se ve claramente al no tener su propio "punteado".
Todos esos calculos suenan correctos, pero tiene que ser un escalado posterior al renderizado.

Adelantandome a lo que te vaya a decir BMB, y arriesgandome a errar, yo lo que se de 2D en N64 es que las librerías proporcionan microcodigos para el renderizado por tiles/celdas igual que en sistemas anteriores. El proceso sugerido depende de lo que quieras hacer, pero, basicamente, tu puedes cargar sucesivamente todos los microcodigos con sus respectivos display lists que quieras, limitado unicamente por tu deseo de mantener un rendimiento aceptable.
Para el ejemplo que pones, de un terreno 2D con objetos 3D encima, suena a que podrías pasar primero el microcodigo 2D que renderize tu fondo y luego renderizar los tridimensionales encima.
Hay muchas variaciones en todo esto, y po supuesto, la region de la pantalla a la que dibujes con cada uno es personalizable y tal. Mas detalles no te puedo dar, pero yo creo que es totalmente posible lo que dices. Lo facil o complicado que sea y el resultado que de ya es algo que se me escapa.

@Calculinho El Destruction Derby de N64 lo jugué brevemente con el 64drive y no recuerdo bien cuanto detalle o veriabilidad tenian los daños fisicos. Lo que si se es que no es el unico juego que los tiene. Todos los juegos de la saga RUSH que salieron en la N64 (SFR, RUSH2, SFR 2049) tienen daños en la carroceria tambien. Y creo que hay alguno mas, pero no me hagas mucho caso.

Ya que lo mencionas, y con respecto a la discusion de framebuffers y tal, CREO que posiblemente sea de los pocos juegos que rendericen a 24bit y luego aplica una mano de dithering aleatorio por VI que incluso se puede desactivar en las opciones, dejando ver el banding de color causando por la reduccion a RGB de 21bit. Claro que tambien puede ser simplemente 16bit. No lo se. @BMBx64 haces el analisis, aclara este detalle tambien, por favor.
@radorn pues sí, los que comentas también tienes daños estéticos por lo que veo en youtube, ya no me acordaba. Aunque creo que los de Destruction Derby son mejores porque no sólo se quedan en lo estético de los coches sino que ver saltar por los aires trozos de los mismos. Por cierto, creo que el 2049 no tiene he estado mirando un par de vídeos y sólo encuentro hostias delanteras así que no veo si el coche queda dañado o no. Y ojo, me refiero a daños estéticos en tiempo real, que por ejemplo el Top Gear Rally 2 tiene un sistema de daños de piezas del coche como ruedas, amortiguadores, etc. Pero creo recordar que estéticamente el coche nunca sufría cambios estéticos aunque chocases, pero ya hace más de un año que lo jugué y la memoria es muy traicionera.
@Calculinho
PSX no hace cálculos de Z-buffer en el caso de Crash, lo hacen las estaciones de trabajo de SGI, en la consola solo se cargan los display lists ya ordenados para cada frame, en los juegos que se ejecutan en tiempo real habría que ver cual es la calidad del algoritmo de ordenación que usan, aunque seguramente sean truquillos de programación muy ingeniosos.

A pesar de que tengan la lista bien ordenada la GPU solo pinta en 2D, pondrá un polígono encima de otro, ej. si 2 polígonos se cruzan en un punto intermedio hay que dividir triángulos para visualizar el cruce entre ambos, en un Z-buffer como N64 se hace una comparación por pixel con profundidad Z de 65535 posiciones para saber qué pixel se pinta por encima del otro.

Me apunto el Destruction Derby para cuando tenga un rato [oki]

@EMaDeLoC
Sí, no hay problema.

Si usas COPY los tiles podrán estar o bien delante o detrás de los modelados 3D, ya que COPY solo pinta directamente en el framebuffer.

Si usas CYCLE y tiles como polígonos planos el resto de elementos 3D podrían incluso interactuar con el fondo, como traspasarlo suavemente, recibir iluminación y otros efectos.
@BMBx64 Gracias, me imaginaba que técnicamente sería posible pero al no haber ejemplos en la consola no estaba seguro. Creo que CYCLE sería la mejor opción ya que podrían usarse efectos de iluminación y transparencias y mejorar gráficamente el juego hipotético.

radorn escribió:La verdad es que yo no se casi nada de las tecnicas matematicas que mencionas.

Supongo que te refieres a sustituir las divisiones de potencias de 2 con desplazamientos de bits a la derecha (shifts).
Piensa en números binarios:
1=1
2=10
3=11
4=100
5=101
6=110
7=111
8=1000

Si te fijas, al quitar el bit de la derecha cuando es 1000(8), nos queda lo mismo que si fuese 100(4). Pues hacer eso, quitar un bit a la derecha, es una instrucción muy sencilla a nivel de procesador, mientras que una división es algo más complejo. Es tan sencilla que en algunos procesadores puedes hacer la primera con una sola instrucción de código, mientras que la división te puede llevar 3 o 4. Y si necesitas mucha velocidad de procesado y tienes divisiones por dos, esto te ayuda a ganar mucha velocidad.
Pero claro, si haces lo mismo con 111(7), matemáticamente tendría que ser 3'5, pero te quedas con 11(3) y el resto, ese 1 de sobra, ha desaparecido, por lo que has perdido información relevante para hacer redondeo al aza, de 3'5 a 4. Es decir, has perdido precisión, y si no tienes en cuenta esto o estas haciendo el método de cálculo de otra manera, esta falta de precisión se encadena y agranda hasta hacerse visible.
Puede que con números pequeños como los que estoy usando en el ejemplo no parezca tan grave, pero con números grandes es algo percibible.

radorn escribió:Una objeccion que tengo a tu explicacion es que si el responsable de las lineas extra fuese el proceso renderizador,

No, no me has entendido, el proceso de rasterizado esta bien, pero hay una discrepancia entre el tamaño vertical del rasterizado y el del framebuffer. En el caso que nos ocupa, se rasterizan 213 líneas y el framebuffer es de 216, habiendo tres líneas duplicadas: la 1, la 72 y la 144. Para mí el problema es como el emulador maneja internamente el rasterizado y el framebuffer, que debe hacerlo por dos métodos distintos y de ahí la discrepancia.
La verdad que me llama la atención que se copie la primera línea superior y no la última, pero puede que la pantalla se dibuje de abajo a arriba y por lo tanto el error de cálculo vaya en esa dirección.
No descarto tampoco que el rasterizador funcione bien y haga 215 líneas como toca y sea al pasarlo al framebuffer donde todo se vaya al carajo y se dupliquen líneas, se pierdan las dos de abajo...
Pero eso, que yo creo que el problema esta en el diferente tamaño de rasterizador y framebuffer del emulador, no en la forma de trabajar del rasterizador.

En cuanto a lo que comentas del 3D en 2D, a mi me parece una explicación buena y es más o menos lo que pensaba que podría hacerse en un juego. Lástima que a ningún desarrollador se le ocurriese, porque habría quedado algo bastante vistoso para la época, cercano al resultado que dio años después Sacred en PC.
Gracias por la explicacion del bitshift. Yo es que veo que soleis manejar conceptos computacionales de bajo nivel y yo no estoy familiarizado. Me referia a eso.

En cuanto a lo que dices del framebuffer. Yo es que no creo que el emulador renderize a 213. Yo creo que renderiza perfectamente a los 215 que corresponden, porque si no no coincidiria (excepto diferencias menores) casi nada en la comparacion con las correcciones que hice. Lo que yo creo que pasa es que, una vez renderizado a 215 como corresponde, algun proceso posterior entre el framebuffer y la rutrina de captura (sacar fichero de imagen) o presentacion (pantalla), alguna cosa se hace mal y se añaden esos duplicados, estirando la imagen hacia abajo 3 pixels. Sumale que se hace un redondeo al alza para hacer la dimension vertical numero par, y 2 de los pixels acaban fuera. Con todo, ese redondeo a 216 salva de la quema una de las lineas xD

De todas formas, una pregunta para @BMBx64, y si ya diste la explicacion en el hilo, no te repitas. Dimelo y lo busco, que ademas asi continuo la lectura del hilo que la tengo a medias :D
No es que esté sorprendido porque claramente la N64 está llena de cosas raras y numeros raros, pero... ¿a que se deben esas resoluciones de framebuffer tan particulares? ¿Es simplemente que los desarrolladores eran así de bohemios o tiene alguna explicacion tecnica? Particularmente me llama la atencion, como seguro que a muchos, eso de que las haya impares, al menos en el eje vertical: 215, 235, 237, 239 (zelda), 269 (GE PAL)... Cierto es que no todas son impares. en los ejemplos de mis capturas hay tambien 214, 218, 220... 326 (intro y menu de GE PAL, raro ejemplo de oversampling), pero muchas si que lo son. Tambien es cierto que a las capturas que hice en su momento tambien les recorte los bordes negros y otras que descargue hechas por otra persona parecen ser todas 237 sin recortar los bordes. Yo no recuerdo cuales eran las dimensiones originales de las mias.
Coincido en que es algo posterior al rasterizado o el resultado sería más distinto. Puede incluso que no sea culpa de proceso vinculado al framebuffer, sino una limitación de salida gráfica del emulador que no permita trabajar con impares y esté resuelta como el c... pero vamos, para estar seguros habría que mirar el código fuente.

En cuanto a tu pregunta hacia BMBx64, quizá el tema de resoluciones peculiares venga por eso de que la resolución vertical se calcula a posteriori y por la forma que tiene la N64 de calcularla haya que darle muchas vueltas para que salgan pares. Creo que también puede que tenga algo que ver que fuesen quitando líneas hasta conseguir un equilibrio razonable entre tamaño de imagen y framerate, y que sean impares es simple coincidencia.

La verdad es que ya puestos BMBx64 podría indicar como se obtiene la resolución vertical a partir de la resolución horizontal y otros parámetros, ayudaría a despejar dudas. A ver si se anima. [angelito]
Malas noticias. GoldenEye Vault cierra sus puertas.
SubDrag ya no tiene tiempo y energía para mantener el sitio ni continuar trabajando en el Editor. Sabía que cada vez estaba menos activo y que el proyecto de Goldfinger 64 le había quemado mucho, pero recientemente había añadido compatibilidad en el Editor para Pokemon Snap y Super Smash BROS 64 así que este cierre me ha pillado por sorpresa.
De momento sólo mantiene el contenido relacionado con GoldenEye y Perfect Dark y ya no se puede acceder al resto de parches de otros juegos. Puede que en el futuro todo renazca con otra forma.

Creo que el mejor sitio para conocer novedades sigue siendo el foro de shootersforever y más concretamente el hilo del anuncio del cierre de GoldenEye Vault. Fue en ese foro donde conocí a @radorn, SubDrag y muchos otros que me enseñaron y ayudaron en mis mods.

Tengo en la recta final mi recopilatorio de mapas multijugador para GoldenEye y he malgastado mis vacaciones sin avanzar apenas en él. Necesito ponerme las pilas. [+furioso]
@Sogun Vamos tendre que investigar con el editor pues estoy haciendo las pruebes en goldeneye por que en perfect dark se me queda pillado es una pena

Solo me faltaba el de editar las cinematicas en perfect dark pero si no se puede no se puede, vere si puedo desordenar los niveles

Es una pena, ¿se sabe el motivo?
@Flash-Original
Hace tiempo que estoy bastante desconectado de toda la scene de GoldenEye y Perfect Dark y no sé si han avanzado algo en las cinemáticas.
Seguramente PD es mucho más complejo y por la tanto es más difícil desarrollar el editor en ese sentido, pero también la comunidad se ha centrado casi exclusivamente en GE y quizás por eso el editor ha avanzado más en darle soporte y al final es la pescadilla que se muerde la cola. Por ejemplo, durante todo el desarrollo de Goldfinger 64 el editor evolucionó un montón porque se necesitó para sacar el proyecto adelante.

Sin embargo hace poco he visto cosas brutales en GE. No sé si se puede hacer todo con el editor o si lo han hackeado por su cuenta, porque parece que la comunidad está desdoblada entre el foro que he mencionado antes y un canal de discord y es difícil seguir la pista. Hay hacks con sonido para las pisadas como en PD; con cinemáticas al principio, en medio y al final del nivel, diálogos hablados... y luego está esto (especialmente a partir del minuto 10:27):

SubEye
Lo veo ahora y ese primer nivel era premonitorio. :(
¿Se sabe de algun foro de scene retro,noticias y demas? o sea abarcando desde nes/master system hasta n64/ps1?
@Sogun
Precisamente hace un par de dias se me dio por visitar el Vault despues de un monton de tiempo porque estaba trasteando con roms y unos hacks que tenia desperdigados por ahi, descubriendo la, para mi novedad, del mickey, snap y ssb... yo lo ultimo que habia visto era DKR. Y ahora va y chapa la mitad del sitio de golpe.
Podría hacer un zip con todo y subirlo al internet archive o algo...
Despues de tanto tiempo sus motivos tendrá, no lo culpo por eso. Aunque en el terreno personal entre el y ya es otra cuestión.
@radorn
La teoría es que el RDP no pinta todas las líneas y esas resoluciones ayudan a ahorrar ancho de banda.

Por otro lado tenemos set scissor, cuando empecé a programar en N64 utilizaba un scissor de 320,240, lo cual es erróneo ya que el 0 cuenta, el setting correcto es 319,239 (0-319 = 320), es decir necesitas poner un valor impar para conseguir uno par, con ello no quiero decir que el que existan resultados pares e impares sea fruto de ello.

Lo que sí podría hacer es un programa pintando lineas en posiciones concretas para saber donde dejan de visualizarse, pero ya de entrada con el cable RGB la imagen me sale descentrada hacia la izquierda [mad]

Sobre lo que comenta @EMaDeLoC, no he estudiado a fondo el tema de las resoluciones, para entender las cosas siempre me ayudo trasteando en la consola y en este caso se puede liar bastante como ponga mal los valores donde no debo [hallow]

Pero lo que sí que me gustaría mirar es el centrado de imagen que tienen juegos como Quake 1, 2 y que inexplicablemente falta en la mayoría de títulos, creo que es una función obligatoria para cualquier nuevo homebrew que se haga.
Alguien conoce este juego cancelado?

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

Yo lo conoci hace poco y me parece bastante llamativo.
@sinovic Si, lo conozco. No lo recuerdo de las revistas de la epoca, y si lo vi quizá no me llamó la atencion o no hablaron mucho de el y por eso no lo recuerdo. La segunda posibilidad es la que mas probable me parece. Ese video lo publicó uno de los desarrolladores, que, hace cosa de uno o dos años desenterró de sus archivos personales una serie de ROMs de betas entre las que estan esa y unas de DIE HARD 64 (que luego se convertiría en el, a mi parecer, mediocre-truño DIE HARD Vendetta, de GC, que tuve la desgracia de comprar por querer un FPS).
Del DIE HARD 64 primero sacó unos videos y luego los dueños del copyright le permitieron publicar 3 ROMs con versiones beta de los niveles del juego, unos bastante funcionales y otros muy incompletos incompletos. Durante todo el juego suena la misma musica ratonera con unos punteados de cuerda que pueden recordar a algunos momentos de las peliculas, pero nada mas xD
Del Riqa, por desgracia, no le dejaron publicar la ROM, pero si grabar un video, que es el que has puesto ahí. El hilo está en el foro ASSEMbler Games. No se si por aquí se comentó tambien, pues de aquella no me pasaba mucho por aqui.

@BMBx64
Te resuelvo lo del "descentrado hacia a la izquierda" de RGB. En realidad es muy sencillo y no tiene misterio ninguno:
Cuando una señal analogica llega a la TV, si es RGB, va directamente a los cañones de electrones del tubo (o el escalador de imagen en una pantalla de panel), con el unico paso previo de la amplificacion.
Por otro lado, si la señal es compuesto, S-Video, o componentes (YPbPr) es necesario hacer la conversion a RGB primero y eso introduce un retraso.
No es que la señal RGB se desvie a la izquierda, es que la TV esta calibrada para contar con el retraso del decodificador de señales compuestas, que son las que usa la mayoria de la gente.
En una TV digital que samplee la señal lo podrían haber solucionado, pero ya veo que en tu caso no, y me imagino que debe ser así en general en todos los modelos.

Una curiosidad al respecto: La señal RGB del conector SCART estaba inicialmente destinada a decodificadores de teletexto externos, y el metodo que usaban para superponer su señal en la imagen de la TV era mediante la activacion de la patilla "fastswitching" o algo asi. El modo en que funcinoa esto es que la entrada RGB al tubo tiene dos posibles fuentes, el decodificador de compuesto (o svideo), y la entrada RGB externa, y se cambia de una a otra segun lo indique el voltaje de la patilla esa. La velocidad a la que la patilla activa y desactiva la superposicion de la señal externa RGB tiene que ser suficientemente rapida como para poder activar la superposicion cuando empiece un pixel y desactivarla cuando acabe.
Luego las TVs empezaron a incorporar decodificadores de teletexto integrados, que, internamente funcinoan de manera similar. La ventaja de todo esto es que si mantienes la señal fastswitching activa todo el tiempo puedes usar el RGB para mostrar contenido de video normal, como hacen las consolas.
En USA, en vez de teletexto tenian "closed captions", y creo que no usaban el mismo sistema y por eso sus TVs de consumo raramente tenian algun tipo de conexion RGB ni mucho menos un estandar como es SCART. Ellos pasaron directamente a componentes en la epoca del DVD.
En fin, todo este preambulo para comentar que, el mismo mecanismo de superposicion RGB es el que usa la mayoria de TVs para superponer los menus en pantalla, no solo el teletexto.
Cuando usas una fuente RGB en una de esas TVs, es habitual que el OSD transparente la imagen, porque a fin de cuentas lo que esta sucediendo es que se mezcla la señal RGB externa con la interna del OSD. La cuestion es que si usas una fuente de video SCART que emita la misma imagen en compuesto y RGB a la vez (svideo no, porque tapa una de las patillas RGB), y haces que la TV muestre la entrada de compuesto en vez de RGB. En esa situacion, si haces que salga algun elemento del OSD en pantalla, digamos, el deslizador de volumen, lo que vas a notar es que ese deslizador va a transparentar la imagen, pero dentro de esa area, la imagen estará corrida a la izquierda con respecto al resto de la imagen procedente de compuesto, porque esa transparencia es resultado que que cuando la TV hace fastswitching para mostrar el elemento de la OSD, tambien se mezcla la señal RGB externa.

En fin, chorricuriosidades. Espero que te haya resultado entretenido.
@radorn gracias por la explicacion. Ojala algun dia se libere la rom para que sea analizada como se hace en este hilo... claro, solo si es digna de analisis para asi ir descubriendo mas cosillas de esta infravalorada consola que a mi en lo personal me encanta.

Saludos.
@radorn
Se agradece la explicación [oki]

Por lo pronto necesito tomar el control de la posición de pantalla, luego podré experimentar y ver cuales son los rangos de pintado y resoluciones útiles.

En las próximas semanas vuelvo a tener más tiempo libre, así que supongo que podré volver a trastear [360º]
--

(Había pasado por alto el vídeo del Riqa, ya podrían lanzar el prototipo..)
BMBx64 escribió:Por lo pronto necesito tomar el control de la posición de pantalla, luego podré experimentar y ver cuales son los rangos de pintado y resoluciones útiles.


Durante la racha de posts masivos de antes del verano, puse tambien esto, o algo similar. Son unos calculos que he hecho sobre las frecuencias de la consola y especialmente el pixel clock del bus de video.
Probablemente te sirva de algo para eso que quieres hacer.

video format timings

NTSC
   color   3579545.45~ Hz (315MHz / 88)
   hsync   15750/1.001
   vsync   60/1.001
   line   63,55~ microsec

PAL
   color   4433618.75 Hz (+/- 0.5 Hz)
   hsync   15625 Hz
   vsync   50 Hz
   line   64 microsec

MPAL
   color   3575611.00 Hz
   hsync   15750 Hz
   vsync   60 Hz
   line   63.492063492063492063492063492063 us


N64 timings

Xtal1=X
VCLK_ = Video Clock

NTSC   Xn      14318181.81~Hz
      VCLKn   48681818.18~Hz   (Xn * 17 / 5)   ((((315/88)*4)*17)/5)
      FSCn    3579545.45~Hz   (Xn * 1 / 4)   (315/88)

PAL      Xp      17734475.00 Hz
      VCLKp   49656530.00 Hz   (Xp * 14 / 5)
      FSCp    4433618.75   Hz   (Xp * 1 / 4)

MPAL   Xm      14302446.00 Hz
      VCLKm   48628318.00 Hz   (Xm 17 / 5)
      FSCm    3575611.50 Hz   (Xm 1 / 4)


Xtal2=Y
      Y=14705882.352941176470588235294118 Hz
RCLK   250 MHz = Y * 17
Rambus Clock

RCPclk = RCLK / 4      = 62.5 MHz
CPUclk = RCPclk * 1.5   = 93.75 MHz


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


Here I'll try to calculate plausible video timings for the N64.
Pixel clock values can be calculated from known data.
Actual Hsync and Vsync timings are a result of line lenght in pixels and
display height in lines, which are set in software by the libraries that
control the VI, which is the element that puts the video data on the bus that
goes to the DAC. This is a 7bit wide bus with a fixed clock derived from the
color carrier frecuency, and sends sequences of 4 7-bit bytes, containing the
values for R, G, and B, and a control byte that signals, among other things,
the synchronization pulses that the DAC should generate. The pixel clock of
the N64 video subsystem is, therefore, a quarter of the video bus frecuency.
This scheme imposes that analog video lines have a fixed lenght in pixels.
I don't know what values actual games use or can use, so I'll try to calculate
possible timings by trying several reasonable values.


-------------------PAL N64--------------------
(283.75 * 15625) + 25
PAL carrier = 283.75 x 15625 = 4433593.75 -> +25 = 4433618.75 Hz
PAL color cycles per line = 283.75 or 283.7516

N64 PAL crystal       = 17734475.00 Hz
   |->  1/4 (0.25x) = 4433618.75 Hz (PAL color)
   |-> 14/5 (2.80x) = 49656530.00 Hz (video bus)
   
pixel clock = videobus / 4 (1 clock per RGB byte + 1 clock for signaling byte)
49656530 / 4 = 12414132.5 pixels per second

---50Hz modes for PAL N64---

794-pix lines = 15634.927581863979848866498740554 Hsync
                   +9.927581863979848866498740554 Hz vs STD
line duration =  63.959362444375392320003028806080 microsec
                283.57142857142857142857142857143 chroma cycles
312 line 288p = 50.111947377769166182264419040238 Vsync
313 line 288p = 49.951845309469584181682104602409 Vsync
625 line 576i = 50.031768261964735516372795969773 Vsync
           \ 25.015884130982367758186397984887 fps

795-pix lines = 15615.261006289308176100628930818 Hsync   
               -9.738993710691823899371069182 Hz vs STD
line duration =  64.039915797579895333000513729008 microsec
            283.92857142857142857142857142857 chroma cycles
312 line 288p = 50.048913481696500564425092726980 Vsync
313 line 288p = 49.889012799646352000321498181527 Vsync
625 line 576i = 49.968835220125786163522012578616 Vsync
           \ 24.984417610062893081761006289308 fps

          
796-pix lines = 15595.643844221105527638190954774 Hsync
              -29.356155778894472361809045226 Hz vs STD
line duration =  64.120469150784398345997998651939 microsec
            284.28571428571428571428571428571 chroma cycles
312 line 288p = 49.986037962247133101404458188378 Vsync
313 line 288p = 49.826338160450816382230642028032 Vsync
625 line 576i = 49.906060301507537688442211055276 Vsync
           \ 24.953030150753768844221105527638 fps

---60Hz modes made for PAL N64---

nominal line lenght = pixel clock / horizontal sync
NTSC (12414132.5 / (15750 / 1.001))   = 788.98708777777777777777777777778
SysM (12414132.5 / 15750)         = 788.19888888888888888888888888889
trying 788 789 790

788-pix lines = 15753.975253807106598984771573604 Hsync
              +19.709519541372333250505839338327 Hz vs STD
line duration =  63.476042325148374242018119268503 microsec
             chroma cycles
262 line 240p = 60.129676541248498469407525090092 Vsync
263 line 240p = 59.901046592422458551272895717125 Vsync
525 line 480i = 60.015143824027072758037225042301 Vsync
           \ 30.007571912013536379018612521150 fps

789-pix lines = 15734.008238276299112801013941698 Hsync
               -0.25749598943515293325179256738192 Hz vs STD
line duration =  63.555555555555555555555555555554 microsec
             chroma cycles
262 line 240p = 60.053466558306485163362648632435 Vsync
263 line 240p = 59.825126381278703850954425633833 Vsync
525 line 480i = 59.939079002957329953527672158850 Vsync
           \ 29.969539501478664976763836079425 fps

790-pix lines = 15714.091772151898734177215189873 Hsync
              -20.173962113835531557050544392317 Hz vs STD
line duration =  63.637149031557380268013089114364 microsec
             chroma cycles
262 line 240p = 59.977449512030147840371050343028 Hsync
263 line 240p = 59.749398373201135871396255474804 Hsync
525 line 480i = 59.863206751054852320675105485230 Hsync
           \ 29.931603375527426160337552742615 fps


-------------------NTSC N64----------------------

NTSC carrier = 315000000/88 = 3579545.4545454545454545454545455
NTSC 227.5 chroma cycles per line

N64 NTSC crystal    = 14318181.8181818181818181818181818 Hz
   |->  1/4 (0.25x) =  3579545.4545454545454545454545455 Hz   (NTSC color)
   |-> 17/5 (3.40x) = 48681818.1818181818181818181818182 Hz   (video bus)

pixel clock = ((315000000/88)*(17/5)) = 12170454.545454545454545454545455

---60Hz modes---

nominal line lenght = pixel clock / horizontal sync
NTSC   ((315000000/88)*(17/5))/(15750/1.001)   = 773.5
SysM   ((315000000/88)*(17/5))/(15750)         = 772.72727272727272727272727272727
trying 772 773 774

(((315000000/88)*(17/5))/772)
772 pix lines = 15764.837494112105511069241639190
              +30.571759846371245334975904924091 Hz vs STD
line duration = 63.432306255835667600373482726423
262 line 240p = 60.171135473710326378126876485457
263 line 240p = 59.942347886357815631441983418973
525 line 480i = 60.056523787093735280263777673105
           \ 30.028261893546867640131888836552

(((315000000/88)*(17/5))/773)
773 pix lines = 15744.443137716100199929436669411

line duration = 63.432306255835667600373482726423
262 line 240p = 60.093294418763741221104720112255
263 line 240p = 59.864802805004183269693675549090
525 line 480i = 59.978831000823238856874044454898
           \ 29.989415500411619428437022227449

(((315000000/88)*(17/5))/774)
774 pix lines = 15724.101479915433403805496828753

line duration = 63.596638655462184873949579831931
262 line 240p = 60.015654503494020625211819957071
263 line 240p = 59.787458098537769596218619120732
525 line 480i = 59.901338971106412966878083157153
           \ 29.950669485553206483439041578576
Sogun escribió:Sin embargo hace poco he visto cosas brutales en GE. No sé si se puede hacer todo con el editor o si lo han hackeado por su cuenta, porque parece que la comunidad está desdoblada entre el foro que he mencionado antes y un canal de discord y es difícil seguir la pista. Hay hacks con sonido para las pisadas como en PD; con cinemáticas al principio, en medio y al final del nivel, diálogos hablados... y luego está esto (especialmente a partir del minuto 10:27):

SubEye
Lo veo ahora y ese primer nivel era premonitorio. :(


¡qué pasada! Me ha gustado especialmente el "modo resident evil". Si finalmente sale lo de crear un proyecto desde EOL para N64, ¿qué os parecería hacer Resident Evil Zero? [looco]
@sogun llevo desde que pusiste el subeye64 buscando si se puede usar en flashcard o sí es una modificación sólo para emulador, pero no encuentro nada ¿Tú sabes?
O sea que Crash se inspiro jugablemente en Donkey Kong Country!!!

Para que luego digan que la trilogía del mono solo aporto a la industria sus gráficos prerenderizados XD
@Calculinho
Pues no tengo ni idea de si funciona en consola. El parche no estaba en GoldenEye Vault y no lo he probado.
@Sogun gracias! Estos días tengo la DC enchufada al CRT, pero cuando saque la N64 tengo que probar todo ese rebumbio de mods que hay a ver si funcionan.
Sogun escribió:@Calculinho
Pues no tengo ni idea de si funciona en consola. El parche no estaba en GoldenEye Vault y no lo he probado.

He encontrado este
https://cdn.discordapp.com/attachments/ ... view_2.zip

es de Junio pero es el último que existe públicamente, al parecer.
@radorn
Por lo visto hay valores estándar que usan la mayoría de desarrolladores, por ejemplo, la libdragon y la libn64 tienen la misma configuración para NTSC 320x240.

libdragon
__registers[1] = 0x00000140; /* base offset for field 1 */
__registers[2] = 0x00000140; /* width */
__registers[5] = 0x03E52239; /* burst */
__registers[6] = 0x0000020D; /* vsync */         
__registers[7] = 0x00000C15; /* hsync */
__registers[8] = 0x0C150C15; /* leap */
__registers[9] = 0x006C02EC; /* hstart */
__registers[10] = 0x002501FF; /* vstart for field 1 */
__registers[11] = 0x000E0204; /* vburst for field 1 */
__registers[12] = 0x00000200; /* x-scale */         
__registers[13] = 0x00000400; /* y-scale */


libn64
static vi_state_t vi_state = {
  0x0000324E, // status, 0
  0x00200000, // origin, 1
  0x00000140, // width, 2
  0x00000002, // intr, 3
  0x00000000, // current, 4
  0x03E52239, // burst, 5
  0x0000020D, // v_sync, 6
  0x00000C15, // h_sync, 7
  0x0C150C15, // leap, 8
  0x006C02EC, // h_start, 9
  0x002501FF, // v_start, 10
  0x000E0204, // v_burst, 11
  0x00000200, // x_scale, 12
  0x00000400, // y_scale, 13
};


El VI status es el que controla el AA, el dither, etc como en los hacks que han ido saliendo, si descomponemos la configuración original de la libn64 es un poco raruna.

0x3000 // control
0x0200 // AA resample
0x0040 // serrate
0x0008 // gamma correct
0x0004 // gamma correct dither
0x0002 // 16bit color mode
--
0x324E


- Serrate no debería llevarlo ya que es para modos entrelazados
- Gamma correct es más útil para salida YUV
- El dither es el horror, es como el filtro del Silent Hill sin estar en Silent Hill
- AA resample emborrona, en 2D no debería estar activado, así que he editado a 0x3302 con los cambios pertinentes y sorpresa (la imagen de John D9 [hallow] ):
Imagen

Pensaba que el fallo de las franjas era cosa de la libdragon y es un fallo de la consola, simplemente no le gusta esa configuración en NTSC, me han recomendado algunas configuraciones pero ahí si que toca cruzar dedos.
--

He hecho un test y muy sorprendido, aún me pregunto si el resultado es correcto, se pinta un fondo azul a 320x240 con el RDP y hay un contador de fps dibujado por la CPU, solo eso:
- Libdragon: 505 fps
- Libn64: 1316 fps

El código en sí es el mismo, pero en libn64 está escrito a más bajo nivel.

@cegador
Eso estaría bien, a tí te gustaba modelar 3D no? [360º]
@BMBx64 Le doy mucha vueltas a esos numeros y no logro descifrar que son burst, leap, hstart, vstart, vburst...
width da 320, lo cual no tiene misterio ninguno, y me llaman la atencion los valores de sync, porque siendo 240p, vsync es 525, que son las lineas de un cuatro NTSC estandard en entrelazado (dos fields/campos), lo cual no parece consistente con un modo de video 240p, a no ser que haga sucesivamente campos de 262 y 263 lineas.
Mas misterioso me resulta el hsync, que da 3093, que dividido entre 4 da 773.25, lo cual se aproxima a mis valores de duracion de linea, pero, curiosamente, añade ese decimal, que no entiendo...

Segun la documentacion de viletim (Tim Worthington) del mod RGB, cada pixel son 4 bytes sucesivos (de ahí la division entre 4): señalizacion, R G y B. ¿como leches haces 773.25?

Además, si lo que buscaban era seguir el estandar analogico, el valor sería 773.5, no .25. Siendo así, yo hice calculos para una duraciones de linea de 772, 773 y 774, para usar enteros.

Mi no comprender 773.25, o 3093 ciclos del bus de video. No tener sentido, hao!
Mi no comprender 240p con 525 lineas. Eso ser entrelazado, hao!
@radorn
Ayer hablé con marshall y bueno me pasó una configuración de un ejemplo suyo de la iQUE, que acabó siendo la misma configuración de la libdragon, según él no hay documentación oficial sobre esto, así que deben ser valores que han sacado de algún lado o hay consenso de que sean fiables.

Field 2 según veo es diferente solo en entrelazado.

En principio voy a copiar la config de libdragon a libn64 para darle soporte, luego ya veremos si consigo arreglar lo del AA (que va a ser que no).

De todas formas si te ves con ganas puedes rellenar la estructura de libn64 y te compilo un ejemplo [oki] , aunque desconozco como van asociados algunos valores con otros.
@BMBx64 Pues no se, no quiero freirte la consola xD
la verdad es que no entiendo mas que do o tres de los valores, y de esos aun me confunden que tengan decimales y tal... en fin le daré mas vueltas y si consigo algo que parezca tener sentido te lo paso xD
Venga otra ronda de capturas.

Kirby 64: The Crystal Shards
Creo que es de los juegos con menos pantalla de los títulos analizados, 300x216 con los margenes negros, pero luego tenemos el marcador.
Imagen

En algunos juegos se pinta por debajo del marcador, pero aquí evidentemente no, la pantalla 3D va en una región más pequeña que lo sitúa a 300x172.
Imagen

Un momento.. toda esa geometría, pues oye los niveles están bastante detallados.
Imagen

Con montañas, lagos y otros detalles bien redondeados a diferencia de otros títulos en la consola.
Imagen

Pero yo lo que quiero es darme una vuelta por ellos a ver que hay, así que vamos a seguir el camino que normalmente hace Kirby pero de frente, la geometría supera los 5000 polígonos por escenario, así que como es lógico no lo enseñan desde una posición que se vaya a ver al completo.
Imagen

Los escenarios están adaptados para seguir una cámara guiada, en este caso es un escenario de desarrollo horizontal, así que es alargado y pone el camino más cerca de la cámara para dar la sensación de más profundidad, los fondos a tenor de las extracciones son 2D de varias capas.
Imagen

Los personajes son un buen ejemplo de diseño y uso de goraud, con lo que quedan muy redonditos sin malgastas polígonos, sí, casi 2000 para los 5 juntos.
Imagen

Qué sería de Kirby sin su música, en N64 hay unos temas muy peculiares, a mi me gustan estos:




WWF No Mercy
De éste juego he oído cosas muy buenas, aunque no soy amante del genero me gustó el WWF Super WrestleMania de Mega Drive.

El caso es que tras jugarlo oye se juega muy bien, puedes agarrar con facilidad y hacer llaves al contricante en plan eso lo he hecho yo? Además de ser accesible jugablemente, por lo visto tiene muchas opciones de personalización y modos.

En todo caso, resolución 480x237, sin expansión y se mueve muy suave.
Imagen

WWF Attitude
Al ser de Acclaim esperaba una resolución más alta y no decepciona, 510x237 en éste caso, sin expansión.

Jugarlo ya es otra historia, aunque funciona suave es como dar puñetazos o patadas debajo del agua, a veces pulsaba un botón, me quedaba pensando pero éste botón sirve para algo y ahí llega, atención hace el gesto de querer agarrar al contrincante, pero oh no, se escurre y te pilla por la espalda, pulsas botones, para qué? Te acaba de tumbar y ahí lo tienes subiéndose a las cuerdas para recordarte la tunda que te va a caer [idea]

Con lo que quiero decir es que de jugar alguno sería al No Mercy.

Imagen

Aero Fighters Assault
Me encanta, quizás en otro momento se pueda profundizar en él, resolución útil de 286x208.
Imagen

Supongo que quién lo haya jugado recordará ésta fase y su canción.


@radorn
lol o incluso la tele, aunque las LCD/LED corren menos riesgo, la verdad es que he ido con el culo apretado en algunos tests [jaja]
BMBx64 escribió: @cegador
Eso estaría bien, a tí te gustaba modelar 3D no? [360º]


Sí, estoy un poco oxidado, pero modelar con pocos polígonos estilo N64 me atrevería [360º]
Ya que ésto va de curiosidades y el hilo ésta muy parado dejo un vídeo de como se hicieron las intros de Resident Evil 2 (y no me refiero a meterlas en el cartucho [hallow] )


@cegador
Genial, aunque el desarrollo de las librerías se ha ralentizado por completo, la verdad es que hace un año por esta época era mucho más optimista [burla3]
BMBx64 escribió:Ya que ésto va de curiosidades y el hilo ésta muy parado dejo un vídeo de como se hicieron las intros de Resident Evil 2 (y no me refiero a meterlas en el cartucho [hallow] )


@cegador
Genial, aunque el desarrollo de las librerías se ha ralentizado por completo, la verdad es que hace un año por esta época era mucho más optimista [burla3]


¡Buen vídeo!

Estas cosas van cómo van, cuando haces algo "por amor al arte" los avances van a rachas.

Hay que tener fe [angelito]
Gracias por el video @BMBx64 [oki]

Y gran juego este RE 2, si bien N64 no tuvo todos los RE, creo que se llevo el mejor juego de la trilogía original de esa generación XD , porque del primero es mejor el REmake.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@Oystein Aarseth casi 2 años más tarde, y mucho más caro, en lo que por lo demás no es más que un desierto de survival horror's en ese sistema, el género de moda en aquella generación; pero sí, hay que alabar ese port, mejor eso que nada, y teniendo en cuenta las limitaciones salió bastante bien [hallow]
Mirad qué he encontrado:

Velvet Dark, la hermana de Joanna Dark (según el artículo era un personaje seleccionable en el multiplayer de PD :-? ) iba a tener su propio juego.

Imagen

Iba a ser una precuela de Perfect Dark y en tercera persona en vez de en primera... un juego de infiltración estilo Metal Gear.

Imagen

Según el documento de diseño, iba a tener alguna compatibilidad con GB/GBA, la protagonista tenía una especie de "subidas de nivel" mediante algo llamado "serum", algo de combates tácticos...
Imagen

Artículo en inglés aquí:
https://www.unseen64.net/category/nin/nintendo64-64dd/page/2/
Oystein Aarseth escribió:Gracias por el video @BMBx64 [oki]

Y gran juego este RE 2, si bien N64 no tuvo todos los RE, creo que se llevo el mejor juego de la trilogía original de esa generación XD , porque del primero es mejor el REmake.


Yo siempre espere el RE0 version N64 [sonrisa]. Lo esperaba con muchas ganas en la consola pero bueno... lo cancelaron y salio pal cubo.

Seria genial que en una hipotetica N64 mini lanzaran de regalo esa version (RE0 N64) como hicieron con el star fox 2 en snes mini... seria genial.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@sinovic ¿no está ese unreleased en forma de rom por ahí rulando aún?
Sexy MotherFucker escribió:@sinovic ¿no está ese unreleased en forma de rom por ahí rulando aún?


No que yo sepa, lo unico que he encontrado son solo videos. En su tiempo busque la rom sin existo. Pero ojala que existiera... pero... ¿estara terminado?. El que yo se que anda por ahi en la red es el prototipo de RE2 (1.5) de psx con elza walker, pero del 0 nada... :-?
sinovic escribió:
Oystein Aarseth escribió:Gracias por el video @BMBx64 [oki]

Y gran juego este RE 2, si bien N64 no tuvo todos los RE, creo que se llevo el mejor juego de la trilogía original de esa generación XD , porque del primero es mejor el REmake.


Yo siempre espere el RE0 version N64 [sonrisa]. Lo esperaba con muchas ganas en la consola pero bueno... lo cancelaron y salio pal cubo.

Seria genial que en una hipotetica N64 mini lanzaran de regalo esa version (RE0 N64) como hicieron con el star fox 2 en snes mini... seria genial.


Preferiria el Mother 64, que se confirmó que estaba acabado..
http://starmen.net/eb64/images/
ewin escribió:
Preferiria el Mother 64, que se confirmó que estaba acabado..
http://starmen.net/eb64/images/


Cuestiones de gusto supongo. En lo personal no soy fanatico de los RPG. XD
@cegador muy guapo eso de la precuela de Perfect Dark. Aunque por la compatibilidad con GBA de haber salido lo habría hecho para el Cubo seguramente.
sinovic escribió:
ewin escribió:
Preferiria el Mother 64, que se confirmó que estaba acabado..
http://starmen.net/eb64/images/


Cuestiones de gusto supongo. En lo personal no soy fanatico de los RPG. XD

Entonces te encantará N64 [sati]
@sinovic @Sexy MotherFucker
Confirmo con bastante seguridad que no hay ROM de ningun prototipo/beta de RE:0 en circulacion, y creo que tampoco hay noticias de que haya ningun coleccionista que lo tenga y haya dicho "esta boca es mia".
Creo que los de CAPCOM sacaron algo hace no demasiado donde sacaban imagenes del prototipo, posiblemente de un port del codigo original a otra plataforma o algo así, al estilo de los ports de N64 de Rare en el recopilatorio RARE Replay.

@ewin
¿Donde has leido eso de que MOTHER 3 / Earthbound 64 estaba terminado (o casi) pero no lo sacaron?
Yo lo que siempre leí es que tenian tantos problemas de desarrollo y tantos bugs (algunso dicen que por la inexperiencia en 3D del equipo y la ambicion del proyecto), que Nintendo se cansó de meter dinero en el tema canceló el proyecto viendo que ya iba a salir la sucesora de N64, que el 64DD no iba a ninguna parte y tal.
Vamos, yo lo de "acabado" nunca lo habia leido.

@cegador @Falkiño
Ciertamente, el juego de Velvet Dark, aunque tecnicamente empezó en la era de N64, llegase a donde llegase en su desarrollo, no iba a salir hasta la siguiente generacion, eso está claro, ya fuera en GC con Nintendo o en XB con Microsoft.
Lo triste es que MS no continuase el desarrollo. Es cierto que la Rare que Nintendo vendió ya no era la misma Rare de su apogeo en SNES y N64, pero desde luego con MS se fue a la mierda. Que un mito como Rare acabase casi relegada a chorradas como Kinect Sports es un lamentable destino.
¿Han tenido exito con su MMO de piratas?
@radorn En un reportaje de la (ahora cerrada) web 64dd.net, que era la principal fuente de información acerca del 64dd hasta hace unos años (previo a la wikipedia).El comentario de la falta de experiencia del equipo (más del de Ape inc que Hal) viene de la wikipedia y, desde ahi, se ha venido repitiendo sin más. Es cierto que sus desarrolladores tenían más experiencia con los juegos 2d pero disponian de un kit de desarrollo del 64DD (versión avanzada del de Nintendo 64) desde el primer dia. Al quedarse por el camino el 64DD (que tenia tanto éxito en japón como un helado de mierda) se traspasó a N64, realizandose las adaptaciones oportunas. Para este proceso ya contó con parte del equipo de desarrollo del Zelda 64 Ura. Dato que tampoco aparece en muchas partes.y que salió referenciada en dicha review (la de 64dd.net) y en una de Famitsu a Shigesato Itoi donde reconoció problemas de tiempos.

El verdadero problema fue no solamente el paso de 2d a 3d sino que por el cambio de rumbo de Nintendo a mitad de desarrollo (todo pensado para el 64DD), les tocó rehacer el juego para meterlo en un cartucho del tamño del zelda, recortando, quitando ideas originales de aqui y de allá y sobretodo, eliminando zonas enteras pues no habia espacio fisico para ello (tenian una carga dinámica). Fue un follón por culpa de Nintendo que cambió de idea pero no tocó ni un dia los plazos. Sin embargo, con el juego a un 90%, les dieron un ultimatum aún dandoles un par de meses de más en el plazo. Con el juego ya acabado, en fase beta (busca de bugs) se les dijo que no porque no lo consideraron acabado. Pero lo estaba tanto como para plantearse como titulo de lanzamiento, puliendolo, para gamecube. Imaginate si estaba acabado. Aqui aportan la visión de Iwata de lo que pasó:

https://www.wikibound.info/wiki/EarthBound_64

" Other aspects of development were shortchanged as well, as Iwata stated in an interview regarding the devleopment of Mother 3 for N64, "any normal project has a trial period where you make a sample product and get the green light based on the response. But MOTHER 3 was special in that we skipped the trial period and went straight to game production. Without that trial period, all we had was our experience and achievements from making MOTHER 2, without the benefit of starting off with a team of people who worked on MOTHER 2". These shortcuts were primarily due to financial concerns. Development also was impacted by the financial situation at HAL Laboratories, and their lack of ability to afford to train talent". At the end of the day, the team realized they felt an obsessive need to force something that did not need to be 3d, into 3d, and that to tell the story they wanted to, 3d was not necessary."

Según HAL, el dia de la cancelación el juego estaba al 90% de desarrollo. Según Iwata al 30% y según Miyamoto, a nivel global, a un 60%. ¿quien miente?

"In an interview, Satoru Iwata estimated the game was about 30% complete, while Miyamoto believed it was approximately 60 percent complete from a programming perspective. Apparently a complete script was produced but not perfected."

EDIT EXTRA: 6 años mas tarde salió el juego reconvertido a 2d en GBA. Se aprovechó casi toda la historia, diseños, localizaciones, algunos personajes (tanto NPC como personajes). El script del juego sin embargo se guardó en una carpeta. Decir que en uno de esos "festivales" que celebraba Nintendo en wii, sacando juegos de otra región en la VC de manera excepcional se estudió sacar el juego pues, de golpe "el juego podia interesar al estar casi acabado". Se nombraron tres opciones, una desconocida y dos juegos que "por el estado en que estaban de desarrollo eran opciones solventes para salir, si se dan las condiciones, en próximos eventos" (dixit en Comupter an Videogames, Ninteno UK preguntado al efecto). ¿Que otros dos titulos eran? Pues StarFox 2 y Mother 64. Finalmente el AS del starfox 2 se lo guardaron para la snes mini.

¿Ves la jugada?
Ostia, meter el Mother de N64 en la N64 mini (de la misma manera que metieron el Starfox 2 en snes mini) sería la ostia [boing]
3572 respuestas
Responder
1…29, 30, 31, 32, 33…72
Volver a Consolas clásicas