Hilo de detalles y curiosidades de N64

@Conker64 El gif es alguien que conoces o alguien cualquiera de internet?

@radorn Es de un tío random, un regalo de Navidad del año pasado.
Es como el mítico "Nintendo Sixty fooooour!!!", pero en grande.



Por cierto, me ha encantado esta parodia del Nintendo sixty-four...

Ahora que lo ha dicho Conker, tiene sentido que en esta época (creo) no haya juegos en tercera persona en escenarios abierto a pantalla partida o que Mario Kart 64 use sprites 2D para los corredores. Me gustaría ver el hack del Mario 64 como va en la sala de los espejos, cuando lo publique supongo que se podrá ver importando un save directamente.

Por cierto ha salido un nuevo hack para Majora's Mask: https://www.romhacking.net/hacks/3959/

Para Conker's ha salido traducción francesa 1.3. A nosotros no nos afecta, pero al parecer las mejoras de esta versión están sobre todo en que se han editado gráficos para ponerlos en francés, yo la verdad es que ya no recuerdo bien si había gráficos en inglés cuando lo jugué en español; pero de ser así supongo que la traducción francesa puede ser un avance para que más adelante salga una más completa al español. https://www.romhacking.net/translations/3457/

En hiddenpalace están lanzando nuevos prototipos cada día en estas fiestas , hoy 2 de N64:

Robotech: Crystal Dreams (Prototype)

GT 64: Championship Edition (May 25, 1998 prototype)

Interesante vídeo que muestra el mando de Ultra 64 y el devkit.

Para los entendidos una demo extraña con peces que dan casi miedo y ni idea de su finalidad:
https://www.youtube.com/watch?v=dDxAyK4c03U&app=desktop

A esto lo llaman juego, pero yo creo que es otra demo. buena música por cierto.
https://youtu.be/sgPQhG91Wrk

Como va el SDK, me gustaria probar un background que hice (si hay algun cambio) si no volver a descargar la libdragon

https://gitlab.com/kholdfuzion/goldeneye_src
Alguien está decompilando GoldenEye

radorn escribió:https://gitlab.com/kholdfuzion/goldeneye_src
Alguien está decompilando GoldenEye

Ejemplos práctico a nivel usuario de para que podría servir eso? xD

@SuperPadLand A nivel usuario nada, pero hace muy poco se decompiló Mario 64 y ya hay quien ha hecho un port preliminar a Linux.
También está el código fuente original de Turok, encontrado en una estación de trabajo Silicon Graphics proveniente de la subasta de bienes de Acclaim, aunque no estoy al tanto de que haya nadie trabajando con ello aún. Pero esas cosas nunca se saben hasta que salen de la cueva con algún resultado.

@radorn a lo que me refería era a que podíamos esperar los usuarios normales. Entiendo por lo que dices que por ejemplo podríamos ver un port corriendo nativamente en otras plataformas como Linux en 10-20 años (ojalá Wii con el Wiimote DD).

@SuperPadLand Pues, desde ports a otras plataformas, hasta reconstruir el motor en la propia N64 y hacerlo de código abierto, con modificaciones profundas, añadido de características, mejoras de rendimiento, resolución de bugs. Hay muchas posibilidades, todo depende de la imaginación, la habilidad, y el tiempo que se invierta.

Una cosa en la que suelo pensar es que sería bueno que se pudiesen adaptar juegos para correr sin ir a "cámara rápida" en consolas con overclock, cosa muy dificil en un juego de consolas clásicas y mediante ROMhacking debido a cómo estos motores se optimizan mucho para las frecuencias de reloj fijas del sistema original (hoy las consolas ya incluyen componentes con velocidades variables, y es una situación diferente).

Está el conocido overclock de la CPU mediante modificación del multiplicador del bus, pero tiende a hacer que los juegos vayan a cámara rapida también. Además, eso no cambia el reloj del RCP que es que renderiza. Otra cosa es si la RAM se puede overclockear o no y si se desetabilizaría o se quemaría.

Estas cosas se podrían hacer con el código fuente mas facilmente.

Dicho esto, no tengo ni idea de cuán avanzado está el proceso ni cuando podría estar terminado, y llegados a ese punto, cuando podría tardar en dar algún fruto.

@SuperPadLand También es posible que se puedan hacer otras versiones del juego como una segunda parte con niveles nuevos, o aprovechar el motor (que suele ser lo más difícil y tedioso de programar) para crear un juego distinto.
También sirve para meterse en la scene, ya que teniendo un ejemplo práctico y funcional de un juego comercial te puedes hacer mejor a la idea de como funciona la máquina a la hora de programar juegos.

@radorn La RAM no se puede overclokear sin overclokear el RCP, ya que es quien genera los pulsos de reloj y hacerlo desincronizaría el sistema y la memoria no se podría leer.
Hay quien ha overclokeado el RCP al margen del la CPU para evitar esa cámara rápida y obtener una mejora de rendimiento, pero el vídeo se desincroniza y hay que usar un FPGA programado adrede para sacar dicho vídeo.

@EMaDeLoC @radorn
Pues mira. Acabo de encontrarme con esto https://www.youtube.com/watch?v=5SxZglDHM6M
En la descripcion dice que es un mod hecho a partir del código decompilado, aunque sigue distribuyendose como parche para la ROM americana, claro. No se si corre en consola, pero lo comprobaré pronto (aunque probablemente no lo haga...)

EDITO: SI LO HACE, lo dice en el video. Eso pasa por no mirar las cosas hasta el final!

EMaDeLoC escribió:La RAM no se puede overclokear sin overclokear el RCP, ya que es quien genera los pulsos de reloj y hacerlo desincronizaría el sistema y la memoria no se podría leer.

Ya lo se, no me refería a que se overclockease la RAM por si misma sin el RCP. Despues de todo el controlador de memoria va en el RCP. Y no solo eso, por lo que yo tengo entendido, no es que el RCP le de el reloj a la RAM, si no que el multiplicador da la frecuencia del bus, los 250MHz, y de ahí deriva el RCP su reloj de 62.5Mhz (1/4).
Lo único que decía es que no se si la RAM aguantaría aumentar, no se, a 300MHz, por ejemplo, que daría 75Mhz al RCP. Tampoco se si el RCP tiene un multiplicador seleccionable como la CPU.

Dado que el bus de video se rige por otro reloj separado del de la RAM y el RCP, derivado esta vez de la portadora de color analógico, habría que entender el funcionamiento del VI para saber qué causa la desincronización.
Ahora recuerdo aquello que se trató con Conker64 en su anterior vida (xD) con lo de los parámetros del VI, y se me ocurre que probablemente el VI (y el AI) actue de sincronizador entre la frecuencia interna del RCP y la externa del bus AV, y algunos de los parámetros misteriosos tengan que ver con el modo de arbitrar entre esas dos frecuencias fuera de sincronía, especialmente para dar al software información sobre la sincronía de la pantalla.

radorn escribió:

EMaDeLoC escribió:La RAM no se puede overclokear sin overclokear el RCP, ya que es quien genera los pulsos de reloj y hacerlo desincronizaría el sistema y la memoria no se podría leer.

Ya lo se, no me refería a que se overclockease la RAM por si misma sin el RCP. Despues de todo el controlador de memoria va en el RCP. Y no solo eso, por lo que yo tengo entendido, no es que el RCP le de el reloj a la RAM, si no que el multiplicador da la frecuencia del bus, los 250MHz, y de ahí deriva el RCP su reloj de 62.5Mhz (1/4).
Lo único que decía es que no se si la RAM aguantaría aumentar, no se, a 300MHz, por ejemplo, que daría 75Mhz al RCP. Tampoco se si el RCP tiene un multiplicador seleccionable como la CPU.

Ah, vale. Pues un datasheet de NEC sobre RDRAM que se parece mucho al de la N64 dice que han de ser 250MHz máximo. Pero el del vídeo de antes ponía el RCP a 70Mhz, lo que significa que la RAM va a 280MHz. No sé si se podría subir a 300MHz, ya subirlo un 12% me parece mucho y seguramente será bastante inestable.

radorn escribió:Dado que el bus de video se rige por otro reloj separado del de la RAM y el RCP, derivado esta vez de la portadora de color analógico, habría que entender el funcionamiento del VI para saber qué causa la desincronización.
Ahora recuerdo aquello que se trató con Conker64 en su anterior vida (xD) con lo de los parámetros del VI, y se me ocurre que probablemente el VI (y el AI) actue de sincronizador entre la frecuencia interna del RCP y la externa del bus AV, y algunos de los parámetros misteriosos tengan que ver con el modo de arbitrar entre esas dos frecuencias fuera de sincronía, especialmente para dar al software información sobre la sincronía de la pantalla.

Pues yo estuve dándole vueltas a eso hace poco, en especial porqué ejecutar un juego de otra región te da o 61Hz o 49Hz. No he visto en ninguna parte que por código se establezca una frecuencia concreta, solo que el vídeo del RCP se pone en modo 50 o 60 Hz dependiendo de la región de la ROM.
Igual es tonteria lo que voy a decir, pero creo que el VI tiene hardcoded una determinada cantidad de pulsos y la diferencia de frecuencia entre algún elemento externo al RCP provoca el descuadre.

A ver si un día de estos hago algunas mediciones de las frecuencias de vídeo entre distintas consolas...

P.D.: recordad lo que tardé en poner la comparativa UltraHDMI vs. escaladores...

EMaDeLoC escribió:Pues yo estuve dándole vueltas a eso hace poco, en especial porqué ejecutar un juego de otra región te da o 61Hz o 49Hz. No he visto en ninguna parte que por código se establezca una frecuencia concreta, solo que el vídeo del RCP se pone en modo 50 o 60 Hz dependiendo de la región de la ROM.
Igual es tonteria lo que voy a decir, pero creo que el VI tiene hardcoded una determinada cantidad de pulsos y la diferencia de frecuencia entre algún elemento externo al RCP provoca el descuadre.

hilo_hilo-de-detalles-y-curiosidades-de-n64_2171497_s1500#p1746500058
El año pasado hablabamos de eso. Y con esos mismos datos yo he hecho calculos de por qué los juegos NTSC en consola PAL dan 61.2Hz y los PAL dan 49.1 en NTSC. Ni siquiera creo que NTSC en NTSC y PAL en PAL den 60 ni 50 exactos, porque el pixel clock no lo permite.

En tiempos recientes he repetido estas explicaciones varias veces por aquí. Cuando uno entiende que el pixel clock de la consola es fijo y los pulsos de sincronizacion H y V son enviados junto con uno de dichos pixels, queda claro que las sincronías de video tienen que casar con el pixel clock. Contando con la diferencia de los pixelclocks de cada región de la consola y teniendo en cuenta los valores que apuntan los juegos de cada región, se pueden predecir esos 61.2Hz y 49.1Hz. Como mínimo tenemos la confirmación de Conker64 de hace tiempo de que, efectivamente, los juegos NTSC en consola PAL corren a 61Hz, pues su monitor se lo chiva, aunque, obviamente, redondea los decimales.

Yo creo que la teoría es buena y las pocas pruebas disponibles la avalan.

@radorn Mmmm... ¿Entiendo que esos 61.2Hz y 49.1Hz son entonces cálculos teóricos y no mediciones reales?
Que no dudo de los cálculos, los he visto y son una pasada, pero no sé si alguien ha llegado a medirlos de verdad.

Quizá, puede, tal vez, cabe la posibilidad de que pueda hacer alguna medición real, más o menos precisa, del vsync y el hsync.

@EMaDeLoC Yo no tengo osciloscopio, ni me consta que nadie se haya molestado en medir este asunto en concreto. Pero, como ya te digo, con la información de Tim Worthington sobre el "protocolo" del bus de video, y contando con las diferencias conocidas del pixel clock entre regiones, las cuentas salen, y está la confirmación de los 61Hz intentando correr NTSC en consola PAL de Conker64.
Además de eso está la confirmación de marshallh, autor del UltraHDMI, de que tanto en NTSC como en PAL, el video activo por linea son 640px, y está el tema de la técnica de-blur, que ignora uno de cada dos pixels para eliminar el interpolado y dar pixels puros en juegos de 320px. Esto da la idea de cómo funciona el VI a la hora de poner pixels en el bus de video, especialmente si tenemos en cuenta de que puede hacerlo con juegos NTSC en consola PAL también, dando a entender que se limita a alinearse con el pixel clock fijo de la consola y por el pasan el mismo numero de pixels por linea que el juego mande independientemente de la velocidad exacta del bus.
Si la consola adaptase los tiempos, el deblur solo se podría hacer con juegos nativos a la región de la consola.

No cabe duda que sería bueno tener una medición real también, y estoy seguro de que confirmará la teoría, mas que echarla abajo.

Hay que precisar que, dado que desconozco la longitud de linea exacta que mandan los juegos (y, de acuerdo a la teoría, aunque es improbable, hasta podrían cambiar de un juego otro, dentro de los límites que una TV analógica aceptase, claro), lo que he hecho para esas aproximaciones de 61.2 y 49.1 ha sido asumir los 50Hz y 60Hz, dividir esto entre sus correspondientes pixel clocks nativos, y multiplicarlos por el opuesto. Es una aproximación con asunciones.
También está la duda de si, en modos LDTV (240/288), se repite siempre un mismo tipo de campo o se alterna.
En modo entrelazado NTSC suma 525 lineas y PAL 625, lo cual da cifras con media linea en división exacta, que es lo que provoca el efecto de entrelazado. Para hacer progresivo a media resolución, los campos tienen que tener un numero entero de lineas, así que o quitas la media que sobra o añades media mas para completar. Otra solución es desplazar la media de un campo al siguiente, manteniendo el mismo numero de lineas para dos campos que en modo entrelazado, aunque no se si esto lo aceptaría la TV con gracia, pues cambiaría en unos ~64microsegundos la duración de un frame/campo al siguiente en ambos formatos (en PAL 64 exactos, en NTSC algo menos).

En fin, hay muchas incógnitas. Así como en la NES, por ejemplo, tienen todas las sincronizaciones perfectamente tabuladas en un wiki, para N64, y asumo que bastantes otros sistemas, no.

Flash-Original escribió:Como va el SDK, me gustaria probar un background que hice (si hay algun cambio) si no volver a descargar la libdragon

Cual de ellas? libn64 está parada creo, su autor pasó a trabajar a una gran empresa.

Libdragon, la original tiene actualizaciones, no del autor original pero sí de alguien con permiso para tocar su Github, pero ninguna de ellas al RDP, hasta que no actualice por ahí creo que no será demasiado útil.

El fork que yo hice de la libdragon tuvo algunos cambios éste año, baja esa si quieres usar 2D porque es la única realmente acelerada.

Quizás lo ideal sería copiar rdp.c y rdp.h de mi lib a la última versión original, que entre otras cosas creo que metía modos 640x240p.

Yo ahora mismo estoy montando algo 3D, pero no para N64 sino en PC y Android.

¿Cual recomiendas tocar?

@Flash-Original
Baja la original y copia los archivos rdp.c y rdp.h de la mía, si te da problemas de compilación porque la nueva incorpora algo del RSP, entonces solo compila la mía.

La diferencia está en las funciones del RDP, la original tiene estas:


La que yo edité corrige problemas, es más rápida y accede a más cosas del hardware como CYCLE para transparencias o zooms, hay funciones borradas como texture flush que es un despilfarro que puede penalizar en un 20%, en otras cambian los parámetros, los slots de texturas no sirven en 2D, es mejor tener los 4KB enteros y ahorrar esas instrucciones, etc..

@Conker64 Sabes si hay alguna limitacion que no se haya llegado a cubrir como la 3d o el audio(si se ha resuelto ya)
ha pasado un año y ya no recuerdo mucho y buscando atras vi que algunas cosas no se han logrado poner en el sdk

Conker64 escribió:

Flash-Original escribió:Como va el SDK, me gustaria probar un background que hice (si hay algun cambio) si no volver a descargar la libdragon

Cual de ellas? libn64 está parada creo, su autor pasó a trabajar a una gran empresa.

Que pena que este parada esa librería,por lo que comentaste prometía bastante.

Salud.

@Flash-Original
Audio puedes reproducir, pero la falta de hilos hace que sea poco práctico.
3D solo por software, no hay nada completo para usarlo acelerado.

El clon del flappybird en N64 usa sonidos (solo fx, no música), tienes el código para echarle un vistazo:
https://github.com/meeq/FlappyBird-N64

@dirtymagic
El desarrollo de homebrew no interesa demasiado desafortunadamente

Conker64 escribió:@dirtymagic
El desarrollo de homebrew no interesa demasiado desafortunadamente

Con un poco de suerte, las fuentes de Mario, Turok, y en un futuro esperemos no muy lejano, GoldenEye, podrían abrir ese camino a mas gente y cambiar la situación, aumentando la masa crítica.

Dios ya ni recordaba lo desesperante que es con los errores para prepararlo todo de nuevo cuando termine lo subire en una ISO o algo porque si cada uno tiene que pasar por esto buff

Otra vez error 127 (faltan paquetes) y otra vez a hacerlo todo

radorn escribió:Con un poco de suerte, las fuentes de Mario, Turok, y en un futuro esperemos no muy lejano, GoldenEye, podrían abrir ese camino a mas gente y cambiar la situación, aumentando la masa crítica.

Sí, aunque el problema es que esos códigos comerciales no sirven ahora mismo, es decir para aprender están geniales, pero hace falta un SDK completo y accesible como el de la libultra.

Por ejemplo hay librerías 3D como la raylib (PC) que traen un instalador para windows y configuran mingw junto con notepad++ para compilar la librería en 1 solo click, con todas sus dependencias, ejemplos y demás.

En N64 está más orientado a que cojas el código, tengas una instalación de linux a poder ser y sigas unos pasos de instalación, eso ya asusta a bastante gente a querer probarla, sobretodo cuando los makefiles vienen hasta mal, para compilar la libdragon tuve que cambiar algunas rutas bastante obvias.

En realidad podrías bajar los binarios desde la web cen64, que evitan que tengas que montar todo el entorno de cero en el caso de la libn64, pero están incompletos y faltan includes necesarios hasta para hacer una función aleatoria, así que ya tendrías que estar trasteando para añadir lo que falte al entorno.

Luego es necesario un ejemplo 3D claro y funcional, un microcódigo light que se encargue de audio y 3D, hilos (ésto lo tiene la libn64), unas macros creadas para hacer algunas operaciones más sencillas como libultra, creo que solo 1 persona encontró como usar los coeficientes de textura apropiadamente hasta ahora, sin eso no puedes ni texturizar un cubo rotando, la textura no sabría como plasmarse en el triángulo.

Y nos queda la falta de opciones en emulación para probar los tests, limitando todo a cen64 el cual se incluye incompleto y hay que buscar los pif por separado.

Para resumirlo hace falta nivelazo para programar un SDK a tan bajo nivel, no hay soporte, quién tiene esos conocimientos habla en marciano o solo se dedica a trastear con el material comercial donde ahí si que hay cosas sorprendentes.

@Conker64 Ya veo que siguen las cosas muy difíciles. Yo pensaba que ya se había avanzado un poco mas.

ACTUALIZO:
Me acabo de topar con esto. ¿Lo conocías?
https://twitter.com/search?q=%23ultraed64

Parece que el autor tuvo un twitter y lo borró, un github y lo borró. No se si el twittero ese es el autor o que.

@radorn
Ah es deadcast no?

https://forums.tigsource.com/index.php? ... ic=46690.0

Me topé con su hilo hace años pero no me quedó claro si descartó lo que estaba haciendo para acabar usando libultra o ha vuelto de nuevo a usar su código experimental.

Viendo el twitter parece que ha estado trabajando en una interfaz gráfica, yo diría que es libultra, pero tiene muy buena pinta, es lo que muchos desearían, un visor de escenas, con un click para compilar, cen64 lanzado automáticamente..

radorn escribió:@Conker64 Ya veo que siguen las cosas muy difíciles. Yo pensaba que ya se había avanzado un poco mas.

ACTUALIZO:
Me acabo de topar con esto. ¿Lo conocías?
https://twitter.com/search?q=%23ultraed64

Parece que el autor tuvo un twitter y lo borró, un github y lo borró. No se si el twittero ese es el autor o que.

Hacerle RT y darle me gusta para que se motive! haceros cuentas clon si hace falta!

@Conker64 Parece que hay otros videos por ahí donde también automatiza lanzar la ROM en consola con 64drive por USB.

radorn escribió:@Conker64 Parece que hay otros videos por ahí donde también automatiza lanzar la ROM en consola con 64drive por USB.

Mola, yo acabé cargándome tarjetas y slots SD, de saber que trastearía con la consola hubiera pillado un cartucho con USB en su día

SuperPadLand escribió:

radorn escribió:Hacerle RT y darle me gusta para que se motive! haceros cuentas clon si hace falta!

Estaría bien adaptar esa interfaz cuando exista un SDK libre completo, a ver si vuelve a subir el github para ver lo que hizo.

Creo que hasta ahora no se había descubierto esta función de la parte trasera del mando de N64:

https://mobile.twitter.com/ThatsADarkHo ... 3630784513

avalancha escribió:Creo que hasta ahora no se había descubierto esta función de la parte trasera del mando de N64:

https://mobile.twitter.com/ThatsADarkHo ... 3630784513

Y yo pausando el juego cuando tenía que "recargar"....

Buena forma de dejar horribles marcas en el plástico. Por lo demás, muy util.

avalancha escribió:Creo que hasta ahora no se había descubierto esta función de la parte trasera del mando de N64:

https://mobile.twitter.com/ThatsADarkHo ... 3630784513

Muy grande.

Mirando la web de briconsola he visto que hay un mod fake-RGB para las PAL: https://www.briconsola.com/potenciar-co ... ntendo-64/

(Viene justo después del mod RGB para consolas NTSC)

Ya dice que no es un verdadero RGB, pero que mejora sobre un tercio la calidad. Yo tengo dos consolas PAL y quería saber opiniones de si este mod puede compensar, especialmente para después enchufarla a un televisor LCD directamente o a través de un OSSC (básicamente que no aparezcan las lineas como puños que me salen ahora).

A lo anterior se le añadiría, cuando fuera posible, las modificaciones de las rom para eliminar el filtro AA y ganar otro poco de nitidez.

Pero vamos eso ¿Opiniones resultado-precio? Ya sé que hay cosas mejores, pero más caras. Más adelante quisiera comprar una NTSC con mod RGB para usar cartuchos originales, pero también quiero tener un PAL para originales.

@SuperPadLand Lo comentó otro usuario en el hilo general, y ya dije allí que ese segundo mod no le encuentro sentido ninguno.
No vas a ver RGB. Vas a ver R, o G, o B. Uno de los tres. Pasa la señal de video compuesto a uno de los canales RGB. Imagen monocromática en rojo, verde, o azul. Y con puntitos por toda la pantalla porque no estarías separando croma. Unos puntitos muy nítidos, eso si...
De hacer esta tontería, al menos podría haberlo hecho con la patilla de luma de s-video en vez de con video compuesto, pero ya veo que el tío es un genio... Y si además, pasas la patilla por las tres entradas, al menos tendrás una imagen en blanco y negro, en vez de todo rojo o verde o azul. Aunque, sin amplificacion, imagino que se verá oscuro además de que te puedes cargar el chip a la larga.

En fin. Yo no lo veo como una alternativa a RGB ni una mejora sobre compuesto. Como mucho es un experimento curioso, pero, como mod para obtener alguna "mejora" no tiene sentido.

@radorn y que me dices de esas placas que venden para sacar RGB que afirman que son para todos los modelos PAL? https://www.youtube.com/watch?v=uN_2dVh0gvo

Aunque no dicen el precio de la placa así que seguramente sea muy cara.

@SuperPadLand Uf, tiene ya unos añitos ese vídeo...
La página donde lo venden no funciona, dicen que reabriran en 2020.
Por web archive he accedido a la página del producto. A 48€ lo tenian a la venta.
https://web.archive.org/web/20150217143051/http://www.otakus-store.net/fr/home/229-kit-modding-n64-for-all.html

Es más barato el mod de Tim, e igual de complicado de soldar.


Igual me equivoco, pero quizá salga otro mod RGB para la N64 a un precio razonable dentro de poco.

@SuperPadLand Parece una versión antigua del mod RGB universal de Tim Worthington, o quizá una versión que algún otro hizo a partir de las instrucciones del proyecto que este publicó.
Esas cosas si funcionan, porque generan su propia señal RGB a partir de la señal de video digital que sale de RCP (el chip de video y otras cosas de la N64), saltandose el DAC nativo que no produce RGB.
No tiene nada que ver con la chapuza sin sentido de briconsola.

@EMaDeLoC @radorn pues me espero a ver si sale algo mientras. Gracias

@Sogun tú que has trabajado con los mapeados 3D del Goldeneye no tendrás a mano .obj con sus texturas de Bond, Natalya, armas? Quizás algún escenario.

Tuve el Goldeneyeditor hace un tiempo pero no sé ande andará, supongo que de ahí se podrían exportar, si los extraigo del juego pinta a bastante trabajo.

Estoy haciendo cosillas en 3D y tengo algo en mente

Mario 64 se compiló originalmente sin ejecutar optimizaciones de compilación.



Basicamente, aunque en general la versión NTSC corre a 30fps estables, algunas zonas como el submarino presentan bajones importantes. Esto es debido a que no se compiló el juego sin las optimizaciones de compilación de tipo O2.
El motivo fuese posiblemente cuestión de los tiempos apurados de lanzamiento. Curiosamente en la versión PAL si se configuró el compilador con las optimizaciones. Unido a correr a 25fps y requerir menos recursos, la versión europea del juego es la más estable en framerate.

Es un vídeo interesante, aunque comete algunos fallos como la incorrecta descripción de como funciona el everdrive o pensar que la consola corre a 60 o 50 hercios según la región, cuando su velocidad es basicamente la misma.

@Conker64 En ascuas me tienes.

@EMaDeLoC Interesante cuestión.
Me ha matado cuando ha dicho que la ROM optimizada no se puede usar para speedrunning "por la impredecible variación de velocidad de las tarjetas SD" ¡GUAT DA FAC! ¿En serio? Tanto rollo explicando cosas técnicas ¿y no sabe que las ROMs se cargan en RAM primero y que no se leen de la SD durante la partida? Flipa.
Al menos ha dicho "gracias a cartuchos flash, como el EverDrive, podemos [...]" en vez de usar "everdrive" como nombre genérico.

En cuanto al video en sí, la voz del tio este me da dentera, con ese tonito sugestivo semi susurrante y esas eses de pijillo que tanto abundan en USA hoy día. No me comas el oido.

@radorn Si no usan flashcards en speedruns es simplemente para no hacer trampa, porque a ver quien te asegura que esa rom no ha sido manipulada.
En los comentarios ya le han corregido y ha pedido disculpas.

@EMaDeLoC Me pregunto si habrá un hackeo "facil" del mario PAL para que vaya a 60 en vez de 50, ya que el ritmo del juego va atado al refresco de pantalla. Con PALadin se puede hacer algo, pero estropea el sonido, por cosa del tamaño de bufer

@radorn Habría que echar un ojo al código fuente. Cambiando el reloj base de los fotogramas por segundo al del procesador se podría hacer, pero a saber cómo esta programado. Los programadores venian de las consolas con hercios bloqueados y un número concreto de ciclos y tareas entre fotograma y fotograma, no de un sistema con carga de trabajo variable y diferencias de duración entre un fotograma y otro, así que seguramente estará todo muy medido a los fps y será complicado de trabaja con ello.

@Conker64
No tengo esos modelos a mano, pero es muy fácil extraerlos desde el Editor. Puedes extraer cualquier tipo de modelo o escenario en formato OBJ o FBX (conserva los colores de los vértices).
https://github.com/carnivoroussociety/GoldEditor

Si lo vas a usar asegúrate de instalar también todo lo que se describe en la página GitHub o no te funcionará o dará problemas.

Para extraer escenarios abre el editor y haz:
-File -> New.
-Elige el nivel que quieres exportar (no cambies la escala).
-Edit Setup -> Visual Editor (si no se te abre la ventana automáticamente)
-En la esquina inferior izquierda haz click donde pone 'Edit Objects mode' hasta que cambie a 'Edit Room Positions'
-Haz click con el botón derecho sobre la geometría y busca 'Export Full Level escaled to .obj'. (te extraerá el nivel a escala del juego si no has modificado la escala al seleccionar el escenario)
-Selecciona el directorio donde quieres extraer el escenario. Te permite elegir entre OBJ, FBX y Collada Dae.

Para extraer modelos:
-En la ventana principal del editor haz:
-Tools -> Model Editor
-Arriba a la izquierda en 'choose a model' seleccionas el tipo entre personajes, objetos y armas. En el desplegable inmediatamente a la derecha seleccionas el modelo.
-Pulsa en 'Edit', que está también justo a la derecha del desplegable y deberás ver el modelo en la ventana abajo a la derecha.
-Pulsa en 'Export Whole obj' que está justo encima del visor de texturas del modelo, selecciona el directorio y el formato para exportar el modelo.

Los personajes y las armas están compuestos de varios objetos y no sé si pueden dar problemas, ya que nunca he experimentado con ellos. Las armas además renderizan de una forma especial y es muy probable que se exporte con triángulos 'del revés' además de estar "incompletas" ya que se ahorraron los polígonos que no se veían en pantalla.


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

Quería comentar un par de cosillas de hacks que han salido que me parecen destacables:

-Ya está disponible el parche Super Mario 64 cooperativo 2 jugadores a pantalla partida -> leer descripción del vídeo
Hay vídeos de gameplay y va bastante bien en el hardware real. Me pregunto si se han empleado las optimizaciones de las que habla el vídeo de @EMaDeLoC. El autor del hack menciona que "ha arreglado el lag del submarino", pero no especifica nada más. Es la misma persona que optimizó el hack Super Mario 64 Star Road y lo hizo compatible con consola optimizando el modelo de Mario entre otras cosas. Sin embargo esas mejoras no parecen aplicadas en este hack. Quizás haya margen de mejora.

Hablando del lag de Dire Dire Docks. Es algo que efectivamente nunca noté en la rom PAL. Cuando jugué a la rom NTSC en Wii64 sí que lo noté, pero pensaba que era cosa del emulador. ¿Alguien sabe si la versión NTSC de la Consola Virtual también ocurre o está arreglada?


-También quería hablar de un nuevo hack de GoldenEye llamado WW2 City -> http://n64vault.com/ge-levels:ww2-city
Es tan sólo un nivel, pero hace cosas que muestran cómo está evolucionando la comunidad. Incorpora un nuevo y sorprendente tipo de enemigo y también la posibilidad de jugarlo en alta resolución (la resolución de la secuencia de créditos que creo que era de 440x330) manteniendo pulsado el botón "L" mientras carga. -> vídeo

@Conker64 si necesitas te puedo pasar algun mapa de los mios de zelda
@Sogun Mola me recuerda al call of duty cuando aun molaba