Hilo de detalles y curiosidades de N64

@rigoyagami
Mi idea era hacer una interfaz acelerada por hardware, con caratulas y otras cosillas como transparencias, zooms al seleccionar, lista de favoritos, etc

Sobretodo hacer menos tedioso el uso del CPAK, como un sistema de carga automático de SD a CPAK si estableces esa opción (para juegos que se comen entera la memoria), poder acceder a la lista de juegos que hay guardada en el CPAK y hacer respaldos individuales, borrar, editar el contenido, en lugar de volcar el CPAK entero, etc

Y para las funciones depende, supongo que utilizar o ver el código disponible de otros menus, la alt64 usa libdragon, no sabía que tuviera código para identificar el clon del Everdrive y fastidiarlo

Conker64 escribió:@rigoyagami
Mi idea era hacer una interfaz acelerada por hardware, con caratulas y otras cosillas como transparencias, zooms al seleccionar, lista de favoritos, etc

Sobretodo hacer menos tedioso el uso del CPAK, como un sistema de carga automático de SD a CPAK si estableces esa opción (para juegos que se comen entera la memoria), poder acceder a la lista de juegos que hay guardada en el CPAK y hacer respaldos individuales, borrar, editar el contenido, en lugar de volcar el CPAK entero, etc

Y para las funciones depende, supongo que utilizar o ver el código disponible de otros menus, la alt64 usa libdragon, no sabía que tuviera código para identificar el clon del Everdrive y fastidiarlo

Suena muy prometedor! (ojalá te animes a hacerlo realidad), yo por mi parte tenía la intención primeramente de compilar el fuente de alt64 eliminando la validación que estropea los saves en flashcarts ED64P y validarlo de forma directa en mi propia consola.

El ejecutable que compilé de momento no me ha dado ningún fallo al grabar aunque he leído que el problema es detectable con el título smash brothers 64.

@Conker64
(apropósito el ejecutable terminó en 4MB, sabes si hay algún comando en la compilación que me permita generar un ejecutable de menor tamaño?)

Lo que he detectado de momento, es que no todas las conversiones de aleck64 arrancan :S. De estas adaptaciones para mi sólo funcionaron con alt64 que compile y ejecuté en ED64P los siguientes:
Eleven Beat
Kuru Kuru Fever
Vivid Dolls
Star Soldier Vanishing Earth Arcade

Los que sólo me dieron pantalla negra:
Tower & Shaft
Super Real Mahjong VS
Mayjinsen 3
Magical Tetris Challenge
Hi Pai Paradise
Donchan Puzzle Hanabi de Doon!


En consideración que altra64, fork de alt64 afirma tener 100% compatibilidad con 64dd y aleck64. Mi intención es poner los fuentes de alt64 y el altra64 codo a codo a fin de generar una versión paralela de alt64 con las "mejoras" agregadas por networkfusion en altra64 pero sin la validación que estropea los saves en cartuchos ED64P (más considerando que soy propietario de uno de estos clones)

Pero debo reconocer que no sé que tan factible resulte mi objetivo, porque con el entorno de desarrollo y las herramientas para n64 que logré montar gracias a ti, no logro compilar el altra64, reporté el error a networkfusion y el indica tener intenciones de corregirlo "pronto".

rigoyagami escribió:@Conker64
(apropósito el ejecutable terminó en 4MB, sabes si hay algún comando en la compilación que me permita generar un ejecutable de menor tamaño?)
.

Hola, puedo mirarlo, a mi me los generaba de 2MB, pero puede ser variable, depende del sistema de archivos que monte.

El Tic Tac Toe solo ocupa 4KB, normalmente los ejemplos escritos en ASM ocupan poco.

Del Altra64 no te se decir, pero si alt64 te compila y el Altra64 solo corrige algunas cosas lo que puedes hacer es cambiar solo los archivos .c, .h que hayan sido modificados de una versión a la otra y ver si compila, porque puede que existan errores en los makefile, etc

@Conker64
Perdona, si alguien más me puede ayudar, con este programa...
https://www.romhacking.net/hacks/4606/
Cambia correctamente a 60 haz, el problema es que ahora en lylat wars 64 en la n64 se recorta casi hasta la mitad de lo retratos cuando hablan.
Habría alguna forma de solucionarlo con una everdrive?

@Conker64
Finalmente había omitido que en el make está la instrucción "4M":


Cambiando eso por "2M" ya genera el OS64.V64 a 2 megabytes

Estaba comparando con notepad++ la diferencia de archivos entre alt64 y altra64 y es bastante:


Creo que será buen curro tratar de incorporar lo que haya agregado el altra64 a la funcionalidad

Viendo que compartisteis VHS
yo me vi cientos de veces y no es aleatorio el VHS de majora mask me encantaba la cancion del final
https://youtu.be/Ru-UFzkahf0?t=301

@blade133bo Trataré de echarle un vistazo a lo del Lylat recortado a 60, pero, despues de leer por encima las instrucciones, parece que usaron PALadin (una vieja aplicación de la scene original de N64) para hacer las conversiones, así que no se yo si el problema tendrá facil solución sin que un experto le haga un hackeo manual.

@Flash-Original ese tema es ligeramente off-topic en este hilo, y mas indicado para el general, así que respondo en oculto:

@blade133bo Justamente lo vi hace un par dias

Da muchos problemas en según que juegos, mala tasa de refresco, rayas negras,etc.Aunque varia segun cual uses
Quizas saldria mejor pasar la traduccion de uno a otro y ya(si se pueden mirar archivos)
Al menos no es un parche a 60fps
https://www.youtube.com/watch?v=7FaOqn8ypJ4 (1:10)
El engine se apoya mucho en lo de la gravedad(no me sale) eso incluso hoy en dia se ve en algunos juegos si se cambia

@radorn Gracias por pasarlo, es solo que por alguna razón me gusto esa musica solamente, ya que desconozco este genero musical (Yo soy raro y no escucho nada de musica)

@Flash-Original
Para pasar la traduccion tal cual, a la americana le hace falta espacio para 10000 caracteres.
Perdón, 5000 caracteres, que el texto está en 16 bits.
Una pena que no haga la conversión correctamente.
Saludos.

joerr esto es un hilazo....

me suscribo

El Flashcart "ED64 Plus" se ha dejado de ensamblar o producir?

Dante_Sparta16 escribió:El Flashcart "ED64 Plus" se ha dejado de ensamblar o producir?

Ni idea si siguen haciendo, pero en aliexpress todavía quedan.

cegador escribió:@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
-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.

Opino lo mismo. En Game 40 dijeron que estaba en desarrollo una versión para PSX pero esta jamás salió a la luz. ¿Alguien sabe si eso era cierto? Es que no imagino el efecto de agua en esa consola.

Expansion_Pack escribió:Opino lo mismo. En Game 40 dijeron que estaba en desarrollo una versión para PSX pero esta jamás salió a la luz. ¿Alguien sabe si eso era cierto? Es que no imagino el efecto de agua en esa consola.

Pues no se si en algun momento pensaron en hacer un turok en PS1, pero, después de ver como funciona el motor del juego, dudo mucho que fuese a ser un port. Yo nunca oí nada de que fuera a haber un turok en ps1, pero, asumiendo que tuvieran pensado hacerlo, yo creo que tendría que ser un juego muy diferente.
No es solo el tema de los efectos graficos, si no la forma en que los niveles esán construidos por piezas reutilizables. El motor del juego está fuertemente adaptado a la velocidad del cartucho, cargando dichas piezas por streaming en tiempo real. Creo que en PS1 hubiera tenido que ser un fps mucho mas tradicional, sin poder ofrecer los niveles enormes que tiene en N64.

radorn escribió:

Expansion_Pack escribió:Opino lo mismo. En Game 40 dijeron que estaba en desarrollo una versión para PSX pero esta jamás salió a la luz. ¿Alguien sabe si eso era cierto? Es que no imagino el efecto de agua en esa consola.

Pues no se si en algun momento pensaron en hacer un turok en PS1, pero, después de ver como funciona el motor del juego, dudo mucho que fuese a ser un port. Yo nunca oí nada de que fuera a haber un turok en ps1, pero, asumiendo que tuvieran pensado hacerlo, yo creo que tendría que ser un juego muy diferente.
No es solo el tema de los efectos graficos, si no la forma en que los niveles esán construidos por piezas reutilizables. El motor del juego está fuertemente adaptado a la velocidad del cartucho, cargando dichas piezas por streaming en tiempo real. Creo que en PS1 hubiera tenido que ser un fps mucho mas tradicional, sin poder ofrecer los niveles enormes que tiene en N64.

Ya ves, el cartucho fue muy criticado por el precio y limitaciones de almacenamiento, pero tenía cosas muy potentes que ofrecer.

@Expansion_Pack
Si hubiera habido un port, no creo que hubiera sido muy diferente al de n64,
Siendo realistas, la diferencia entre n64 y Psx es los polígonos reguetoneros de psx y el almacenamiento de la n64, obviamente quedarían unos ports más que decentes, hablo en ambos sentidos.
Por si tengo que dejarlo claro, la n64 no la cambiaba ni por una PS3, que consolon que tuve.

blade133bo escribió:@Expansion_Pack
Si hubiera habido un port, no creo que hubiera sido muy diferente al de n64,
Siendo realistas, la diferencia entre n64 y Psx es los polígonos reguetoneros de psx y el almacenamiento de la n64, obviamente quedarían unos ports más que decentes, hablo en ambos sentidos.
Por si tengo que dejarlo claro, la n64 no la cambiaba ni por una PS3, que consolon que tuve.

Opino como tú, ese baile poligonal era algo característico, así como en N64 las texturas de baja calidad y bajo poligonaje. Pero si hablamos de Turok, habría perdido mucho encanto con el reguetoneo como tú dices y la pixelación excesiva.

blade133bo escribió:@Flash-Original
Para pasar la traduccion tal cual, a la americana le hace falta espacio para 10000 caracteres.
Perdón, 5000 caracteres, que el texto está en 16 bits.
Una pena que no haga la conversión correctamente.
Saludos.

Con Retrotink podría funcionar vi en las características del convertidor que puede visualizar correctamente la señal europea a 60 hz con salida progresiva, me gustaría para jugar perfect dark en español y a color y por supuesto la traducción de Lylat, los resultados del convertidor se acercan al ultra hdmi siempre y cuando convierta la señal del cable s-video claro.

También me sorprende que no hayan mencionado aquí del nuevo convertidor de EON super 64 del que me da curiosidad saber si puede sacar correctamente la señal europea de los juegos de n64 en las consolas ntsc , la ventaja que le veo al convertidor es que no requiere de una fuente de alimentación externa aunque con el costo que tiene probablemente opte por Retrotink.

Y una noticia reciente es que el hack de Super Mario 64 star road ya es funcional en el hardware real gracias a Kaze Emuanar

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

john D9 escribió:Y una noticia reciente es que el hack de Super Mario 64 star road ya es funcional en el hardware real gracias a Kaze Emuanar

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

Notición! Gracias.
En el video tambien comenta sobre una utilidad para compatibilizar antiguos hacks con la consola. Habrá que investigarlo.

john D9 escribió:También me sorprende que no hayan mencionado aquí del nuevo convertidor de EON super 64 del que me da curiosidad saber si puede sacar correctamente la señal europea de los juegos de n64 en las consolas ntsc

Creo que sí se comentó en el hilo general de n64. Respecto a si acepta video a 50Hz (probablemente 49.xHz por las diferencias del pixel clock) en consola NTSC, no tengo ni idea.
Lo único que se es que los fabricantes dicen que tienen que hace una version PAL del aparato, aunque no sé si eso es indicativo de las características de la versión NTSC.
En el hilo general tambien comenté algo sobre un fallo que se apreciaba claramente en el análisis de MJR, aunque en otros análisis parece que no aparece, así que igual lo han solucionado. Si bien, parece haber otros problemas, como la calidad material: chips con gota de epoxy, soldaduras de mala calidad o incluso ausentes...
Es cara y parece tener bastantes problemas. Espero que no tarden en solucionarlos, por su bien.

Algunos trucos ya se han tratado en el hilo, pero otros no:

cegador escribió:Algunos trucos ya se han tratado en el hilo, pero otros no:

Buenas curiosidades del vídeo algunas explicadas en este hilo por Conker64, aunque el titulo es algo engañoso , creo que todos sabíamos que eso no es 3d desde hace mucho tiempo atras xD así son los primeros resident evil con mucho 2d,

Pero en fin otra noticia interesante es el nuevo mod de ocarina of time llamado Dawn & Dusk de luigiblood, que incluso funciona en disco magnetico mejor que nimpize adventure y compatible para flash cart también , realmente vale la pena se los recomiendo.

No estoy tan al día con N64 desde que jugué el fullset hace dos años, podéis decirme si han aparecido en este tiempo algún otro juego cancelado o prototipo? El último que vi fue el de Die Hard 64.

¡Hostia! ¿Qué el Ocarina of Time tiene a Hitler oculto entre los NPC y nadie se ha dado cuenta?!

john D9 escribió:Pero en fin otra noticia interesante es el nuevo mod de ocarina of time llamado Dawn & Dusk de luigiblood, que incluso funciona en disco magnetico mejor que nimpize adventure y compatible para flash cart también , realmente vale la pena se los recomiendo.

Gracias por el aviso!
Para el que le interese, ha sacado una v2.0 corrigiendo algún fallo:

https://twitter.com/LuigiBlood/status/1 ... 3549634560

Vosotros como veis esto:
Hyperkin Nintendo 64 HDMI Link Cable: https://www.amazon.com/Hyperkin-Hdtv-Ca ... B07SCPHHVB

Al final no uso la 64 para la vomitiva salida y los dientes de sierra, tengo algunos pendientes y me gustaria volver a cogerlo

He visto algunos videos y parece que quita el baile de las texturas

@Flash-Original Aquí una comparativa de métodos para conectar N64 a televisores actuales:



Parece que el cable ese de hyperkin oscurece la imagen y los colores se muestran apagados ¡pero por 30$ no se le puede pedir más! Lo máximo seria el UltraHDMI pero se va a casi 300€.

¿a qué te refieres con "baile de texturas"? N64 no tenía ese problema, las que tenían "baile de texturas" eran PS1 y Saturn...

Flash-Original escribió:Vosotros como veis esto:
Hyperkin Nintendo 64 HDMI Link Cable: https://www.amazon.com/Hyperkin-Hdtv-Ca ... B07SCPHHVB

Al final no uso la 64 para la vomitiva salida y los dientes de sierra, tengo algunos pendientes y me gustaria volver a cogerlo

He visto algunos videos y parece que quita el baile de las texturas

La salida de vídeo de N64 es vomitiva, pero la consola no tiene baile de texturas ni tampoco dientes de sierra, esos son los fallos de una PSX. En N64 los fallos van por otro lado, no tienes dientes de sierra; pero todo está emborronado por el filtro gráfico de suavizado, si quieres ver dientes de sierra en un juego de N64 prueba el primer Quake, es el único juego del catálogo que permite desactivar en opciones ese filtro y así puedes ver dientes vs emborronado. En cuanto a las texturas aquí no bailan y son solidas, el problema es que suelen ser de baja calidad o resolución, además de que muchos juegos por el poco tamaño del cartucho no podían tener una gran variedad de las mismas haciendo entornos más monótonos. Ambas consolas tienen excepciones o al menos juegos que limitan mucho sus carencias.

quise decir las 2d como los corazones del ocarina of time

Flash-Original escribió:quise decir las 2d como los corazones del ocarina of time

Vas a tener que especificar un poco más cual es el problema que le ves al Zelda porque precisamente los dos juegos al completo y en especial sus elementos 2D estan optimizados para las teles CRT y se ven de lujo. Desgraciadamente eso mismo provoca que al conectar la consola a una HDTV se vea horrible.

El cable parece que hace algún tipo de upscale y elimina un poco el efecto pixel. Es una mejora ya que el fabricante usa la salida de S-video y la convierte a HDMI, lamentablemente no soporta RGB que sería lo suyo, así que solo merece la pena para N64 y Gamecube NTSC. Para el resto de consolas, euroconector con RGB.

Imágenes del prototipo del mando de N64:

https://twitter.com/shanebattye/status/ ... 7030618112

@cegador tiene buena pinta aunque si vendiera los sticks sueltos yo tengo dos pads muertos que resucitaría encantado. Y ya sé que se venden sticks sueltos, pero los baratos hay que soldar porque no traen el plastico de enchufar y los caros, pues son muy caros

Edit: Vale, entendí que era un prototipo de mando nuevo para N64, no el original de 1995. Pues el stick me tiene mucha mejor pinta que el que finalmente salió la verdad.

El stick del prototipo funciona igual que el mando final. Por otras fotos se ve que tiene el mismo sistema de engranages.


Lo que si que parece que al ser más pequeño, es menos preciso que los que salieron al final.

@EMaDeLoC en realidad yo lo decía por el agarre de la cabeza, me tiene pinta de resbalar menos y sobre todo cansar menos el pulgar en partidas largas.

SuperPadLand escribió:@EMaDeLoC en realidad yo lo decía por el agarre de la cabeza, me tiene pinta de resbalar menos y sobre todo cansar menos el pulgar en partidas largas.

Yo creo que al ser liso resbalaría más.

Modern Vintage Gamer dedica un vídeo al UltraHLE.



La parte técnica, sin entrar en profundidad, empieza en 6:30. Explica la diferencia entre LLE y HLE y el cómo fue posible que ordenadores "relativamente poco potentes" pudieran emular un puñado de juegos de N64. Las comillas son porque hablamos de ordenadores cuyo procesador es 2 o 3 veces más rápido que el R4300, tarjetas gráficas 4 veces más potentes que el RCP y sin el cuello de botella de la RAM de la consola.

La existencia del UltraHLE no solo marca una revolución en los emuladores al innovar con cierto éxito en el uso de HLE, también resulta una prueba de la relación entre el personal que trabajó en SGi y se fue a 3Dfx y en como definieron el estandar de trabajo de los procesadores gráficos 3D y en especial en el lenguaje o API para comunicarse con dichos procesadores. Esto convierte al RCP en el padre, o como mínimo un antepasado, de las aceleradoras gráficas modernas de PC tanto en la forma de trabajar por hardware como por software.

Por otra parte el hecho de que intercepte de forma tan efectiva las llamadas a las librerías básicas del SDK de la Nintendo 64 sugiere que los creadores del UltraHLE eran programadores con experiencia en las aceleradoras gráficas y/o estaban relacionados con desarrolladoras de la consola y tenian a mano las herramientas del SDK.
De hecho es posible que el UltraHLE fuese originalmente una herramienta para poder desarrollar a bajo coste los juegos de la consola.

En la parte negativa estan los haters de la consola que para demostrar su analfabetismo computacional usan el emulador como prueba de, en terminos técnicos, "lo mierda que era la consola", ignorando el logro técnico del emulador y la vinculación entre los creadores del RCP y las Voodoo.

¿Vosotros qué opinais o sabeis respecto al UltraHLE?

Si mal no recuerdo el SDK de N64 se filtró por esa época y entonces empezaron a florecer todo tipo de emuladores, con eso ya tenías el código fuente de lo que hace exactamente cada función de la libultra.

Seguí de cerca la emulación durante unos cuantos años, yo tenía una lamentable S3 Trio 2x y luego pasé a una Geforce 2, así que poco pude probar el UltraHLE hasta que lo modificaron para funcionar en DX o OGL, no recuerdo, tampoco es que fueran muchos juegos.

El resto de emuladores iba a pedales en un PIII 500Mhz, aunque podías encontrar versiones o configuraciones en juegos concretos para que fueran más o menos bien, creo que el que se llevaba la palma era un "emulador" que todo lo que hacía era cargar la rom en la ram, solo eso

PD:
- El hack del Zelda muy bueno, funciona bien en consola
- Creo que no se han filtrado más betas importantes desde el Die Hard
- Ya han descifrado como texturizar con corrección de perspectiva totalmente acelerado sin usar la libultra:
https://github.com/pseudophpt/pseultra

No recuerdo cuando fue exactamente que tuve por primera vez PC en casa, pero creo que fue en 2001 (nací en el 85, pero hasta entonces tuve que esperar, si...), y luego cuando tardé en tener internet, por modem 56k.
Estaba buscando cosas de videojuegos y finalmente acabé topandome con los emuladores, lo cual no tardó mucho en llevarme a los de N64. Obviamente el estreno me lo perdí, y no se si para cuando encontré el UltraHLE ya estaba o no el Project64. Recuerdo que había tambien otro que se llamaba Corn y un par mas.
Tenía una tarjeta con chip Rage128 de ATi y una CPU AMD Athlon a 800MHz, y recuerdo que la emulación de N64 nunca fué demasiado bien en mi PC, aunque me jugué el Conker entero en alguna versión de PJ64, ya en 2002 o 2003, no sin bastantes errores gráficos, claro. A la que si jugué mucho en emulación fue a la SNES, consola que nunca llegué a tocar en su día, y bastante a la MegaDrive también.

El primer juego que intenté emular con el UltraHLE fue Lylat Wars, juego que no tuve mas que en alquiler, y recuerdo la enorme decepción de ver que, si, cargaba, pero se veía todo azul y super oscuro y jugar sin el analógico era un truño, etc. Un par de años después, descubrí Lik-Sang y compré un adaptador de mandos de PS1/2 y N64 a PC en grupo con otros 4 del instituto para aprovechar los descuentos por volumen que hacían, y por transferencia bancaria por falta de tarjeta, aunque creo que fuí el único que lo compró por N64, pues todos los otros lo hicieron por PS.

Pero en fin, esto ya fue todo con PJ64, pues UltraHLE nunca funcionó bien para mi, imagino que por mi tipo de GPU.
Recuerdo que de aquella hasta se recomendaban las ROMs V64 porque eran mas rapidas o noseque...

EMaDeLoC escribió:De hecho es posible que el UltraHLE fuese originalmente una herramienta para poder desarrollar a bajo coste los juegos de la consola.

Hmmm, teorías emadelocianas... me encantan a la brasa
Con unos resultados y compatibilidad tan limitados como tenía este emulador, creo que acabaría entorpeciendo mas que ayudando. Fíjate como hoy en día emuladores mucho mas avanzados han supuesto tal impedimento a que lo que se hace con emuladores como plataforma de testeo funcione en consola. ¿De qué sirve ahorrar usando una herramienta tan limitada si luego vas a tener que comprar igualmente el equipamiento oficial para meterte en las tripas de lo que ya has hecho, deshacer lo que está mal, y volver a hacerlo bien? Al final te sale todo mucho mas trabajoso y costoso que si hubieras ido por la via oficial desde el principio.

radorn escribió:

EMaDeLoC escribió:De hecho es posible que el UltraHLE fuese originalmente una herramienta para poder desarrollar a bajo coste los juegos de la consola.

Hmmm, teorías emadelocianas... me encantan a la brasa

radorn escribió:Con unos resultados y compatibilidad tan limitados como tenía este emulador, creo que acabaría entorpeciendo mas que ayudando. Fíjate como hoy en día emuladores mucho mas avanzados han supuesto tal impedimento a que lo que se hace con emuladores como plataforma de testeo funcione en consola. ¿De qué sirve ahorrar usando una herramienta tan limitada si luego vas a tener que comprar igualmente el equipamiento oficial para meterte en las tripas de lo que ya has hecho, deshacer lo que está mal, y volver a hacerlo bien? Al final te sale todo mucho mas trabajoso y costoso que si hubieras ido por la via oficial desde el principio.

Bueno, en mi mente no estaba pensando en el emulador tal cual se publicó ni en un sustitutivo del hardware completo, más bien en una especie de "máquina virtual" donde comprobar que las ROM cargan como deben y en especial, dado que el VR4300 esta emulado en LLE, el poder optimizar y chequear la correcta ejecución del código sin pasarse en la cantidad de cálculos, pero con una función gráfica más limitada o practicamente nula. El hardware oficial para el desarrollo de la N64 era caro en todas sus formas y algún estudio es posible que solo pudiera permitirse una estación de desarrollo SGi. El hecho de que el equipo tuviese que trabajar por turnos en esa estación ya supone un quebradero de cabeza importante. Sin embargo si quienes picaban código adelantaban trabajo de debug fuera de esa estación ya era un ahorro considerable.
Tampoco es descartable que el emulador fuese algo más completo graficamente con las funciones estandar de la libreria (pero igualmente muy limitado) para que los programadores de IA y otras funciones no relacionadas con los gráficos pudieran ir avanzando en PCs convencionales mientras el equipo del motor gráfico se dedicara a crear y probar microcódigos en la máquina real. Por ejemplo, para probar el algoritmo de colisiones no necesitas cargar texturas ni efectos, con ver los modelos 3D básicos te puede bastar. Y eso una versión muy recortada del UltraHLE podría hacerlo.
Es solo una teoría, pero dado el coste del hardware de desarrollo en esa época había mercado entre las desarrolladoras por alternativas baratas. Tal vez el UltraHLE fuese en principio una alternativa en software barata creada por un par de personas para venderlo a distintas desarrolladoras pero el proyecto se fue al traste y decidieran publicarlo.
O sea producto de un par de frikis con mucho tiempo libre.
Yo solo expongo mis teorias...

@EMaDeLoC Pues yo diría que es mucho mas probable que UltraHLE fuese mas bien un proyecto de geeks de alto nivel, programadores profesionales con estudios universitarios, aficionados a los videojuegos, con acceso a las herramientas de desarrollo y documentación filtradas a grupos de noticias, que las bajasen por curiosidad técnica y quizá interés en programar alguna cosilla para la consola, y que, estudiando el funcionamiento de la consola, se les encendió la bombilla al darse cuenta de la posibilidad de emular los microcodigos en vez del RCP directamente, naciendo así la idea de HLE que acabaron implementando.

Que luego el emulador encontrase añgún uso entre desarrolladores licenciados por Nintendo, de forma similar a como sucedió con el V64, es una posibilidad que no voy a negar, ni tampoco la posibilidad de que en tal empresa estuviesen implicados los propios autores, pero que empezase como herramienta de desarrollo es algo que me parece muy improbable.

No puede ser que este hilo caiga en el olvido

Jugar a dobles en pantalla partida al Mario 64 en consola original:

¿Y el frame rate no se resiente?

@cegador Lo vi hace poco, pero estaba con la cabeza en otra cosa y no vine a comentar.
¿No había también algo similar para el ZOoT?

Señor Ventura escribió:¿Y el frame rate no se resiente?

Recientemente he probado algunos hacks varios, y he notado algo respecto al rendimiento que probablemente también juegue un papel aquí.
Así como existen esos parcheos para ROMs para ganar nitidez quitando ciertos procesos del VI, el componente que lee el framebuffer para pasarlo al bus de video, y quitando la segunda capa de antialiasing de ese modo no ganas nada o casi nada de rendimiento, otros hacks que desactivan el antialiasing a nivel del RDP (el que renderiza), si que gana mucho rendimiento, por lo que he podido ver.
Probé brevemente un hack de Mario 64 en el que, en la version para consola, reducen un poco la resolución recortando los bordes de la pantalla y desactivan el antialiasing por completo.
También un hack de GoldenEye que pone los gráficos a 640x480 (salida entrelazada 480i, claro, pero el buffer tiene que ser progresivo, pues es imposible garantizar un frame parcial de un solo campo para cada refresco de pantalla, que son 60 por segundo xD). Con dos versiones, una con AA activado y otro desactivado. El desactivado no solo corre mucho mejor que el otro, si no que hasta me ha parecido algo mas rápido que el original, aunque no tengo con que comprobarlo. Creo que la técnica está ya integrada entre el arsenal para modders del juego.

Muy probablemente este hack de mario a pantalla partida desactivará el AA por completo, entre otras optimizaciones.

Como curiosidad añado que en el Diddy Kong Racing, sin modificar, ya los de Rare implementaron una optimización consistente en que, si te paras, se activa el anti-aliasing, pero si arrancas, a poco que alcances algo de velocidad, se desactiva para mejorar el rendimiento. Es algo en lo que no reparas mientras juegas. Yo me di cuenta ya de adulto, y de chiripa. He de fijarme si Jet Force Gemini y Mickey's Speedway USA también lo hacen, dado que son herederos del motor de DKR.

Recuerdo que con un Pentium 3 a 800mhz, 128mb de ram y una geforce 4 mx podia emular N64 en su totalidad con buen rendimiento.

@radorn se ve claramente que tiene peor rendimiento que el juego original. Lo dice el propio creador del vídeo. No es que el hack no merezca la pena por ello y no digo que no se puedan optimizar incluso más desactivando cosas, pero en el vídeo se nota bastante. Tampoco es una anomalía, entra dentro de la normalidad de los juegos a pantalla partida y en este caso tiene bastante mérito porque a diferencia de los de carreras o FPS de que está renderizando dos mundos abiertos en tercera persona con manejo de la cámara al mismo tiempo, algo bastante tocho para la época y que ahora mismo no caigo si hay algún juego que oficialmente ofreciera esto. Creo que ni en Dreamcast.

@SuperPadLand Bueno, yo no dije en ningún momento que el hack de pantalla partida de Mario 64 no afectase negativamente al rendimiento. Simplemente mencioné una probable optimizacion, quitar el AA, que podrían usar para aligerar la carga, y que lo he visto en un hack de GE a 640x480 con un excelente rendimiento, y que incluso un juego oficial recurre a ello.

@radorn sigue siendo una demostración de potencia.

En las mismas condiciones que un juego de playstation (sin aa, sin corrección de perspectiva, y sin z buffer), no sé si he llegado a leer que la burrearía en rendimiento, pero se ha hablado de tantas cifras que no se si 500k polígonos por segundo es una fantasmada (imagino también que a baja resolución).

Este hilo es una maravilla. ¡Menuda currada tiene!

Tal como predije, parece que alguien ya ha hecho un port inicial a LinuxPC del código decompilado de Mario 64 que salió hace no mucho.



Noticia donde lo ví: https://n64today.com/2019/09/18/super-mario-64-pc-port/
GirHub de código decompilado, con 260 forks xD https://github.com/n64decomp/sm64

Y nuevamente reitero mi incertidumbre acerca de a donde conducirá esto.

La mayor parte de la scene de Mario 64 está centrada en emuladores y no en la consola original tanto por razones técnicas históricas como por el hecho de que hay mas gente con emuladores que con hardware original cartuchos flash, además de que en emulador es mas facil hacer depuración y engancharle todo tipo de programas, mejoras de rendimiento gracias al HLE, todo ello rendundando en muchas mas posibilidades, flexibilidad y facilidad.
Para mucha gente sería mucho mas deseable tener un motor que corriese de forma nativa en plataformas modernas y hacer sus proyectos ahí. Los gurús que actualmente han hackeado hasta el infinito el motor original no se cómo se lo tomarán, pues sus hackeos actuales se basan en el codigo compilado de la ROM original, concretamente la versión NTSC. Con el nuevo motor de código abierto perdería el sentido dedicarse a hackear un binario concreto, que, además, varíaría entre plataformas, así que se orientaría todo mas hacia la programación con codigo fuente, recompilando para las distintas plataformas. Linux, macOS, Windows, consolas...

En cuanto a N64, sería bueno que se hiciese un port a librerías modernas y compilable con herrambientas actuales, lo cual podría mejorar el rendimiento sin necesidad de mucho mas, aunque luego también se podría mejorar el motor, tanto en rendimiento como en capacidades.

En fin, habrá que estar atento a cómo evoluciona el asunto.

@Sogun recuerdo que preguntabas qué relevancia tenía que saliese el código fuente, pues aquí lo tienes
@Conker64 ¿Estabas al tanto de esto? ¿Que opinion te merece?

@radorn de hecho creo que el hack no desactiva nada, de todas formas creo que comentó Conker en este hilo que desactivar el AA no mejoraba el rendimiento cuando le dije yo si esto sería posible aplicando los parches para las roms que ya existen.

@Señor Ventura en el modo Turbo3D Nintendo ya indicaba que la consola podía mover 500K. Como no hay ningún juego que lo haya usado a saber como se verían, seguramente a medio camino entre lo mejor de PSX y la M2, pero sin correción de perspectiva ni z-buffer ya que tiene pinta de que esas cifras las conseguía a costa de desactivar todo.

https://youtu.be/QeLGfeDHIYo
https://www.youtube.com/watch?v=ocaTno8iYVU

También habría que tener en cuenta que los juegos de la M2 usan CD, las limitaciones del cartucho en el tema de la variedad de texturas también afectarían al resultado final.

Tema aparte sería ver un motor de la scene en la actualidad con todo los avances que se conocen, el que están haciendo para Saturn muestra claramente mejoras que ni los ingenieros de la consola soñaron con ver en su máquina en los 90. https://sonicfangameshq.com/forums/show ... -demo.323/

Ahora mismo Saturn con ese proyecto podría tener un Quake II muy similar al de PSX, quizás algo peor porque dudo que pueda mover cuatro pantallas con la misma soltura; pero a saber. Estaría bien proyectos así para Jaguar, 3DO, PSX y N64. Sólo por ver cuanto más pueden dar con lo que sabemos hoy.

En N64 un proyecto así tendría que ser muy bruto, imagino que 300-400K con correción y el z-buffer optimizado sólo donde haga falta, etc.

El del zelda que han preguntado atras si hay un zelda multijugador pero solo funciona en emulador en cnosola no

En mario 64 yo probe el de varios marois que funciona tambien en wii

Con zelda ocarina poco a poco se hacen avances tambien alguien que este puesto a lo mejor ya lo sabra pero para los que no pongo una pequeña lista de lo que se puede

*Se pueden añadir enemigos propios o Assets en codigo C
*Puedes hacer que la IA vayan adonde tu digas
*Ya se pueden hacer cinematicas
*Mejora de soporte de texturas (RGBA)
*Desactivar el buffer para cuando toma la imagen al darle al start, este provocava que se quedara pillado
*Se puede importar un modelado nuevo para sustituir a link mas facilmente (antes en hex)

Como mencion interesante un español ha echo un generador de mazmorras de manera que siempre sea diferente ha modificado un poco la logica de los enemigos de manera que pueda invocar mas enemigos

@radorn
Hola, pues no sabía que ya tenían un port del SM64 corriendo en PC , aunque cuando vi el código fuente con comentarios para cada función pensé que era cuestión de tiempo.

--
El del Mario 64 a pantalla partida es bastante impresionante, me pregunto si tiene algún tipo de optimización o va a lo bestia.

Por ejemplo cuando cargas una textura puedes ver si se va a utilizar en las 2 cámaras antes de descargarla y como se usa el z-buffer da un poco igual el orden de pintado.

Por otro lado técnicamente pasamos 1 modelado que tenía cerca de 700 polígonos a 4, 2 Marios y 2 Luigis que se pueden ver a la vez, que si entran en la habitación del espejo van a ser 8 xD

No estaría mal saber si está usando el modelado actualizado, que se ve prácticamente igual pero usa muchos menos polígonos.

Dejo un gif de navidad