Hilo de detalles y curiosidades de N64

Responder
1…35, 36, 37, 38, 39…72
@radorn, tienes un mensaje privado.

He incluido otra versión del mapa con las texturas de las cajas de madera espejadas y también el camino de piedra sólo para que se vean sus pros y contras. Dejo una captura de emulador como las de ayer.

Imagen

Probando más a fondo todas las versiones en consola más a fondo, la falta de filtrado trilineal realmente sólo lo hecho en falta en las texturas de las cajas de madera y de las paredes cuando uso la textura de 64x128 a escala de grises. Parece que en texturas sin mucho cambio de contraste o líneas marcadas se disimula mucho más.

Estos ejemplos los he hecho sin meterme a modificar la geometría. Se podría conseguir mucha más definición en las texturas manteniendo el color e incluso el filtrado trilineal a costa de multiplicar la carga poligonal.
Por ejemplo estoy viendo que las texturas de las paredes no se repiten verticalmente, por lo que podría partir las paredes en dos filas y tener dos texturas de 64x64 a 16 colores (sin filtro trilineal) o partirlas en 4 filas y usar 4 texturas de 64x32 a 16 colores (y tener filtro). Algo similar se puede hacer con las cajas y el camino. Se pueden partir la geometría en 2 y así usar dos texturas de 32x64 a 16 colores y mantendríamos el filtrado trilineal. Son números razonables para un mapa de 1 jugador, pero habría que ver cómo funcionaría a pantalla partida a 4 jugadores.
Con el suelo no hay mejora posible a menos que dediquemos una burrada de polígonos para ello (4 por cada repetición de la textura y 2 texturas de 32x64 con 16 colores). Claro que podemos llevar esto al absurdo y trocear el mapa un una cuadrícula donde encajar trozos de textura de 32x32 a 256 colores y así mantener el detalle de las texturas originales, todos sus colores y todos los filtros (a costa de un rendimiento lamentable con toda probabilidad [qmparto] ).

De los mapas del Counter Strike de Monkeyface sí tenía conocimiento. Wreck estuvo actualizando los parches antiguos para hacerlos compatibles con el hardware real y probablemente también lo actualizara. Pero no son ports directos sino mapas con un diseño propio y mucho más reducido que los originales.
Yo creo que para hacer un mapa de CS, lo más similar al original, habría que redibujar las texturas, más que usar una profundidad de color y resolución que quepa en la caché, por experiencia se aprovecha mejor las paletas haciéndolo de cero que haciéndolo automatizado con un programa. No se como funciona GE , en el tema de partir los escenarios, pero si que le haría falta para no cargar el escenario entero y permitir subir el polinaje, para adaptar texturas en mosaico.

¿Hay alguna forma de hacer escenarios en blender para GE/PD?


Salud.
ACTUALIZATION SUPERFLUA:
Hay un pequeño problema técnico con la captura de este video. Las consolas NTSC de Nintendo, y, por algunos indicios que he visto, probablemente todas las demás fabricadas en Japón, producen una señal NTSC-J, que es ligeramente diferente de la señal NTSC-M original americana. La diferencia es que el nivel de voltaje que representa el color negro en el estandar original americano es un poco mas alto que el nivel del negro en el estandard japonés, que es igual que en PAL. En una TV analógica esta discrepancia se suele corregir a niveles aceptables simplemente dando un poco mas de brillo, pero en capturas digitales, donde niveles especificos se traducen a valores discretos, si la captura se hace incorrectamente, el resultado puede ser un poco mas dificil de corregir.

Basicamente el resultado de todo esto es que si capturas NTSC-J como si fuera NTSC-M (o "normal") la imagen queda algo oscurecida, y los detalles en zonas poco iluminadas pueden perderse de forma irrecuperable.

http://www.glennchan.info/articles/tech ... setup.html

Como hacía tiempo que no capturaba nada, me había olvidado de este detalle, y cuando capturé este video, me quedé extrañado de que la imagen parecía mas oscura de lo debido y no acababa de acordarme del detalle, y es que estaba capturando en NTSC-M y no NTSC-J como debería.

Mi capturadora puede ponerse en ambos modos, M y J. Lo unico que le falta es que, si bien tiene modo PAL y PAL-60, y tambien NTSC y NTSC-50, lo que no tiene es "NTSC-J-50", que es como se podría llamar a lo que saca la N64 NTSC(J) con software PAL, por tanto si quiero capturar juegos PAL con esta consola NTSC que uso actualmente como principal, va a quedar siempre oscuro.

En fin, todo este rollo es la explicación de que la imagen se vea algo oscurilla de más, en el dudoso caso de que alguien se lo hubiese preguntado.

----------------- POST ORIGINAL -----------------
Primeros resultados. Solo la misma escena con cada una de las ROMs durante un segundo, encadenadas para ver las transiciones facilmente, en bucle repetido tres veces.


Si hace falta, puedo poner imágenes estáticas y subir mas video que he grabado, acercandome mas a los objetos, para verlos de perfil y ver el efecto del TLMMI o la falta de el, y haciendo movimientos de camara lentos para ver el aliasing de texturas.
EDITO: https://www.youtube.com/playlist?list=P ... cKCDMUr6pY

Por cierto, que hice los codigos de botones para desbloquear el truco de todas las armas, municion infinita, invencibilidad (para no autoreventarme con la exlosiones) y paintball, para hacer el tonto. Pero al activar cualquier truco DAM desaparecía del selector de misiones. Sin embargo, al darle a A o START, sin importar de donde apuntase la mirilla, estando todos los fotogramas de las misiiones en negro, me salió la mision de SILO, pudiendo incluso jugarla.
Muchas gracias por los vídeos @radorn. Los has grabado concienzudamente para mostrar todas las diferencias. [oki]

Ya te comenté que las colisiones no están hechas y que aproveché lo que pude de los triángulos del escenario para salir del paso, por lo que hay muchos sitios por los que no se puede pasar XD.

En el tercer vídeo se puede ver una cosa curiosa con la textura del suelo empedrado y es que hace una especie de mipmapping cuando por el tamaño de la textura es imposible.
En texturas con paleta de colores (también existen texturas con paleta en escala de grises) la caché de 4 kB se parte en dos y una mitad alberga la paleta (da igual que sea de 4 o de 8 bits) y la otra mitad la textura en sí con los mipmaps si fuese posible. En este caso la textura es de 64x64x4 bits, lo que llena los 2 kB sin posibilidad de que se generen mipmaps (una textura de 32x32 ocuparía 1kB y usaría el otro kB para los mipmaps).
Lo que se ve en el vídeo me estaba ocurriendo también con las texturas de 64x128 aunque en esos casos sí que conseguí arreglarlo. Aún conservo esa rom porque el efecto era muy curioso: en la textura de la pared con ventanas, cuando estabas lo suficientemente lejos como para que actuara el primer nivel de mipmaps (aunque en este caso debería de empezar a pixelizarse la textura) las ventanas desaparecían y parecía la textura de la pared normal. Hacía incluso la interpolación como si fuese un mipmap verdadero. Pero como en el caso del suelo empedrado, se puede ver que estos falsos mipmaps lo que hacen es coger trozos de la textura y descartar otros por lo que no queda una imagen escalada. Tengo que investigar más sobre este tema a ver si es posible simular filtro trilineal con texturas que se supone que no deben tenerlos y diseñar texturas con el bug o lo que sea en mente para que el resultado quede decente.

El problema de los mipmaps que genera la Nintendo64 es que se emborronan más de lo que deberían. Si creamos nuestros propios niveles de mipmaps a partir de la textura grande el resultado es bastante más nítido. Claro que esto supone trabajo y tiempo extra y también ocupan espacio en la memoria y en el cartucho (aproximadamente un 30% más que si no generásemos nuestros propios mipmaps) por lo que no creo que se usase más que para hacer trucos con esta técnica (como el retrato de Peach/Bowser en Super Mario 64).

También es muy curioso lo que mencionas de los trucos. Nunca había oído nada igual. No sé si en una rom sin modificar también ocurre.
Sogun escribió:Ya te comenté que las colisiones no están hechas y que aproveché lo que pude de los triángulos del escenario para salir del paso, por lo que hay muchos sitios por los que no se puede pasar XD.

Ya, pero no me iba a quedar quieto, como comprenderás. Me recorrí los escenarios a conciencia y me salí muchas veces del escenario, y aproveché para recorrerme la nada exterior, Y casi siempre pude volver a entrar en el clipping. Tambien muchas veces me quedé atrapado en un triangulo sin poder ya salir de el...
En el video se me ve intentando "empujar", o recular y entrar por otro angulo, porque a veces funciona y todo, si es que hay algo al otro lado, claro. En fin, había que intentarlo xD.

Cuando hace años estaba haciendo el mapa de fort knox tambien me ocurrieron cosas raras con los mipmaps.
En la textura de las ventanas, de cerca, con el mipmap 0, todo bien, pero a medida que iban saliendo los siguientes, cada uno estaba mas corrupto. Fue hace mucho tiempo, y no recuerdo los detalles ni conservo nada de aquello, por desgracia.
Tambien recuerdo un proyecto de EternallyAries, de un mapa multi basado en las texturas de Super Mario Bros de NES, donde las texturas se desnaturalizaban enormemenente a medida que entraban los mipmaps en juego, especialmente la de ladrillos, que con cada mipmap iba degenerando en una masa de marron super oscurocon algunos puntitos de verde amarillento, hasta finalmente quedarse en un negro solido.
Me llamó tanto la atención que hice un analisis bastante exhaustivo.

Parece como si hubiese algun tipo de configuración especial, algun ajuste extra sobre cómo generar los mipmaps, y que un tratamiento universal no necesariamente funciona bien o algo así... no lo se.

Sogun escribió:En el tercer vídeo se puede ver una cosa curiosa con la textura del suelo empedrado y es que hace una especie de mipmapping cuando por el tamaño de la textura es imposible.

Yo creo que mas bien es el aliasing, porque aunque el efecto quede emborronado como si fuera TLMMI, en realidad el aspecto original de la textura queda totalmente desvirtuado, que es precisamente en lo que consiste el aliasing. O sea, ya no es una version reconocible pero de baja resolución, si no un amontonamietno de pixels sin mucho orden. Claro, como esas texturas ya son superficies irregulares con un aspecto mas o menos natural o de algo envejecido, etc... pues bueno, el aliasing, aunque las haga irreconocibles, no las convierte en algo tan alejado del proposito original, Pero seguro que si la textura original fuese de algo mas regular u ordenado, sí habría una diferencia mas grande entre la zona normal y la afectada por el aliasing que dificilmente parecería un mipmaping accidental.

Sogun escribió:Si creamos nuestros propios niveles de mipmaps a partir de la textura grande el resultado es bastante más nítido.

Obviamente, pero: ¿Tiene el motor de GE soporte nativo para hacer tal cosa? ¿Permite el editor importar texturas con mipmaps precalculados? ¿O hay que hacer hackeos de bajo nivel para hacer tal cosa?
@radorn

La textura del suelo empedrado en el segundo vídeo y en el tercero es la misma y con los mismos parámetros (lo comprobé varias veces y creo que no se me pasó nada) y en el segundo vídeo se comporta como era de esperar y en el tercero hace esa cosa rara.

Los mipmpas generados por la consola a veces hacen cosas raras como bien dices. A veces quedan mal y otras bien XD.
Un ejemplo de lo malo se puede encontrar en mi parche Golden Nintendo Maps si elegimos el nivel de Surface 2. Apareceremos en la sala del jefe del Templo del Bosque de Ocarina of Time y si nos dirigimos a la sala del ascensor veremos que en una textura del suelo aparecen unos píxeles negros enormes cuando actúan los mipmaps.
Ejemplos que queden bien (o al menos a mí me lo parecen) se pueden encontrar en el mismo mapa del Templo del Bosque (pero esta vez cargamos el nivel correcto) y hay que llegar hasta una habitación tras el pasillo en espiral que tiene una especie de foso de ponzoña rosa con una capa de niebla por encima. En consola y gracias a los mipmaps autogenerados esa ponzoña rosa tiene un aspecto gelatinoso muy sorprendente.
Otro caso que queda mal pero mola es en Goldfinger 64 en el tercer nivel (Miami) hay unos toldos al principio que son rojos y con los mipmaps se ponen azules. ¡No tiene ningún sentido! [qmparto]


El Editor sí que tiene soporte nativo para usar nuestros propios mipmaps aunque el proceso es algo oscuro. Así es como hice el truco del retrato en el castillo del Mario 64 y también me ha permitido arreglar algunos desaguisados que me hacían los mipmaps (en el mapa de la casa de Boo del Mario 64 las barandillas se volvían totalmente azules y tuve que generarlos yo mismo para que no ocurriera).
Sogun escribió:La textura del suelo empedrado en el segundo vídeo y en el tercero es la misma y con los mismos parámetros (lo comprobé varias veces y creo que no se me pasó nada) y en el segundo vídeo se comporta como era de esperar y en el tercero hace esa cosa rara.

Ah, si, ya veo lo que dices. Es curioso, desde luego, sobre todo si dices que están configuradas de la misma manera.

Sogun escribió:El Editor sí que tiene soporte nativo para usar nuestros propios mipmaps aunque el proceso es algo oscuro.

Bueno saberlo. ¿Cuántos niveles de mipmap se pueden hacer?
radorn escribió:Bueno saberlo. ¿Cuántos niveles de mipmap se pueden hacer?

El máximo son 7 niveles pero me cuesta pensar en una textura que necesite más de 6. Se supone que la textura original es el nivel 0. Quizás algunas texturas rectangulares sí que necesiten los 7 niveles.

Una textura de 64x64 a 4 bits de escala de grises sería tal que así:
Nivel 0: 64x64
Nivel 1: 32x32
Nivel 2: 16x16
Nivel 3: 8x8
Nivel 4: 4x4
Nivel 5: 2x2
Nivel 6: 1x1

Una textura 16x256 a 4 bits en escala de grises podría ser:
Nivel 0: 16x256
Nivel 1: 8x128
Nivel 2: 4x64
Nivel 3: 2x32
Nivel 4: 1x16
Nivel 5: 1x8
Nivel 6: 1x4
Nivel 7: 1x2
Nivel 8: 1x1 (este nivel no se podría alcanzar)
Aunque nunca he probado algo así.

Te pongo el ejemplo de los mipmaps que utiliza el truco del retrato del Mario 64.
Imagen

PD: Photobucket hace tiempo que se había puesto pesado pero ahora con la marca de agua me está tocando las narices. ¿Qué otra web para subir imágenes me recomendáis?
[pedantería]
Sogun escribió:Se supone que la textura original es el nivel 0
lo se :)
radorn escribió:En la textura de las ventanas, de cerca, con el mipmap 0, todo bien, pero a medida que iban saliendo los siguientes, cada uno estaba mas corrupto.

Sabiendo eso, técnicamente esto es incorrecto
Sogun escribió:El máximo son 7 niveles
en realidad son 8 niveles de mip-map en una textura "mip-map-eada" xD, dado que el nivel 0, la textura a tamaño completo, tambien se cuenta, como en todo sistema de numeración binario.

Es como contar con 8 bits, o un byte. ¿Cuantos valores puedes representar con 8 bits? 256. Pero, como lo lógico es contar desde 0, el valor máximo acaba siendo 255.
[/pedantería]

En ese ejemplo de 16x256 que has puesto, me llama mucho la atención que puedas seguir reduciendo la textura una vez una de las dimensiones ya ha tocado fondo, llegando a 1 pixel. ¿Seguro que se puede hacer eso? Porque técnicamente eso supone alterar las proporciones de la textura...

En fin. No se si es una buena recomendación, pero para colgar imágenes, tiendo a usar este https://postimage.io/
Por ahora parece que funciona bien. Para lo poco que lo uso, no tengo ni cuenta.
radorn escribió:En ese ejemplo de 16x256 que has puesto, me llama mucho la atención que puedas seguir reduciendo la textura una vez una de las dimensiones ya ha tocado fondo, llegando a 1 pixel. ¿Seguro que se puede hacer eso? Porque técnicamente eso supone alterar las proporciones de la textura...


No he probado ejemplos tan extremos así que no podría confirmarte si se puede hacer o no. Pero me parece que sí porque ahora he recordado que las texturas del nivel de Aztec también tienen mipmaps pre-generados y estas texturas tienen unas proporciones muy raras y las divisiones no son exactas. En palabras de Martin Hollins (el director del juego GoldenEye) hicieron las texturas del tamaño máximo que cabía en la caché tal y como decía Hollis.

Imagen

Haciendo unos cálculos:
Base: 128*47*4 bits / 8 = 3008 Bytes
Nivel1: 64*24*4 bits / 8 = 768 Bytes
Nivel2: 32*13*4 bits / 8 = 208 Bytes
Nivel 3: 16*7* 4 bits / 8 = 56 Bytes
Nivel4: 8*4*4 bits / 8 = 16 Bytes
Nivel5: 4*3*4 bits / 8 = 6 Bytes
TOTAL = 4062 Bytes. En realidad creo que son más porque la información de las texturas se guardan en bloques horizontales de 8 Bytes y entonces los niveles 4 y 5 de los mipmaps ocuparían 32 y 24 Bytes respectivamente haciendo un total de 4096 Bytes que significa ocupar todo el espacio de los 4 KB de la caché.

Desde hace un tiempo el Editor te permite ver los mipmaps pre-generados en las texturas que los usan además de otras cosas muy prácticas como seleccionar el color que quieres que haga de transparencia (ya no estamos limitados al negro) e incluso editar la paleta de colores desde Image Tools.
Lo que he señalado en rojo te da información sobre la textura. El primer carácter te dice el tipo de textura que es (color a 4 bits, color a 8 bits, en escala de grises, texturas con varios niveles de alfa, etc) y el segundo carácter te indica el número de mipmaps que tiene la textura. Este segundo número es el que me está confundiendo porque va de 0 a 7 y en el caso de esta textura el 6 corresponde a la textura base + los 5 niveles de mipmaps. La confusión me llega cuando para arreglar el falso mipmapping de las texturas de 64x128 que mencionaba antes (y de la textura del suelo empedrado aunque en un nivel no conseguí arreglarla) tuve que cambiar ese número a 1 cuando de toda la vida las texturas sin mipmaps tienen un 0 (es que el mismo editor te las importa así). Y es que tengo el resto de texturas de 64x64 a 16 colores con ese dígito en 0 y no dan problemas. A veces da la sensación de que el 0 y el 1 hacen lo mismo.
@Sogun Gracias por la explicación. La verdad es que cuando ya se entra en los detalles específicos del motor del juego, con los numeros de tipo y demás, ya se me escapa. Nunca entré en tanto detalle con el juego.

En fin, cambiando de tema momentaneamente, me he topado con este video donde se explica detalladamente la técnica de "tool assisted speedruning" para Mario 64 llamada "universos paralelos", y la verdad es que parece una clase de mecánica cuántica xDDDDDDD
He estado trasteando con los modelos del juego de la primera PlayStation Legacy of Kain: Soul Reaver porque es un juego realmente fascinante en cuanto a tecnología y el resultado final parece magia para el sistema en el que fue diseñado. Muy recomendable el vídeo que le dedicaron en DF Retro hace un tiempo:



Ya lo he comentado en anteriores mensajes, pero necesito repetirlo para introducir el mensaje. Se trata de un juego que abusa a lo bestia de ir cargando datos en streaming duplicando datos en el CD para tener accesos más rápidos, utilizando objetos en lugar de geometría del escenario para elementos que se repiten y así cargarlos una vez y copiarlos a partir de entonces, empleando una misma textura pero con diferentes paletas para sólo cargar una textura y simplemente variar los colores como las consolas de 8 y 16 bits con los sprites (no es lo mismo que lo que hace la N64, que guarda la paleta con la textura, por lo que por cada variación de color habría que tener una textura nueva). Lo de las texturas es algo que no pudieron hacer en el port de PC y tuvieron que guardar por separado todas las variantes, ocupando el archivo contenedor de todas las texturas 160 MB.
Técnicamente es una bestia, no sólo por la ausencia de cargas si no por la enorme calidad de sus texturas, resolución de 512x240, rendimiento muy suave para la cantidad de polígonos que mueve en pantalla y efectos chulos. Lo único criticable podría ser la escasa distancia de dibujado en espacios abiertos, aunque muchas partes del escenario están diseñadas para evitar esto.

Tras encontrar las herramientas para extraer los modelos y texturas del CD y hacerlo funcionar todo más o menos para portar algunas cosas a GoldenEye os pongo algunos números. No puedo hacer un port directo de momento, hay que rehacer muchas cosas y dejaré esta pequeña prueba para el futuro. Continúo en secreto que hay imágenes grandes:

Primero una parte del escenario. Se supone que el juego mantiene cargadas 3 zonas parecidas en todo momento (en la que se encuentra el jugador y las dos adyacentes) y que cuando el jugador se desplaza a la siguiente zona descarga él área más alejada y carga la que sería la próxima. Estas zonas están diseñadas de forma que al jugador no le da tiempo a recorrerlas lo suficientemente rápido como para llegar a la siguiente antes de que cargue. Uno esperaría zonas muy ligeras para que carguen rápido, y sin embargo la zona que he capturado tiene la burrada de 3380 triángulos y 84 texturas de 64x64 a 16 colores.

Imagen

Imagen

En realidad las texturas no vienen separadas como en la imagen de arriba (las he separado yo) si no en imágenes de 256x256 con algunos huecos en blanco. Lo que me ha sorprendido es que en una misma de estas imágenes se combinen texturas "verdes" con "marrones", es decir, que parece que cada sector de la textura más grande tiene su propia paleta.
Había separado las texturas creyendo que habría trozos que se repetirían y así podría optimizar la carga de texturas pero no es así. Al menos yo no veo dos texturas iguales. Es una salvajada.
Otra salvajada es la carga poligonal del escenario, perfectamente troceado para utilizar estas texturas. Jet Force Gemini hace algo parecido aunque mucho menos ambicioso y con peor resultado.

Imagen 1167 triángulos, 59 texturas
Imagen 2943 triángulos, 58 texturas

Otro detalle a destacar de los escenarios de Soul Reaver es que tienen una versión alternativa que se encuentra en el mismo modelo. Simplemente cambian las coordenadas de algunos vértices y también su coloreado para darle un aspecto bastante diferente.

Imagen


Por último comentar sobre el modelado del protagonista. Destaca por la cantidad de texturas pero poligonalmente está en la media de Nintendo 64 quedando por debajo de modelados de los juegos punteros con 640 triángulos. Lo más comparable que se me viene a la cabeza serían los enemigos de Perfect Dark.

Imagen
Imagen

La verdad es que me entra mucha curiosidad de probar estos escenarios (evidentemente no enteros) en los motores gráficos de GoldenEye y Perfect Dark y ver cómo funcionan.

Una pregunta para @Conker64 aunque me parece que ya me sé la respuesta (lo he puesto más arriba): ¿Puede la Nintendo 64 guardar las paletas de colores por separado de forma que a una misma textura (una matriz de píxeles para entendernos) se le puedan aplicar indistintamente estas paletas? ¿O por la forma en que funcionan las cosas en Nintendo 64 la matriz de píxeles y la paleta están juntas en un mismo archivo y se tiene que crear y procesar todas las texturas por separado?
Un ejemplo práctico sería el nivel de Pelagic II en Perfect Dark en el que muchas partes del submarino utilizan el mismo diseño de texturas pero distintos colores y lo que hizo Rare fue crear cada textura por separado.
@Sogun
Hola, me pillas de casualidad, apenas paso últimamente.

Sí, textura y paleta se pueden guardar/cargar por separado, dependen del engine o del contenedor de formato que usen para cargarlas.

Yo cuando generaba texturas de 8 o 4bit creaba 2 ficheros, la textura que es un índice de 0-255 y la paleta, que contiene la información de colores de ese índice.

En el caso de las 4bit en realidad se siguen usando datos de 8bit pero con los bits altos y bajos para almacenar 2 valores. (4+4)

Para subirlas a TMEM textura y paleta van por separado en 2 comandos distintos, también puedes ir cambiando de textura sin actualizar paleta si viene una ronda donde todas usan la misma, pero eso ya depende de como el motor gestione.
Conker64 escribió:Sí, textura y paleta se pueden guardar/cargar por separado, dependen del engine o del contenedor de formato que usen para cargarlas.

Para subirlas a TMEM textura y paleta van por separado en 2 comandos distintos, también puedes ir cambiando de textura sin actualizar paleta si viene una ronda donde todas usan la misma, pero eso ya depende de como el motor gestione.


Gracias por la respuesta. No pensaba que la N64 pudiera trabajar así ¿Sabes si algún juego comercial llegó a cargar las paletas de esa manera? Ahora que lo dices me suena que 007 The World is not Enough sería uno de ellos. He encontrado el mensaje de zoinkity donde habla del tema:
I would like to point out that most TWINE stages have a idiotic number of textures that makes it variably infeasible to impossible to include them in Rare's games. The room limit exceeds PD's engine even, but at least merging rooms (and dropping off useless things) can compensate for that. I might add that palette swapping is used often in TWINE but unsupported in GE/PD, requiring unique images for these. Inline textures can not be used for any telemetry with collisions.

Both games (due to hacking) now have a texture limit of 4094 unique images. Expect any TWINE single-player stage to eat almost half of that, and any MP (besides Labyrinth) to eat 25% - 33%. It seems the more accurate the decompiler gets the worse the texture consumption is. Honestly, the stages really need to be cleaned up too. They didn't tile textures; they drew new quads instead.

TWINE loads data on a per-stage basis, more like the Banjo titles, using direct ROM access. GE and PD use an indexed list of all textures and their features. Changing that would require such a radical alteration to the engines I can't even guess what's involved.


Supongo que aún haciéndolo de esta manera se sigue sin poder usar mipmaps en texturas de 64x64 con 4 bits de color porque sigues necesitando la mitad de la caché para cargar la paleta. Pero al poder reutilizar paletas o texturas es más rápido que tener cada textura con su paleta en como se hace en casi todos los juegos.

-----

Aprovecho que he editado el mensaje de arriba con la carga poligonal y de texturas de los escenarios de Jet Force Gemini para añadir aquí otro trozo de escenario que no aparece en el juego y que tampoco he visto en ninguno de esos vídeos que muestran contenido sin usar encontrado en el cartucho.

Imagen
El nombre de la zona es Alpha Sewer Boss. ¿Significa esto que Sekhmet iba a ser el nivel final de uno de los personajes y tener su propio jefe?
@Sogun
Pues no he mirado la verdad, pero libultra usa macros y formatos propios de textura con herramientas de conversión, puede que no muchos equipos las hicieran a mano o llamaran a comandos sin usar las macros.

Lo de JFG mola, siempre he querido ver más material escondido en la rom [360º]
@Sogun De hecho ya se publicitaba por la época del Soul Reaver que era un juego sin cargas. La verdad es que es una proeza para aquellos años
conker64, podrias hacer un analisis del evangelion 64 ?
En gbatemp, dicen que el SM64 a sido descompilado, no se si al 100% pero dicen que los archivos se pueden encontrar por la red.
https://gbatemp.net/threads/super-mario-64-has-been-decompiled.542918/
@doblete ¡Gracias por el aviso! [oki]
Mira que llevo años registrado en GBAtemp, pero nunca me paso, no se por qué. [tomaaa]

En fin, el responsable de la criatura parece estar bastante mosqueado porque alguien filtró el proyecto antes de que estuviera el trabajo 100% rematado. Por lo visto les falta terminar de renombrar todas las funciones, pero es 100% funcional y se puede compilar con el SDK original dando como resultado una ROM 100% identica a la oficial.

Interesante noticia, desde luego. A ver en qué resulta.

Personalmente me interesaría mas el decompilado de otros juegos con motores mas avanzados, pero sin duda tener un codigo fuente funcional de Mario 64 es todo un puntazo.

@Conker64 ¿Le echas un vistacín? [angelito]
https://warosu.org/vr/thread/5644072
si lo quitan tengo copia
Estupenda noticia. Ayudará a más gente a entender como programar en N64 y a mejorar la scene de la consola.
@EMaDeLoC Hablan de portar el juego nativamente otros sistemas, tambien.
Aunque a mi me interesa mas lo que se haga en el hardware original, la idea de un motor "OpenMario64" multiplataforma tambien tiene su cosa, con mil variantes, ¡como el DOOM! xD

He visto que el entorno de desarrollo que indican para este codigo fuente es el SDK para las estaciones de trabajo Silicon Graphics Indy originales, pues mencionan el uso del emulador correspondiente y el uso de Irix, la variante de Unix que usan esas máquinas..
En fin, puede que esto tarde aún en dar sus frutos...
Muy interesante lo de tener el código fuente del Super Mario 64 pero no termino de comprender la importancia de este hecho existiendo multitud de hacks del juego en los que hay cosas inverosímiles o cosas como el editor del GoldenEye que te permite cambiar prácticamente todo el contenido del juego. A ver si alguien puede explicárselo a alguien con casi nulos conocimientos informáticos como yo.

Actualmente hay cosas muy bestias desde hacks completos con todos los niveles sustituidos y más de las 120 estrellas originales, hacks con power-ups totalmente nuevos o basados en otros juegos de Mario (montar en Yoshi, Flor de Fuego, Mario abeja, Mario muelle...), nuevos enemigos, objetos, sonidos y banda sonora, hacks donde se rompen los límites del tamaño de los escenarios, hacks para poner el juego a más resolución (640x480), hacks para forzar 60 fps... Incluso Conker64 mencionó hace un tiempo que se podían modificar los microcódigos.
Si se trata de correr de forma nativa el juego en otras plataformas existen emuladores homebrew en Gamecube, Wii y Xbox que corren el juego a la perfección. No sé si hay algo para PS2 y DreamCast.
Eso sí, un comentario muy llamativo en el enlace que ha publicado radorn habla de hacer funcionar el juego en Playstation lo que sería un grandioso experimento.

No sé. ¿Creéis que la utilidad de esto centrándonos en lo que podría funcionar en el hardware real podría ser incorporar la función de vibración a la rom internacional, sustituir el microcódigo por uno más moderno y eficiente, forzar el filtrado trilineal a las texturas, aumentar la resolución a 320x240 e incluso incorporar panorámico y modos hi-res, desbloquear el framerate y usar triple-buffer, uso del expansión pak para aumentar el rendimiento, e incluso sustitución de los modelos de los personaje por los de la versión de Nintendo DS que tienen mejor acabado y utilizan menos polígonos?
Sería como tener una remasterización en la propia consola. ¿O se podría hacer todo esto con hacks convencionales (algunas cosas ya se han hecho) a pesar de que el código fuente facilitase las cosas?
@Sogun Está claro, como bien señalas, que la "scene" de Mario 64 ha alcanzado unas cotas realmente asombrosas.
Si bien, a mi me sigue molestando que la mayoría de hacks solo funcionen en emulador.
Tambien es cierto que se ha avanzado mucho en la introduccion de codigo y funciones nuevas mediante inyeccion de assembly/ensamblador y creo que incluso hay herramientas para inyectar pequeños (o no tan pequeños) trozos de codigo C y modificar el motor del juego de forma bastante profunda. Pero la potencialidad practica de este tipo de modificaciones a base de hacks sobre codigo ya compilado no se puede comparar a tener el codigo fuente.

Si quieres una idea de qué se podría hacer con el codigo de Mario 64, puedes ver el Zelda. Cuando se acabo el desarrollo de Mario 64, EAD lo usó como base para Zelda 64, y fue modificandolo hasta obtener el producto final que conocemos como Ocarina of Time.

El hecho es que han logrado, por lo visto gracias a que el codigo de mario 64 no está "optimizado", de-compilar la ROM y obtener codigo fuente funcional en C que resulta en la ROM original cuando se compila con el SDK original, y las posibilidades que eso abre son potencialmente enormes.

Hay varias preguntas clave para entender qué ventajas qué posibilidades abre este hecho y las respuestas no son necesariamente claras.
¿Ofrecerá esto información importante sobre técnicas de programación en la N64?
¿Abrirá la puerta a hacks/mods mas avanzados del Mario 64 original?
¿Se podrá portar a otras plataformas?
¿Cuán util es el motor del juego para nuevos desarrollos?
¿Se puede derivar un "middleware" tipo Unitiy o Unreal Engine a partir de el?
No hay respuestas claras. Todo dependerá de cuanto interes y talento se invierta en el tema. El tiempo lo dirá.

De lo que no hay duda es que es un paso muy importante y con un potencial muy grande.
Mira todo lo que se ha hecho con el codigo de los diversos Doom. Hay tropecientos motores derivados, con diversas capacidades y corriendo en hardware de lo mas diverso. Dudo que Mario 64 alcance tales cotas, pero quien sabe.

EDITO: Si te fijas, aunque en mario 64 ciertamente han introducido mucha funcionalidad que atnes no existia, en muchos aspectos es material reciclado. Los añadidos de una forma u otra tienen que engancharse a codigo pre-existente, y las modificaciones, aunque las hay muy refinadas y efectistas, están muy atadas a las capacidades especificas del codigo original, y hacer algo realmente NUEVO es muy dificil, y solo unos pocos pueden realmente incluir algo 100% nuevo, que no sea reciclaje y que realmente se integre en el ecosistema del jeugo sin dar el cante.

Con acceso al codigo fuente, se abren todo tipo de posibilidades.
DF Retro ha publicado un nuevo vídeo esta vez dedicado al primer Turok y centra su análisis principalmente en la versión de Nintendo 64.



Este juego nunca me llamó la atención he incluso en mi grupo de amigos había bastante mofa con el exceso de niebla y que necesitase guardar partida en la tarjeta de memoria. También porque era un juego con un precio altísimo.

Cuando lo jugué ya había completado GoldenEye así que me pareció obsoleto y se acrecentó la sensación de que era un mal juego y que sólo tuvo repercusión porque fue de lo primero en salir. Aún así había varios detalles técnicos que me gustaron como la representación del cielo y el agua, la textura de las montañas y los efectos de luces. No avancé mucho en el juego porque me lo prestaron unos días junto al F-Zero X y prefería gastar mi tiempo en el juego de velocidad (del que tampoco me llevé una buena sensación en ese momento, aunque más adelante le di otra oportunidad y ahí sí me enamoró).

En el vídeo mencionan la forma en que se crean y generan los escenarios y la verdad es que me viene muy bien este ejemplo ahora que estoy experimentando con los mapas del Soul Reaver que mencioné un poco más atrás. Ambos juegos utilizan un sistema de streaming que va cargando y descargando zonas del mapa según el jugador se acerca a ellas y se puede recorrer todo el escenario, que es gigantesco, sin cargas ni transiciones.

Siempre creí que el Turok tenía el desarrollo típico de fases como por ejemplo Doom, pero parece que está diseñado más como Metroid Prime y el juego se divide en sectores a los que se puede volver en cualquier momento e incluso es necesario hacerlo para avanzar en el juego. ¿Alguien que lo haya jugado me lo podría confirmar? ¿Se puede viajar a pie de un sector a otro o es necesario el uso de portales?

Otra cosa muy curiosa que se ve en el vídeo es que los escenarios están construidos por medio de objetos prefabricados que se van acoplando entre sí. Esto permite optimizar el uso de la memoria y supongo que también facilitar el proceso del streaming. Lo malo es que resta variedad en los escenarios.

Muy sorprendido con el primer Turok. Es un juego que voy a tener en cuenta para mis investigaciones.
@Sogun Me gustaría que hubiera algun modo de tener avisos solo del contenido "DF Retro" de Digital Foundry, porque todo lo de las nuevas graficas y tal me da bastante igual, la verdad, salvo algunas curiosidades que tienen de vez en cuando.

En fin, como yo me compré la N64 de estreno y alquilé mucho, aun no teniendo casi ningun otro amigo que la tuviese, siendo casi todos sonyers, jugué al Turok desde el principio siendo, si no recuerdo mal, uno de los titulos de estreno, o saliendo poco despues, en Europa.

Al principio, debido a la dificultad de los controles y otros factores, me dediqué a jugar al juego con trucos (recuerdo de memoria el "big cheat" NTHGTHDGDCRTDRTK, que, por lo visto, es la version sin vocales de "oN THe eiGHT Day, GoD CReaTeD TuRoK"... bastante blasfemo, pero en fin), reventando de todo. Aún no había GoldenEye ninguno, y los gráficos eran alucinantes, y molaba bastante.

Mas recientemente me decidí a jugarme el juego, no recuerdo sin en "NORMAL" o "HARD" y me lo acabé sin truco ninguno.

La música de aquella no me gustaba, pero recientemente le he pillado mas gusto, especialmente a la version CD audio del port a PC. No me gustan todas las pistas, pero hay dos o tres que si me parecen muy buenas y no simplemente sonidos tetricos y ritmicos.
Curiosamente la version CD audio de PC de Turok 2 me parece que suena peor que la version de N64, como que menos pulida y con un toque de MIDI cutre.

Sogun escribió:En el vídeo mencionan la forma en que se crean y generan los escenarios y la verdad es que me viene muy bien este ejemplo ahora que estoy experimentando con los mapas del Soul Reaver que mencioné un poco más atrás. Ambos juegos utilizan un sistema de streaming que va cargando y descargando zonas del mapa según el jugador se acerca a ellas y se puede recorrer todo el escenario, que es gigantesco, sin cargas ni transiciones.

En ShootersForever, hace años, un usuario recien registrado entonces abrió un hilo muy técnico sobre Turok1 hablaba del formato de los niveles y tal. Creo que era el autor de la recreación de Doom64 a PC y que mas tarde hizo los ports de Turok 1 y 2 tambien. Igual te interesa buscarlo. En el post hay imagenes inconfundibles de los mapas en modo rejilla mostrando cómo encajan las piezas o algo así.
... http://www.shootersforever.com/forums_m ... php?t=5544 lo encontré, pero los enlaces de las imagenes están rotos ya..

Sogun escribió:Siempre creí que el Turok tenía el desarrollo típico de fases como por ejemplo Doom, pero parece que está diseñado más como Metroid Prime y el juego se divide en sectores a los que se puede volver en cualquier momento e incluso es necesario hacerlo para avanzar en el juego. ¿Alguien que lo haya jugado me lo podría confirmar? ¿Se puede viajar a pie de un sector a otro o es necesario el uso de portales?

Pues, habiendomelo acabado, puedo responderte.
Los niveles son abiertos, pero tienen un avance bastante lineal. No es exactamente un recorrido tunel, y, algunos niveles incluso son bastante laberinticos (las catacumbas puede ser un autentico infierno), y puedes necesitar volver sobre tus pasos muchas veces. Pero, buena parte del entorno si que consiste en zonas conectadas entre si por las que has de pasar una a una, pero tambien hay variaciones. Realmente cada nivel es diferente.
Tambien hay muchos portales, entre zonas. Son niveles grandes con numerosos puntos de guardado y un estilo de avance variable.

El objetivo del juego es reunir las 8 piezas del "Chronoscepter", el arma definitiva y cargarse al malo maísimo "The Campaigner". Técnicamente te lo puedes cargar sin el, pero problablemente no sea recomendable intentarlo a no ser que quieras jugar a lo TAS.
Cuando empiezas el juego te tiran en medio de la primera fase y tienes que avanzar hasta llegar a las "Hub Ruins", una especie de stonehenge con alta tecnología antigua consistente en unos portales que te llevan a los otros 7 niveles del "lost world" del universo Turok (originario de unos comics).
De todos los niveles se puede regresar al hub, excepto del ultimo, al que entras saltando en una especie de pozo y ya no hay vuelta atrás.

Para abrir esos portales necesitas ir recogiendo llaves por los demás niveles.

En la primera fase puedes recoger las llaves necesarias para el nivel 2 y 3, y luego hay algun nivel que tiene sus correspondientes llaves repartidas por mas de un nivel. En este sentido el avance no es lineal.
Sin embargo, una vez entras en un nivel, te lo tienes que recorrer de principio a fin. Hay un portal de entrada y otro de salida, y ambos conectan con el mismo portal del nivel correspondiente en el "hub". Como es esperable, si entras desde el hub, te mandan al principio del nivel, y no al final. Así que no es recomendable dejarse cosas antes de salir.

La mayoría de enemigos que te cargas se quedan muertos para siempre, sin que yo haya visto ningun mecanismo por el cual se regeneren. Pero tambien hay lugares donde siguen apareciendo enemigos que se materializan desde otra dimension, pues, de acuerdo con el universo Turok, estos viajes espacio-temporales e interdimensionales tienden a suceder de forma espontánea... y claro, como es natural, todo todo bicho que se transporta a donde estás va armado y te odia xDDDD

Dentro de un mismo nivel, el desplazamiento es libre, a pesar de que los niveles tienden a estar estructurados de una forma bastante lineal, y, generalmente, puedes ir a donde quieras, aunque a veces tambien hay puntos que una vez los atraviesas, ya no puedes volver atrás, o te obligan a seguir adelante para mas tarde encontrar una ruta de regreso alternativa.

En medio de los niveles tambien lugares donde "aleatoriamente" aparecen portales que te mandan a fases bonus con items, y que tambien pueden contener obstaculos dañinos y enemigos armados.

A mi es un juego que me gusta mucho, pero tambien es cierto que tiene muchos puntos, tanto en los graficos (especialmente lo repetitivo de su aspecto) y tambien en jugabilidad.
El control, con posicionamiento absoluto del eje vertical del stick analogico para apuntar es muy criticado por la mayoría, pero yo me logré hacer con ello y no me parece tan malo, ni mucho menos. Ciertamente el modo de control 1.2 de GoldenEye, que se le parece mucho en lo esencial, es mejor, pues el eje vertical controla la velocidad del movimiento angular y no la posicion absoluta.

Una cosa que si que no me gusta del Turok es que la deteccion de impactos suele estar basada en una geometría muy simplificada, y muchas veces te encuentras intentando disparar por encima de algun objeto o desde una esquina, y la bala choca contra el aire porque la geometria de colision no coincide con la visual. A veces puede ser muy molesto.

Algunos entornos de Turok 1 me gustan mucho, aunque la densa niebla frecuentemente impida apreciarlos como es debido. Las recreaciones para PC de hace unos años mejoran mucho este aspecto, pero tambien hacen algunos cambios "creativos" sobre el juego con los que no todo el mundo está de acuerdo.

En general, aunque Turok 2 es claramente superior en cuanto a refinamiento técnico, a mi me gusta mas el 1, e incluso los niveles mas repetitivos visualmente son mas soportables y agradables que los de Turok 2, que son excesivamente claustrofóbicos y deprimentes (la colmena de los tecnoinsectos es insufrible, y la nave del útimo nivel no es mucho mejor, ni tampoco se queda corta la cueva de los ciegos... en fin que el diseño de niveles de ese juego es muy mejorable)

Bueno, despues de otra de mis parrafadas, toca ver el video.
@Sogun Turok tuvo muchas cosas adelantadas a su tiempo, cualquiera que lo jugara en su momento (salida de N64 en europa) lo flipó:

-Las animaciones de los enemigos eran muy avanzadas para lo que estábamos acostumbrados
-Las flechas se quedaban clavadas donde habían impactado :O
-los impactos en los enemigos se veían reflejados en sus muestras de dolor
-sangre a borbotones
-armas flipantes y bien animadas (y en 3D)
-IA bastante superior a lo que habíamos visto hasta ese momento
-explosiones inimaginables hasta el momento,
-mejor agua vista en ninguna consola (detrás de Wave Race, claro)
-¿primer shoother con todo en 3D?
-sin tiempos de carga
-el lens flare

Se le criticó demasiado por ser un juego de N64, si hubiera salido en PS1 hubiera sido la hostia.
@cegador Varias de las cosas que mencionas no son del Turok 1 si no del Turok 2

En Turok 1...
...las flechas desaparecían en cuanto impactaban en algo, ya fuera enemigos o escenario.
...no había reacciones por impactos en los enemigos. Salpica la sangre, pero seguian andando sin inmutarse hasta que les dabas el tiro de gracia.
...había mucha sangre para la época, si, pero no tanta, ni tan avanzada como la de T2, ni hacía charco en el suelo.

El resto podría aplicarse a T1 sin problemas, pero me pregunto si lo que tienes en mente al decirlo no es realmente el T2...

Lo del agua si que encaja en T1, porque la tiene con superficie poligonal animada, mientras que en T2 es una superficie plana... con una textura animada bastante buena, pero plana.

Lo de ser el primer shooter todo en 3D, desde luego no puede decir de T2, pero tampoco del T1, porque Quake salió un año antes en PC. Esto además lo atestigua el hecho de que el propio Turok 1 tiene un "truco" llamado "Quack mode" que rebaja una serie de características tecnicas del juego para producir un aspecto similar al del Quake. Es un truco/modo humorístico.
Recuerdo que las revistas de la época presentaron este truco como un supuesto "modo PlayStation", o algo así. Imagino que sería la Nintendo Acción, a modo de propaganda anti-Sony: "¿Ves estos graficazos que tiene este juego? ¡Pues si lo sacaran en la MierdaStation se vería así!" ay, que tiempos mas tontos... xDDDDDDDD
Aunque, al menos, por entonces si había diferencias graficas de verdad en las consolas, no como ahora, que se pasan el día contando pixels, shaders, frames...
@radorn Ahora me dejas con la duda en varios aspectos... a ver si estoy mezclando juegos. Oooh

A ver si puedo jugar estos días... juraría que las flechas se quedaban clavadas en los enemigos en Turok 1 y respecto a las zonas de impacto... igual tienes razón: ¿igual es simplemente que la animación de muerte variaba dependiendo de dónde le habías dado?
cegador escribió:¿igual es simplemente que la animación de muerte variaba dependiendo de dónde le habías dado?

Yo después de acabarme el juego en tiempos relativamente recientes, y de haberlo jugado con insistencia en su día, nunca pude identificar una variación en las animaciones de muerte por disparar en uno o en otro lado al enemigo.
Si que hay variaciones dependiendo del arma usada, eso deguro. Con explosivos los puedes mandar por el aire, y con el cuchillo o flechas no explosivas, muchas veces los ves desangrarse agonicamente, aunque creo que eso tambien puede pasar con balas... La verdad es que tendría que ponerme a hacer experimentos sistematicamente para buscar algun patrón mas o menos fiable que indicase varición por dar en la cabeza o en un brazo o en una pierna, etc... A mi en Turok 1 siempre me dió la impresión de que dieras donde dieras al enemigo le hacías el mismo daño. Tal enemigo, tantas balas, des donde des.
En Turok 2 si que hay variación del daño recibido, y muertes de un tiro por dar en la mollera, y muertes diferentes de acuerdo con la parte del cuerpo donde impactes, pero en Turok 1... despues de jugarlo tanto como lo he jugado, estoy bastante seguro de que no. No pondría la mano en el fuego, porque cabe la posibilidad de que algo se me escape, pero lo veo dificil.
Pues me ha sorprendido el código de SM64, esperaba más bien cosas así:

void func_8027A7C4(void)
{
    s32 i;

    if (gCurrentArea != NULL)
    {
        func_8037C360(gCurrentArea->unk04, 2);
        gCurrentArea = NULL;
        gWarpTransition.isActive = 0;
    }

    for (i = 0; i < 8; i++)
    {
        if (gAreaData[i].unk04 != NULL)
        {
            func_8037C360(gAreaData[i].unk04, 4);
            gAreaData[i].unk04 = NULL;
        }
    }
}


Con más funciones identificadas en hexadecimal, variables por tipo y registro, etc y muy poco código "humano", pero está bien estructurado, con bastante material por nombre y con comentarios (los comentarios se pierden al compilar, solo están en el código original)

Al igual que el código del mortal kombat, usa la libultra y es difícil trasladar ese código sin tener que llevarte también parte de la (prohibida) libultra para no perder funcionalidad o portar sus funciones en caso de querer hacer un port nativo en otra plataforma, yo creo que necesita días, semanas de estudio..

La scene volcada en juegos comerciales es excelente, pero el desarrollo libre o de herramientas interesa mucho menos en el caso de N64, lamentablemente se va a seguir destripando juegos y haciendo cosas maravillosas, mientras que en la scene nadie se interesará por documentar las coordenadas internas del RDP para mostrar un simple cubo texturizado con corrección de perspectiva en un SDK libre.

--
El vídeo de Turok de DF genial, el análisis de framerate bastante flojo, pasa de un segmento donde no aparece nadie a una escena disparando el lanzamisiles a saco, ya se sabe de los problemas de fillrate al poner transparencia y Z-buffer en polígonos grandes.

Me falta recorrido de acción normal en distintos niveles, con lo que ha analizado te haces una falsa idea de como rinde el juego.

(A mi me gusta más el Turok 1 que el 2, sobretodo por el diseño de niveles)
Hablando de Turok y el código fuente de Mario 64. ¿No se consiguió precisamente el código fuente de Turok hace unos años?
Me suena que se liquidó material de Iguana y alguien compró material informático y encontró el código fuente. He encontrado estas cosas:
https://www.retroreversing.com/turok64sourcecode
https://archive.org/details/turok-source.7z

A ver si esta noche publico un nuevo mensaje o edito este con algunas imágenes de algunos mapas del Soul Reaver portados a GoldenEye.
@Sogun Si, hace años se liquidó Acclaim y todos o casi todos sus estudios, incluido Iguana, y para pagar las deudas, se subastaron sus bienes.

Entre los que compraron está el dueño de ASSEMbler games, que publicó algunos de los materiales de los discos duros y se hizo un torrent hace años, donde principalmente había material promocional, y no encontré nada referente a Turok ni eXtreme-G ni nada que realmente me interesase personalmente. Tambien publicaron el motor multiplataforma Quagmire (si, como el personaje de Family Guy), que usaron para juegos de PS1, N64 y DC, aunque no se si alguien ha hecho algo con el. Y luego quedaron las copias de seguridad en cinta magnética, para lo que organizaron un esfuerzo colectivo entre miembros de confianza del foro, para conseguir las pletinas y hardware y software necesario para ir volcando todo el contenido.
https://assemblergames.com/forums/acclaim-project.91/
De acuerdo con las fechas de inicio de los hilos en esa seccion de AG, esto fue en 2010
No se si todo esto llegó a dar su fruto, porque entre medias el foro murió y luego fue resucitado y ahora vuelve a morir... y esa sección del foro parece muerta desde hace años. No se si aún hay algo descargable ahí... supongo que merece la pena rebuscar.

EDITO: https://archive.org/download/acclaim_discs

Paralelamente a esto, otro pujador distinto compró todas o casi todas las estaciones silicon graphics, por lo menos, las Indy, y no se supo de ellas hasta que, años mas tarde, en 2017, ese comprador vendió las Indy a este tio que las muestra apiladas con satisfacción y comenta que está empezando a fisgar en el contenido: https://www.youtube.com/watch?v=z3AW2dDXx1I

Una semana después, publica este video donde anuncia que tiene el codigo fuente de Turok:
https://www.youtube.com/watch?v=ONEy_ybKWsg
El mismo que sale en el enlace de retroreversing que pones.

La verdad es que yo ya me había olvidado del tema.
Un problema que va a tener ese codigo fuente es que dependen de la librería precompilada, libultra, que es el corazon del SDK de Nintendo/SGI.

Hablando de lo cual... @Conker64 ese codigo fuente de Mario 64, depende de un libultra binario o tambien lo decompilaron? Supongo que no...

AÑADO: He encontrado un git que parece ser el de los responsables de la decompilación de sm64. El repositorio correspondiente está vacío, supongo que debido al mencionado asunto de que el renombrado de funciones está inacabado en la versión filtrada. El caso es que parece que tambien tienen una decompilación de libultra! https://github.com/n64decomp/libreultra

Sogun escribió:A ver si esta noche publico un nuevo mensaje o edito este con algunas imágenes de algunos mapas del Soul Reaver portados a GoldenEye.

El post anterior donde mencionabas Soul Reaver, la verdad es que lo leí por encima y pensé que simplemente estabas viendo el juego y las técnicas y no vi la parte donde decías que querías portar cosas a GE.
@radorn

Pues no tenía intención de convertir los mapas de Soul Reaver pero como encontré la forma de hacer pruebas rápidas al final me puse a ello. Aunque una prueba en condiciones requeriría mucho trabajo y tiempo.

Me parecía que la carga poligonal del Soul Reaver era demasiado para una Nintendo 64 pero luego he visto que el juego no tiene una distancia de dibujo muy alta y realmente no se ven taaaantos polígonos en pantalla. He conseguido juntar alguna partes del mapa y funcionan bastante bien salvo el último ejemplo.

Hay que matizar que no son conversiones 1:1. He reducido las texturas a 1/4 de las originales y combinado paletas para poder convertir los mapas en cuestión de minutos. Es decir, he reducido las imágenes de 256x256 que contienen 16 texturas de 16 colores en el juego de Playstation a imágenes de 64x64 a 16 colores (en realidad 15) para adaptarlas a los 4 KB de la caché sin calentarme la cabeza. Para hacerlo bien tendría que partir cada imagen en 16 trozos y retexturizar los escenarios polígono a polígono. Teniendo en cuenta de que los escenarios tienen miles de polígonos y cientos de texturas me llevaría varios días o semanas.
Y seguramente por ese motivo el juego va relativamente suave cuando muestra tantos polígonos en pantalla y no existen problemas de memoria porque estoy usando unas 6 texturas por trozo (25 kB) en lugar de 100 texturas (400 kB). Tendría que ver si con la versión de PC es más fácil hacer estas conversiones. También he perdido el coloreado de vértices en el proceso y se nota una burrada.

Imágenes en secreto:
Ésta es la zona inicial del juego. Son 2925 polígonos y 103 texturas.
ImagenImagen


Aquí una zona de cañones que ya mostré anteriormente.
Este trozo inicial tiene 1305 polígonos y 30 texturas.
Imagen

Después el cañón se abre y se ve la entrada de un templo. Ese trozo son 3372 polígonos y 83 texturas. En la imagen se puede apreciar la mezcla de las paletas de colores porque en el primer trozo sólo hay tonos marrones y en el segundo hay tonos marrones y verdes y por eso el suelo se ve diferente aunque en realidad es la misma textura con la misma paleta (lo mismo con las paredes de las montañas)
Imagen

Una imagen más cercana del templo. Hay que tener en cuenta que mientras el personaje se encuentra en esta zona también están cargadas en memoria las adyacentes. Desde este exterior del templo hay otras 3 salidas además del cañón que hemos dejado atrás (aunque desde luego no tan complejas ni poligonalmente ni a nivel de texturas). Contando que las texturas del trozo del cañón se repiten en el templo en este momento perfectamente hay +100 texturas cargadas en memoria y posiblemente más de 5000 polígonos.
Imagen


Pero la zona más bestia que he encontrado (me falta mucho por mirar aún) es la zona de las cascadas que se ve en la intro del juego. 7444 polígonos y 65 texturas, muchas de ellas con scroll.
Por algún motivo no he sido capaz de cargarla entera en el engine del GoldenEye. En el pasado probé a mostrar 10000 polígonos en pantalla con una misma textura y lo conseguí. He tenido que partir el escenario en dos trozos y jugar con la distancia de dibujo para cargar primero un trozo y después cargar el segundo y tenerlos cargados los dos a la vez. Igual es algo que ocurre en la versión más nueva del Editor que es la que estoy usando ahora y en las anteriores sí que podría hacerlo funcionar.
Imagen

Imagen

Imagen

De momento voy a parar aquí y seguiré haciendo pruebas cuando finalice otros proyectos. Me gustaría ver cuánto mapa puedo juntar aunque sea a costa de usar estas versiones de texturas reducidas. Tendría que hacerlo para GoldenEye ya que permite cargar trozos del escenario desde el cartucho (Perfect Dark carga primero todo el nivel en la RAM y seguro que me quedo corto a pesar de los 8MB) y sobretodo porque permite aplicar una escala a los escenarios y Perfect Dark no (no tendría espacio físico para meter todo el mapa).
Podría emplear un parche que hay para GoldenEye y aprovechar los 8MB del Expansion Pak si me quedo corto de memoria. Incluso podría conseguir hacer funcionar el juego a 440x330 de resolución y así poder hacer una comparación más justa con los 512x240 del juego de Playstation.
A ver si con la versión de PC puedo solucionar algunos problemas que estoy teniendo para extraer algunas salas y también averiguo la manera de conservar el coloreado de vértices.
Yo podría ayudarte, a cortar las texturas y texturizar si me pasa los escenarios y texturas, y los primeros se pueden abrir con blender.

Salud.
Respecto al Turok, lo tuve en la época pero después de un par de años del lanzamiento, así que hypeado no estaba. Debo decir que personalmente me parece el mejor FPS junto al DIOS Goldeneye, El tipo de jugabilidad mas exploratoria estaba muy lograda, y la animación de los personajes junto a la música le sumaba muchos puntos.
@strider_hiryu Yo recuerdo que lo alquilamos para jugar en casa de un colega cuando salió y lo flipamos, el sonido, la sangre, las animaciones, las armas...

Por ponerle un pero, las partes de saltos plataformeros (en mi opinión) eran (y siguen siendo ahora) muy frustrantes: en la primera pantalla había ya una zona de saltos que si fallabas te caías a un lago y era un coñazo tener que volver a subir... en mi opinión la curva de aprendizaje estaba mal, el primer salto que te ponían ya era muy chungo, como jugador no estabas acostumbrado al plataformeo en primera persona, no veías dónde tenías los pies, no estabas acostumbrado al control del mando... si hasta en Ocarina pusieron el salto automático (y era en tercera persona con lo cual hubieras podido calcular mucho mejor las distancias).

PD: ¿Se podría hacer una comparativa entre el TRex de Turok de N64 vs el TRex de PSX?
Imagen

Imagen


@cegador Hombre, ya te comparo yo: El tiranosaurio de PS1 está mucho mas detallado y refinado, pero existe en un vacío sin nada mas, y la consola no está cargada con ningun otro proceso como inteligencia artificial, control del entorno (colision entre objetos y el escenario), y tantas otras cosas... Mientras que el de Turok forma parte de un juego interactivo, con montones de cosas sucediendo, escenario, efectos visuales como fuego, laseres, ondas expansivas, tus disparos, humo, ...
@radorn
Así es, necesitas compilar libultra y cualquier librería necesaria antes de compilar el proyecto.

@Sogun
Muy chulos esos mapas [360º]

@cegador
En cuanto a polígonos no sé si llegué a poner el T-Rex de la demo de PSX aquí, pero tengo la captura:
Imagen

Del Turok faltaría por extraer la escena 3D, limpiarla y dejar solo el dinosaurio, no veo que esté en las webs que suelo mirar a mano.

Luego no son comparables claro, en el Turok carga con todo el engine detrás.

@jordigahan
Perdona, no vi el mensaje, el Evangelion 64 apenas lo he tocado, te refieres a extraer escenas, ver texturas,etc?

Creo que lo único que saqué son wireframes, no sé si llegué a ponerlos aquí.
me referia a un analis como has hecho con otros juegos, hablar de todo un poco.
sobre dinosaurios, podeis aprovechar la comparativa y meter tambien el de la scena del tomb raider 1, en la version de saturn, para que haya una consola de cada.
Conker64 escribió:...


@Conker, quería primero que todo agradecerte por la cantidad de información con la que has "pintado" estas páginas y comentarte que me he leído con mucha detención y entusiasmo cada dato que has publicado sobre la nintendo 64 ysus juegos. Fue tanto lo que con tus explicaciones lograste comunicar que me convenciste de hacerme con una :P (no joke)

Ya instalado y habiéndome familiarizado con el control y unos pocos juegos que sólo vi en revistas en sus años, me ha hecho ilusión de trastear más dada la dificultad de alcanzar ciertos títulos y por otra parte también ver que ofrecía el homebrew para esta consola, me he animado a hacerme con un flashcart también.

Entonces motivado con esto último he querido tratar de poner en marcha el n64 toolchain, y específicamente he estado tratando de levantarlo en windows 10 sin éxito, probé siguiendo este tutorial pero después de un par de horas compilándose el gcc me arroja múltiples errores que no logro sortear por mucho que lo he intentado:S

Sin animo de molestar ni aburrir a nadie, intento solicitar de tu conocimiento y si es posible, que me pudieras comentar brevemente si debiese seguir alguna indicación complementaria (algún otro tutorial de referencia) o derechamente probar a hacerlo de forma directa utilizando alguna distro de linux?

Gracias por tu atención y tiempo de antemano!
@rigoyagami https://vandal.elespanol.com/foro/mensa ... n64/48#711 es tambien suyo por si preguntas
Luego tienes que actualizarlo llendo hacia el github de conker
Flash-Original escribió:@rigoyagami https://vandal.elespanol.com/foro/mensa ... n64/48#711 es tambien suyo por si preguntas
Luego tienes que actualizarlo llendo hacia el github de conker


Oooh, muy buen antecedente!

Y mira que el comienza afirmando:
"Primero mencionar que no he dado con ni un solo tutorial que explique bien los pasos, siempre pasa algo que no deja compilar el entorno."

Voy a intentar porque probé otro tutorial y nuevamente finalizó con error luego de más de una hora :S

Gracias, espero me vaya bien.
@rigoyagami A las malas te paso mi cigwin
Flash-Original escribió:@rigoyagami A las malas te paso mi cigwin


Diría que me interesa porque después de 2 horas igual finalicé con error :(
@rigoyagami
Hola [360º] , qué errores te arroja el entorno?

La verdad es que no he probado a compilar todo de nuevo en los últimos GCC ni tampoco en Win 10, luego no se si bajaste los archivos por tu cuenta o solo los del tutorial que hice, siguiendo todos los pasos.

Si te falla en la compilación larga de varias horas imagino que lo que falla es la compilación de mips64-elf o similar y no la de libdragon que son varios segundos.

Como comenta Flash se puede pasar el entorno ya compilado de cygwin con libdragon, de hecho otras librerías como la libn64 se distribuyen solo así, con los binarios del entorno, pero en su estado actual es solo para expertos.

@jordigahan
Ah ok, el Evangelion 64 no sé si podría jugarlo para hacerle un análisis completo, pero igual se podría sacar algo.

El dinosaurio a ver si un día me entretengo y saco almenos el de N64, el T-Rex del Tomb Raider igual sería más fácil sacarlo de PSX.
@Conker64
Gracias por la pronta respuesta!, veras, este fue el error con el que finalizo la compilación:

In file included from ./tm.h:38:0,
from ../../gcc-5.1.0/gcc/cp/except.c:27:
../../gcc-5.1.0/gcc/defaults.h:126:24: aviso: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \
^
In file included from ../../gcc-5.1.0/gcc/cp/except.c:1023:0:
cfns.gperf: En la función ‘const char* libc_name_p(const char*, unsigned int)’:
cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’ se redeclaró incluida en línea con el atributo ‘gnu_inline’
cfns.gperf:26:14: nota: ‘const char* libc_name_p(const char*, unsigned int)’ previously declared here
cfns.gperf: En el ámbito global:
cfns.gperf:26:14: aviso: inline function ‘const char* libc_name_p(const char*, unsigned int)’ used but never defined
make[2]: *** [Makefile:1058: cp/except.o] Error 1
make[2]: se sale del directorio '/usr/local/libdragon/temp/gcc_compile/gcc'
make[1]: *** [Makefile:4116: all-gcc] Error 2
make[1]: se sale del directorio '/usr/local/libdragon/temp/gcc_compile'
make: *** [Makefile:872: all] Error 2


Instale al pie de la letra lo que aparece en el tutorial, pero ademas instale automake, autoconf, libtools y mercurial, tengo intenciones de trastear con alt64 (el menú alternativo). El tema es que a pesar del error pude compilar el ejemplo de la imagen de conker en png :O

Para alt64, pude instalar libmikmod (y libmikmod-n64), libyaml, pero se me resiste libmad-n64 :s al ejecutar el comando make reclama por ciertos parámetros asociados a aclocal.m4:

cd . && /bin/sh /usr/local/libdragon/temp/libmad-n64/missing --run aclocal-1.8
aclocal: macro `_LT_COMPILER_PIC' required but not defined
aclocal: macro `_LT_DECL_SED' required but not defined
aclocal: macro `_LT_DECL_SED' required but not defined
aclocal: macro `_LT_FUNC_STRIPNAME_CNF' required but not defined
make: *** [Makefile:285: aclocal.m4] Error 1



Has tenido suerte configurando el entorno para compilar alt64?
@rigoyagami Pues te voy a desilusionar pero parece que se casco xD
Pruebo e inicia bien pero me sale errores de subprocesos (lo instale con win 7 y ahora esta con win 10) y me da error de cmopatiblidad con Windows
Vamos que me tocara instalar otra vez (me tire en su momento 48 horas) imaginate ahora para tener que hacerlo otra vez

Si has podido instarlo apuntante los comandos
por ejemplo:
export N64_INST=/usr/local
make
make install
make toolsOriginFlash (aqui el nombre)
make tools-install

Conker64 escribió:@rigoyagami
Hola [360º] , qué errores te arroja el entorno?

La verdad es que no he probado a compilar todo de nuevo en los últimos GCC ni tampoco en Win 10, luego no se si bajaste los archivos por tu cuenta o solo los del tutorial que hice, siguiendo todos los pasos.

Si te falla en la compilación larga de varias horas imagino que lo que falla es la compilación de mips64-elf o similar y no la de libdragon que son varios segundos.

Como comenta Flash se puede pasar el entorno ya compilado de cygwin con libdragon, de hecho otras librerías como la libn64 se distribuyen solo así, con los binarios del entorno, pero en su estado actual es solo para expertos.

@jordigahan
Ah ok, el Evangelion 64 no sé si podría jugarlo para hacerle un análisis completo, pero igual se podría sacar algo.

El dinosaurio a ver si un día me entretengo y saco almenos el de N64, el T-Rex del Tomb Raider igual sería más fácil sacarlo de PSX.


Aunque sea inmiscuirme,¿como va eso? o sea hace años que no se del lbin64 que te pasaste porque estaba a bajo nivel(hex) mientras que libdragon en C
Flash-Original escribió:@rigoyagami Pues te voy a desilusionar pero parece que se casco xD...



Hey!, gracias!!

Pues siendo franco pareciera que mi entorno medio que funciona (al menos pude crear los ejecutables para todos los proyectos de la carpeta examples), igual como describía en el post anterior el terminal del cygwin tardó alrededor de 2 horas y media hasta que apareció el error comentado sin embargo al compilar libdragon no dio errores y algunas herramientas como libmikmod-n64 y libyaml se instalaron sin ningún problema.

Como antecedente instalé sobre Windows 10 (64 bits) utilizando la recopilación de Conker64 (la descarga que figura en su tutorial), respecto a las herramientas que seleccioné en el instalador recuerdo:
autoconf
automake
mercurial
gcc-core
gcc-g++
texinfo
wget
git
libtool
binutils
libmad-devel
libpng
texinfo
tar
zlib-devel



edit: creo que he sorteado el problema para compilar alt64:
$ make
/usr/local/bin/mips64-elf-ld -o menu.elf menu.o everdrive.o fat.o disk.o mem.o sys.o ini.o strlib.o utils.o sram.o stb_image.o chksum64.o mp3.o -O1 -L/usr/local/lib -L/usr/local/mips64-elf/lib -ldragon -lmikmod -lmad -lyaml -lc -lm -ldragonsys -lnosys -Tn64ld.x
/usr/local/bin/mkdfs test.dfs ./filesystem/
Adding './filesystem/bamboo.wav' to filesystem image.
Adding './filesystem/done.wav' to filesystem image.
Adding './filesystem/ed64_mono.wav' to filesystem image.
Adding './filesystem/n64controller.sprite' to filesystem image.
Adding './filesystem/sprites/background.sprite' to filesystem image.
Adding './filesystem/sprites/splash.sprite' to filesystem image.
Adding './filesystem/warning.wav' to filesystem image.
/usr/local/bin/mips64-elf-objcopy menu.elf menu.bin -O binary
rm -f OS64.v64
/usr/local/bin/n64tool -l 4M -t "EverDrive OS" -h ./header.ed64 -o OS64.v64 menu.bin -s 1M test.dfs
/usr/local/bin/chksum64 OS64.v64
CHKSUM64 V1.2 Copyright (C) 1997 Andreas Sterbenz (stan@sbox.tu-graz.ac.at)
This program is released under the terms of the GNU public license. NO WARRANTY

The image 'OS64.v64' is in original (not swapped) format.
Old Checksum: F4 07 6E 75 4C DA D3 A6
Calculated Checksum: 8A 6C 68 DA 8C 04 F4 38
New checksum successfully written.


según el github del autor para generar el instalador libmad-n64 se tenían que utilizar los siguientes parámetros:

CFLAGS="-march=vr4300 -mtune=vr4300 -mno-extern-sdata" \
LDFLAGS="-L$(N64_INST)/lib" LIBS="-lc -lnosys" \
./configure --host=mips64-elf --disable-shared \
--prefix=$(N64_INST) --enable-speed --enable-fpm=mips


Hice un pequeño cambio en los parámetros (adición de --build y sustracción de --disable-shared) y quedó así:
CFLAGS="-march=vr4300 -mtune=vr4300 -mno-extern-sdata" \
LDFLAGS="-L$(N64_INST)/lib" LIBS="-lc -lnosys" \
./configure --host=mips64-elf --build=i686-pc-cygwin \
--prefix=$(N64_INST) --enable-speed --enable-fpm=mips


Ese cambio me permitió instalar libmad-n64 y en consecuencia compilar alt64.
@Flash-Original
Pues no hay nada nuevo creo, yo estuve dándole parte de la funcionalidad del RDP que había hecho en libdragon hasta que me quede atascado, hay mucho código en ASM que no es fácil de seguir o accesos a registros de la maquina que no están del todo documentados.

Para que la librería llegue a buen puerto la comunidad necesita volcarse más.

@rigoyagami
Genial veo que ya te vas apañando con las librerías [360º]

La alt64 no he intentado compilarla aún, estuve pensando en hacer un menú con caratulas para reemplazar el del Everdrive, eso sí.
Conker64 escribió: @rigoyagami
Genial veo que ya te vas apañando con las librerías [360º]

La alt64 no he intentado compilarla aún, estuve pensando en hacer un menú con caratulas para reemplazar el del Everdrive, eso sí.


Pensabas en hacer un menú desde 0 o complementar el alt64?

Yo por mi parte tengo un ED64P y según leí en los foros oficiales de krikzz, saturnu (el autor de alt64) indicó hace algunos años que dejó un "resguardo" a nivel de código encargado de que cuando se utilizará su menú con un ED64P te corrompiera los saves.

Navegando por gbatemp hace un par de semanas, el usuario kuwange preguntó por una validación particular apuntando a un segmento del código fuente de alt64, y el mismo saturnu confirmó el cómo diseñó la validación que causa el "conocido problema" y además afirma que eliminándo esta validación el menú alt64 quedaría 100% operativo en el ED64P (aunque la versión de código fuente en github no es la versión más actual que el desarrolló)

Acá les dejo información detallada respecto a lo que comento:

2017 saturnu, señalando que el menú tiene "trampa" si es utilizado con ED64P
http://krikzz.com/forum/index.php?topic ... 5#msg50935

2019 saturnu, reafirmando el sistema de "boicoteo"
https://gbatemp.net/threads/ed64-plus-m ... st-8670110

kuwange consultando si sus hallazgos en el código fuente y validando si tienen relación con lo comentado originalmente por saturnu
https://gbatemp.net/threads/ed64-plus-m ... st-8670142

saturnu confirma los hallazgos de kuwange y reafirmando que suprimiendo la validación, la funcionalidad para saves queda restituida completamente
https://gbatemp.net/threads/ed64-plus-m ... st-8670663
3563 respuestas
Responder
1…35, 36, 37, 38, 39…72
Volver a Consolas clásicas