Hilo de detalles y curiosidades de N64

Hay alguien para traducirme unas cuantas funciones, se que no es del tema pero es que no se ingles y me gustaria programar un par de cosillas
Dejo aqui las que son:
https://drive.google.com/file/d/10rFcj4ugMjgS_IZjtY3XMUFYgTcXKQLq/view?usp=sharing

SuperPadLand escribió:Imagino que es imposible por alguna razón porque sino a estas alturas ya habría salido alguno, pero lo pregunto igual ¿Cómo veis de posible algún tipo de hack en las rom de juegos que usaban memory pak para que en los flashcard guarden partida como si el cartucho original tuviera RAM para guardar partida? Es algo que en NES y MS sí he visto, modificando el sistema de passwords de muchos juegos para que el programa los guarde y cargue automáticamente en la SRAM del flashcard.

En N64 imagino que no es tan fácil porque la mayoría de juegos no tienen passwords de guardado así que la modificación no consistiría en el mismo mecanismo, pero igual se puede trampear de alguna forma para que el cartucho crea que usa un memory pak al cargar desde la SD del flashcad.

La única solución razonable que yo veo al tema de los CPs es que el menú del flashcart implementase funcionalidad de administración automática de restauración y respaldo de los datos, aunque esto necesitaría de un reset al menos.

Otras rutas, como son modificar cada ROM que lo necesite o creando un bootloader que intentase interceptar las escrituras a los CPs y las redirigiese a un ficheron en la SD serían demasiado trabajosas, llendo caso por caso y una universal como un bootloader, propensa al error.

radorn escribió:

SuperPadLand escribió:Imagino que es imposible por alguna razón porque sino a estas alturas ya habría salido alguno, pero lo pregunto igual ¿Cómo veis de posible algún tipo de hack en las rom de juegos que usaban memory pak para que en los flashcard guarden partida como si el cartucho original tuviera RAM para guardar partida? Es algo que en NES y MS sí he visto, modificando el sistema de passwords de muchos juegos para que el programa los guarde y cargue automáticamente en la SRAM del flashcard.

En N64 imagino que no es tan fácil porque la mayoría de juegos no tienen passwords de guardado así que la modificación no consistiría en el mismo mecanismo, pero igual se puede trampear de alguna forma para que el cartucho crea que usa un memory pak al cargar desde la SD del flashcad.

La única solución razonable que yo veo al tema de los CPs es que el menú del flashcart implementase funcionalidad de administración automática de restauración y respaldo de los datos, aunque esto necesitaría de un reset al menos.

Otras rutas, como son modificar cada ROM que lo necesite o creando un bootloader que intentase interceptar las escrituras a los CPs y las redirigiese a un ficheron en la SD serían demasiado trabajosas, llendo caso por caso y una universal como un bootloader, propensa al error.

Igual no haría falta preparar una ROM para flashcart, sino sustituir el código del CP por uno que trabaje como si el cartucho original tuviera memoria de guardado (SRAM, EEPROM, etc). Los flashcarts ya están preparados para recoger los datos enviados a las memorias de guardado y pasarlos a un archivo en la tarjeta SD.
Hay bastantes juegos con memoria de guardado. Sabiendo las direcciones de memoria o las rutinas que manejen las librerias del SDK, no debería ser difícil sustituir el accceso al CP por la escritura/lectura de SRAM.

De todas formas los flashcarts ya descargan los CP a las tarjetas SD (al menos el Everdrive lo hace), así que se pueden guardar varios archivos con copias de los CP de cada juego que interese.

@EMaDeLoC Se me cruzaron los cables. Me refería a redirigir los guardados de CP a guardados de cartucho normales, que el cartucho flash ya está preparado para redirigir a la SD. En cualquier caso, sigue siendo una tarea de hackeo individual, ROM a ROM.

Respecto a la facilidad o dificultad del hackeo, a mi se me ha transmitido la noción de que no es tan sencillo.
Ten en cuenta también que el CP es un componente extraible en caliente (si bién no todos los juegos admiten este uso, siendo que algunos solo reconocen el CP si está presente desde el arranque y no lo sacas en ningun momento). Esto también sería algo con lo que lidiar en ese hackeo.
Además de que el código del CP variará entre las distintas revisiones del N64 OS (libultra) y muy probablemente haya juegos con codigo "custom" al respecto.
Además, el CP, siendo un accesorio del mando, que, a su vez, es controlado por el PIF, que es otro procesador, por lo visto tiene rutinas de acceso bastante engorrosas y extrañas.

En fin, que tiene pinta de ser un tema peliagudo. Por eso insisto en que el método mas seguro sería el de administrar el CP desde el menú del cartucho. Y a cuento de esto te pregunto: ¿Podrías describirme en detalle cómo administra el ED este tema? Tengo entendido que hay una herramienta manual para hacer y restaurar volcados completos del CP a y desde ficheros en la SD. ¿Hay algo mas?¿Cómo funciona? Se lo mas exacto y detallado posible. Es un tema que me interesa mucho y sobre el que pensé bastante hace un par de años para transmitirle a marshallh para el 64drive, y pero, por un lado, lo compliqué demasiado, y luego quise simplificarlo aunque hubiese que hacer sacrificios, y finalmente las circunstancias del mundo real me hicieron dejarlo de lado, y luego parece que marshallh se ha tomado un descanso de la N64 (por lo visto ahora trabaja en Analogue, junto con kevtris).

EMaDeLoC escribió:

radorn escribió:

SuperPadLand escribió:Imagino que es imposible por alguna razón porque sino a estas alturas ya habría salido alguno, pero lo pregunto igual ¿Cómo veis de posible algún tipo de hack en las rom de juegos que usaban memory pak para que en los flashcard guarden partida como si el cartucho original tuviera RAM para guardar partida? Es algo que en NES y MS sí he visto, modificando el sistema de passwords de muchos juegos para que el programa los guarde y cargue automáticamente en la SRAM del flashcard.

En N64 imagino que no es tan fácil porque la mayoría de juegos no tienen passwords de guardado así que la modificación no consistiría en el mismo mecanismo, pero igual se puede trampear de alguna forma para que el cartucho crea que usa un memory pak al cargar desde la SD del flashcad.

La única solución razonable que yo veo al tema de los CPs es que el menú del flashcart implementase funcionalidad de administración automática de restauración y respaldo de los datos, aunque esto necesitaría de un reset al menos.

Otras rutas, como son modificar cada ROM que lo necesite o creando un bootloader que intentase interceptar las escrituras a los CPs y las redirigiese a un ficheron en la SD serían demasiado trabajosas, llendo caso por caso y una universal como un bootloader, propensa al error.

Igual no haría falta preparar una ROM para flashcart, sino sustituir el código del CP por uno que trabaje como si el cartucho original tuviera memoria de guardado (SRAM, EEPROM, etc). Los flashcarts ya están preparados para recoger los datos enviados a las memorias de guardado y pasarlos a un archivo en la tarjeta SD.
Hay bastantes juegos con memoria de guardado. Sabiendo las direcciones de memoria o las rutinas que manejen las librerias del SDK, no debería ser difícil sustituir el accceso al CP por la escritura/lectura de SRAM.

De todas formas los flashcarts ya descargan los CP a las tarjetas SD (al menos el Everdrive lo hace), así que se pueden guardar varios archivos con copias de los CP de cada juego que interese.

El flashcard chino guarda las partidas en la SD de todos los juegos que originalmente guardaban en el cartucho original, eso no es un problema aquí. Lo que no permite es guardar partida en juegos que piden Memory pak (DK Zero Hour, Hexen, Daikatana, Doom 64, etc). Y que básicamente el hack que pregunto y que has explicado mejor que yo.

El último flashcard de Kirkzz además de lo anterior permite hacer copias de las partidas guardadas de la memory pak, pero no permite guardar partida en la tarjeta SD sin un memory pak. El problema aquí sería el mismo que arriba, la única diferencia es que con un memory pak pequeño puedes guardar millones de partidas volcándolas a la SD y usándolas cuando las necesites nada más.

Ayer probé el debug de DK Zero Hour para poder pasarmelo sin memory pak, pero hay un problema y es que pierdo todos los coleccionables que encuentro en cada nivel, no creo que encontrar todas las zonas secretas y salvar a todas las chicas importe mucho, pero deduzco que encontrar las 13 piezas de la máquina del tiempo y que es lo que motiva que Duke salga a trabajar sí puede ser importante para la trama.

radorn escribió:En fin, que tiene pinta de ser un tema peliagudo. Por eso insisto en que el método mas seguro sería el de administrar el CP desde el menú del cartucho. Y a cuento de esto te pregunto: ¿Podrías describirme en detalle cómo administra el ED este tema? Tengo entendido que hay una herramienta manual para hacer y restaurar volcados completos del CP a y desde ficheros en la SD. ¿Hay algo mas?¿Cómo funciona? Se lo mas exacto y detallado posible. Es un tema que me interesa mucho y sobre el que pensé bastante hace un par de años para transmitirle a marshallh para el 64drive, y pero, por un lado, lo compliqué demasiado, y luego quise simplificarlo aunque hubiese que hacer sacrificios, y finalmente las circunstancias del mundo real me hicieron dejarlo de lado, y luego parece que marshallh se ha tomado un descanso de la N64 (por lo visto ahora trabaja en Analogue, junto con kevtris).

Pues es ultra básico (ultra, lo pillas, ejejeje... ).
En el menú de opciones hay una para administrar los CP, y dentro esta la opción de guardar de CP a un archivo o cargar un archivo al CP. Si no has elegido ningún archivo a la hora de guardar, crea uno con un nombre genérico y dentro esta el contenido tal cual de los 256kb del CP. Como por defecto guarda con el mismo nombre, yo he creado unos cuantos archivos vacios con el nombre del juego (por ejemplo mkart.cpk) y usarlo para guardar el contenido del CP. Cargar desde un archivo machacará completamente su contenido. Como extra hay un visor hexadecimal para ver el contenido de los archivos, supongo que para ver si hay datos corruptos o cosas así.
Y ya está. No administra páginas ni partidas ni nada, vuelca tal cual los datos. Extremadamente simple, pero funcional.

@EMaDeLoC El 64drive también tiene una herramienta similar, aunque limitada a 6 "slots", no entiendo muy bien por qué.
Incluye un visor de contenido que lee la lista de "notas/anotaciones" ("notes" o partidas) para que tengas alguna idea de qué estas moviendo para un lado o para el otro.
Funciona bien, el único problema es la limitación de solo poder tener seis respaldos.
Se hace engorroso tener que estar editándolas desde el PC para copiar y guardar notas individuales. Además de que te obliga a planear qué quieres tener en cada uno...

Yo tengo varias ideas de cómo debería administrarse esto de forma que el menú de un cartucho de estos pudiese automatizar el volcado y restauración de estos datos, con diversas medidas de seguridad para evitar, por ejemplo, que el menú se tome libertades con datos que "no le correspondan" y te sobreescriba un CP original o vuelque un CP con otros datos a uno de tus respaldos correspondientes a un juego.

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

Y hablando de este tema... Ya lo pregunté por ahí en mas sitios a lo largo de los años, pero, ya que ha salido el tema, a ver si alguno por aquí sabeis algo sobre esto:
En diversas plataformas nos encontramos casos de juegos con algún tipo de interacción, declarada o secreta, con otros juegos y/o sus datos guardados.
Está el famoso caso de MGS en PS1, donde, en la batalla contra Psycho Mantis el motor del juego inspecciona la tarjeta de memoria y suceden cosas diferentes según lo que encuentre al examinar los guardados del propio juego e incluso juegos diferentes.
En Saturn me han comentado de algunos juegos que desbloquean algún tipo de minijuego si tienes partidas de esto o lo otro en la memoria interna de la consola.
En la propia N64 nos encontramos interacciones con juegos de GameBoy a través del Transfer Pak. Y no hablo solo de los Pokemon Stadium, si no de juegos como Perfect Dark donde se pueden desbloquear ciertos trucos introduciendo un T-Pak con el PD de GameBoy, no recuerdo si con el requerimiento de tener ciertos datos guardados en el o simplemente con la presencia del juego. También hay algo de Mario Golf y/o Tennis, y algún juego japonés.

Este tipo de interacciones entre juegos es un tema que me interesa bastante y que lamentablemente no parece estar suficientemente documentado.

La pregunta es: ¿Conoceis casos de juegos de N64 que tengan algún tipo de interacción con partidas de otros juegos presentes en el CP? Me da igual si son cosas de secuelas, si es una interacción declarada o secreta, o lo que sea. Cualquier caso que sepais me interesa.

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

La comunidad de desarrollo "casero" N64brew ha anunciado un "Game Jam", o competición de programación.



Este 13 de Octubre se anunciará la temática a la que deberán ceñirse los competidores, y a partir de ahí, tendrán dos meses, hasta el 13 de diciembre, para presentar sus proyectos, que serán juzgados por tres veteranos de la industria, un YouTuber de la comunidad de mods, y un miembro del grupo organizador.

En el mismo canal de ese video hay también lo que parecen ser, por un lado, un documental de la época sobre Acclaim y Turok, y, por el otro, una serie de tres videos que parecen ser varios miembros de Angel Studios jugando al RE2 de N64, al remake moderno del año pasado, comentando y comparando... o algo así... Duran varias horas cada uno y solo he visto un poco por encima para hacerme una idea del contenido.
Esto me recuerda que, hace años, también varios miembros de Rare que trabajaron en Conker BFD se reunieron e hicieron un video multiparte mientras jugaban y comentaban sobre el desarrollo. Yo solo los vi muy por encima, pero, si alguien quiere, aquí están https://www.youtube.com/playlist?list=P ... V0vaSL4rHf

@radorn entre juegos no me suena ya que lo habitual en N64 era que guardasen en el propio cartucho, no sé si existe algún caso como Golden Sun que al terminar el primero te da un password kilométrico que puedes usar al empezar el segundo y sirve para transferir tu partida, pero no me suena ya que juegos con passwords en N64 tampoco abundan.

Entre juegos de GB y N64 sí que creo que hay alguna cosa más me suena que Mickey Speedway USA desbloquea un circuito o personajes si usas el TP con una partida de la versión de GBC, es posible que haya más casos así ya que la mayoría de juegos de N64 tuvieron adaptación a GBC: Turok, Daikatana, PD, Gex, etc.

Se que todos pasais de mi puta cara pero en fin una curiosidad mas que no he visto mas todos los audios de dinosaur planet de la version promo de star fox

https://www.youtube.com/watch?v=6fBxLA2H-jU
@radorn Interesante no se si aceptaran mods pero como no se ingles tampoco me aventuraria a probar

Espera un momento ¿se ha avanzado en el sdk n64lib o libdragon?

@Flash-Original no pasamos de tu cara, pero yo al menos no sé de programación para ayudarte. Si se trata de traducir inglés sin más con google translate quizás puedas entenderlo.

Flash-Original escribió:Se que todos pasais de mi puta cara pero en fin una curiosidad mas que no he visto mas todos los audios de dinosaur planet de la version promo de star fox

https://www.youtube.com/watch?v=6fBxLA2H-jU
@radorn Interesante no se si aceptaran mods pero como no se ingles tampoco me aventuraria a probar

Espera un momento ¿se ha avanzado en el sdk n64lib o libdragon?

No creo que pasen de ti, simplemente que lo que has pedido es como mínimo laborioso.

Salud.

Si no lo decia a malas, lo digo porque se suele pasar de lo que diga normalmente lo de atras lo puse por si alguien podia pero no obligar a nadie

O sea de coña

@Flash-Original No, la competición no acepta ROM-hacks. Los proyectos deben ser desarrollos originales.

Respecto a tu queja, yo, por lo menos, no paso de ti, pero es que no se programar una sola linea de código, y no tengo claro qué es lo que pedías. ¿"Traducir las funciones"? No entiendo. Y al abrir el enlace vi un montonazo de cosas y la idea de ponerme a traducirlo todo, pues...

Sea como sea, en un hobby como este, y en una plataforma como N64, cierto dominio del inglés es obligado.
Si quieres programar para SOs de escritorio contemporáneos (win, lin, mac...), móviles, o incluso ordenadores caseros de la "epoca de oro" del software español, no tengo duda de que tendrás abundantes recursos en español. Pero, en el caso de N64, los materiales oficiales están en ingles y japonés, el núcleo de la scene, histórica y actual, habla inglés, las librerías y documentación que han producido están en inglés... o te defiendes con una cierta facilidad en el idioma, o lo tienes crudo. La comunidad de programación aficionada de N64 es pequeña incluso a nivel internacional, y los hispanoparlantes están integrados en ella, y, esperablemente, se comunican en inglés. No hay suficiente masa crítica para que se forme una comunidad independiente en español, ni creo que vaya a suceder en mucho tiempo, si es que algún día llega.

Pero, bueno, si me aclaras bien qué es lo que necesitas, veré si te puedo ayudar, aunque la verdad es que ya estoy muy ocupado y apurado con otras cosas.

Según entendí lo que intenta hacer @Flash-Original es programar algo o bien para Zelda OOT o Majoras Mask


Se filtró el código completo de alguno de los 2 juegos? Es ingeniería inversa? Es alguna herramienta para añadir código dentro de la ROM? Algún editor?

Según veo hay funciones sin documentar:


En caso de tener el código completo, tienes el entorno de trabajo y todos los assets para poder compilar? Compila si lo haces? Qué quieres hacer?

Las funciones de por sí no creo que sirvan para ningún otro juego, son macros y posiciones especificas.

@gelon
Ya, solo pasé a comentar que tal iban esos ports, ambos me interesan por lo raras que son esas 2 maquinas

@Conker64 Es una herramienta para añadir codigo a la ROM que junto al editor puedes añadir bastantes cosas y hay todo lo necesario para hacerlo a excpecion de animaciones que no se como ser haria, es exclusivamente para su uso en zelda si
@radorn Pues vaya yo pensaba que habria mas gente el que esta haciendo las herramientas de zelda es español por ejemplo
Pero el echo de que queria tocar programacion y tal es porque queria hacer algo para el everdrive

@Flash-Original
Y no hay tutoriales de como inyectar tu propio código? O algunos ejemplos sencillos en plan sigue éste ejemplo para reemplazar un modelado por otro o para hacer aparecer un objeto en alguna mazmorra, etc? Imagino que debe estar todo en inglés..

Viendo las funciones, sí, explican para que son y explican algunos parámetros, pero yo no sabría llegar a ningún lado con eso.

Flash-Original escribió:Pues vaya yo pensaba que habria mas gente el que esta haciendo las herramientas de zelda es español por ejemplo

Una cosa es que haya gente y otra cosa es que haya una comunidad independiente. Aunque haya muchos españoles o hispanoparlantes latinoamericanos, la comunidad de N64 sigue siendo principalmente de habla inglesa.
Para que abunde el material independiente en español hace falta mucha mas masa crítica, creo yo. Yo calculo que la comunidad de N64 no debe ser lo suficientemente grande como para que le merezca la pena a nadie fraccionarla haciendo material que solo una parte de ella va a aprovechar por el idioma, cuya solución sería invertir el doble de tiempo para traducirlo de un lado a otro.

@Conker64 Si hay tutoriales para inyectar modelado pero no quiero poner algo meramente estetico por ejemplo tengo diseñado monstruos pero claro no se ni por donde empezar y para que se esten quietos pues pierde la gracia

@radorn Pues eso limita a hacer cosas por ejemplo yo jaajaja pero en fin la n64 es una consola querida pero tienes sus cosas

@Flash-Original
Entonces tendrías que mirar todas las funciones XYZ de actor, hay de orientación, desplazamiento, velocidad, supongo que se podrá poner a un actor en modo seguimiento dándole el target de Link o usar algunos patrones de movimiento predefinidos, en Zelda los enemigos normalmente van a la suya hasta que te ven, así que ahí existe un cambio de estado y cuando te "ven" parece que son cajas invisibles que persiguen al enemigo y hacen de rango de alcance, todo esto serían conjeturas viendo ese código.

Necesitas el ID del modelado, supongo que dentro del editor devuelve o se crea una instancia.

Yo lo que haría sería localizar todas las funciones que quieres usar de ese link que pusiste y buscar info al respecto, a ver si con suerte dieras con algún ejemplo práctico, además de usar el traductor (no en la parte de código sino en las partes comentadas).

Después de Super Mario 64 otro título de Nintendo 64 ha sido recompilado tras realizarle ingeniería inversa para obtener el código fuente: Doom 64.

Esto significa que se podrán realizar ports totalmente fieles a otras plataformas y dejar de emplear emulación o mods de otros Dooms.

En el siguiente vídeo (horriblemente capturado) puede verse funcionar la rom recompilada en una Nintendo 64 sin ningún tipo de filtro aplicado a las texturas. La versión de Nintendo 64 usaba texturas de 64x64 de resolución por lo que no mostraban mipmamps, pero sí filtrado bilineal. En el minuto 2:10 puede verse perfectamente cuando el protagonista muere y la cámara se queda a ras de suelo.



La descripción del vídeo traducida:

GEC Team Discord: https://discord.gg/aEZD4Y7
Doom 64 Discord: https://discord.gg/Ktxz8nz
Erick, del GEC TEAM y DZDoom ha estado muy ocupado realizando ingeniería inversa a la rom de Doom64. He aquí un test de su código recompilado en una rom funcionando en una auténtica consola Nintendo 64. Mi conversor analógico a digital es un poco viejo así que la calidad del vídeo no es la mejor, pero muestra que la rom recompilada funciona muy bien. Una de las primeras características de este proyecto es la habilidad de apagar el filtrado de 3 puntos en las texturas tal y como se demuestra en el vídeo. Este es un enorme paso en This is a massive step forward in desentrañar el código de Doom64 lo que abre la puerta para mods en Nintendo 64 y portar directamente el código fuente de Doom 64 a PC.

@Sogun Podrías poner un enlace al parche o ROM? me pierdo con tanto discord...

@Sogun Buena noticia, porque Doom 64 es un motor mucho mejor que el de Super Mario 64, o al menos más atractivo en detalle y rendimiento. Es una puerta a realizar conversiones propias o aprender más rápido el funcionamiento de la consola.

@radorn
No he buscado el parche. Ni siquiera estoy seguro de que esté disponible. Discord lo he usado un par de veces y me agobia del caos que resulta.
Me he enterado del asunto en este enlace: https://krikzz.com/forum/index.php?topic=10429.0
Quizás ahí aparezca más información.

¿Se supone que sin mipmaping ni ningún filtro aplicado, el rendimiento es mayor?, ¿podría incrementarse la poligonización, por ejemplo?.

@Señor Ventura Por pruebas que hizo @Conker64 , creo que no había mejora, pero no eran benchmarks como tales sino juegos, así que son demasidos factores a la vez para ver si hay mejora o no de rendimiento.

EMaDeLoC escribió:@Señor Ventura Por pruebas que hizo @Conker64 , creo que no había mejora, pero no eran benchmarks como tales sino juegos, así que son demasidos factores a la vez para ver si hay mejora o no de rendimiento.

Algo debe de afectar porque al adaptar el SM Star Road para que funcionase en consola real se desactivó el filtro gráfico aunque bueno de todo lo que dice que hizo aquí puede verse que el filtro en concreto no es lo que más recursos permite ahorrar, pero cuando vas justísimo cada gota cuenta. https://youtu.be/GQjn4nVJIJw?t=63

https://n64.dev/#reverse-engineering

@SuperPadLand En el vídeo solo menciona el anti-aliasing, que es lo que evita bordes de sierra. No es lo mismo que el mipmapping o el filtro bilinear. Algo afectará en el rendimiento estos últimos, pero no mucho.

radorn escribió:https://n64.dev/#reverse-engineering

La mejor página del mundo.

@EMaDeLoC yo contestaba a raíz de lo de "sin ningún filtro aplicado".

EMaDeLoC escribió:@Señor Ventura Por pruebas que hizo @Conker64 , creo que no había mejora, pero no eran benchmarks como tales sino juegos, así que son demasidos factores a la vez para ver si hay mejora o no de rendimiento.

El mip mapping no he llegado a probarlo en un entorno 3D pero creo que el rendimiento debería mejorar en ese caso, sobretodo por no tener que cargar texturas grandes en superficies lejanas que no necesitan detalle, ahora depende de cuanto se use esa textura, si se convierte para 1 solo uso igual la cosa no cambia demasiado, una vez activas CYCLE si que es cierto que hay poca diferencia en activar o desactivar algunos efectos

Lo del DOOM64 genial

Conker64 escribió:

EMaDeLoC escribió:@Señor Ventura Por pruebas que hizo @Conker64 , creo que no había mejora, pero no eran benchmarks como tales sino juegos, así que son demasidos factores a la vez para ver si hay mejora o no de rendimiento.

El mip mapping no he llegado a probarlo en un entorno 3D pero creo que el rendimiento debería mejorar en ese caso, sobretodo por no tener que cargar texturas grandes en superficies lejanas que no necesitan detalle, ahora depende de cuanto se use esa textura, si se convierte para 1 solo uso igual la cosa no cambia demasiado, una vez activas CYCLE si que es cierto que hay poca diferencia en activar o desactivar algunos efectos

Lo del DOOM64 genial

¿A mi mip mapping te refieres al trilinear?, pensaba que sólo se activaba en 2 cycles como lo de poner dos texturas en
un polígono.
Salud.

@dirtymagic
Sí, el trilinear sí, me refería a efectos en general una vez activado CYCLE, lo cual ya te da acceso al filtro de texturas, etc

https://twitter.com/forestillusion/stat ... 49/photo/4

Un par de vídeos mostrando la diferencia gráfica entre usar el expansion pack, y no usarlo.

https://youtu.be/g2yoz_nYevI?t=5
https://youtu.be/H5C26gti54E?t=112

@Señor Ventura
Rayman2 es un caso donde creo que sí que merece la pena usar hi-res, la penalización es mínima.

Aunque a falta de probar la versión de DC, aún no he visto una versión de consola que no se ralentice, incluidas las versiones de 3DS y PS2.

@Conker64 Rayman 2 en modo low-res y con cable A/V es un borrón de gráficos de plastilina, especialmente en monitor digital. En modo hi-res con S-video (yo lo jugaba así) gana bastante aunque vaya menos fluído.

La versión Dreamcast la tuve de salida en su tiempo y es otro puto nivel: 640x480p, señal de vídeo cristalina con casi cualquier cable, 60 fps "rock solid" (aunque tb se ralentiza muy puntualmente), mayor distancia de dibujado, SONIDO superior, efectos gráficos un escalón por encima de los de N64, mejores texturas, etc. Lo único el control se me hace más cómodo en la consola de Nintendo.

Sobre el expansion pak el mejor uso que puede dársele es crear juegos desde 0 con él en mente, como por ejemplo Majora's Mask, se nota su implementación respecto a Ocarina of Time, los escenarios están como más poblados, hay mayor variedad de texturas, etc.

@Sexy MotherFucker
Pues lastima que no se curraran la versión de PS2.

En cuanto al sonido, hay algunas cosas que me gustan más de la versión original, no todo evidentemente, aunque ya es cuestión de gustos.

Lo del Expansion pak claro, al final se iban a lo más barato que era aumentar la resolución, pero creo que en el caso de Rayman 2 lo hicieron con cabeza y es un modo que vale la pena

@Conker64 la versión Ps2 también es otra que como no emplees un cable de vídeo apropiado tiende a verse borrosa y apagada aun estando en pseudo-hi res entrelazada, una lástima. Es un port algo alternativo, como una versión 1.5 con algunos cambios, una dirección algo más difusa.

De quedarme con una elijo la de Dreamcast por encima incluso de la del PC de la época, aunque el control de la de Nintendo 64 me parece el más cómodo y natural, se nota que el juego incialmente está diseñado para élla.

@Sexy MotherFucker
A mi me mataban los tiempos de carga en la PS2, los cambios que hicieron tampoco me gustaron demasiado, lastima que no tenga una DC, igual algún día me hago con una

Yo uso cable XCM por componentes para todas las 128bit, quizás no sea lo ideal pero no tengo espacio para más

@Conker64

A mi me mataban los tiempos de carga en la PS2,

Bueno, pues prepárate porque de eso también hay en Dreamcast... No recuerdo ahora mismo si más o menos llevaderos que en Ps2, pero al menos para las cut-scenes hay cortes bastante molestos entre intervalos, luego ya en las fases todo fluye sin apenas cortes.

En fin, son sistemas de soporte óptico en una era donde la RAM estaba en exceso racionada, y si encima optimizas mal (Ps2) pues lo que hay.

Y claro tú eres un megafan de la 64 y fuiste de una versión cartucho a un DVD chungo

@Conker64 En tu opinión, que máquina es mas acertada para las 2D, y cual rendiría mas en esos entornos, ¿saturn?, o nintendo 64.

@Señor Ventura
No sé, no he tocado Saturn, parece un caballo demasiado difícil de domar, además tiene chips especializados para 2D, N64 lo llevaría a fuerza de fillrate con sus rectángulos, al igual que PSX.

N64 es buena, bonita y barata para 2D, hace las cosas bien, de no tener que programar a nivel de chip hubiera sido mucho más rápido producir algo en ella (en mi caso, invertí casi 1 año solo en investigar, con libultra se tendrían resultados de inmediato), no necesita CYCLE si vas a usar tiles de scroll o cosas sin transparencia, rotación o scaling horizontal con lo cual hay bastante fillrate disponible, mucho más que en 3D, la memoria unificada y el poder acceder al framebuffer facilitan la programación, el audio no es muy amigable como contra.

Puedes tener 4 planos de scroll, un centenar de sprites en pantalla, bastantes efectos variados, algunos 3D y unas buenas animaciones con la expansión, de hecho puedes tener más que esto, pero siempre está bien definir algunas especificaciones base con las que puedes trabajar tranquilamente.

Si las desarrolladoras hubieran querido, se podrían haber hecho cosas 2D majas en la consola.

Señor Ventura escribió:@Conker64 En tu opinión, que máquina es mas acertada para las 2D, y cual rendiría mas en esos entornos, ¿saturn?, o nintendo 64.

Desde mi escaso conocimiento del hardware de N64, a priori el mayor escollo que le veo en 2D a la máquina es cara al desarrollo: hay que hacerlo todo "a mano" creándote tus propias herramientas en forma de microcódigo para que el RCP se ponga pintar pixels de la manera que quieres, en lugar de que dibuje/renderize polígonos.

En cambio Saturn tiene hardware nativo 2D, por ejemplo el VDP2 que es una suerte de sucesor espiritual del PPU1 de la SNES; un procesador que te planta hasta 4 backgrounds clásicos totalmente escalables, desescalables, rotatorios, "infinitos" estilo modo 7, transparentables, y manipulables de muchas maneras a gran profundidad de color. Sólamente este chip ya dispone en exclusiva para sí mismo de 512 kb de Vram local. Y todo es muy accesible para el programador a la hora de gestionar gráficos 2D.

En cualquier caso Nintendo 64 tiene un potencial interesante para las 2D:

- Tasa de relleno cruda mucho más bestia que la del VDP1 de Saturn, lo cual a la hora de pintar patrones 2D (sprites/texturas) puede marcar diferencia.

- Canales alpha con múltiples niveles de transparencia, un recurso que todavía seguía de lujo en aquella generación.

- Formato cartucho = tiempos de acceso superiores al CDx2 de la Saturn, lo que en títulos como The King of Fighters equivale a jugar sin desesperarte.

- 8'5 MB de Ram potenciales más flexibles que los 8 potenciales de Saturn, ya previamente repartidos.

- CPU más potente, lo que para géneros como los shooters de acción vertical/lateral implica menores ralentizaciones, más hostilidad, mejores patrones de IA, más velocidad, etc. Incluso para títulos software render rollo Doom llevaría ventaja.

- Filtros como el AA o bilineal, para limpieza de imagen.... Ejem, aunque esto ya es debatible si daña más que ayuda según el contexto.

El caso es que de todo este potencial apenas vimos pequeños destellos dentro de su catálogo, mientras que la Sega Saturn fue casi la mayor protagonista del videojuego en 2D durante aquella gen. Por eso el otro día cuando me viniste con el gif del Yoshi dije donde vas tú xD

Sexy MotherFucker escribió:Por eso el otro día cuando me viniste con el gif del Yoshi dije donde vas tú xD

Hombre, puse el gif por la iluminación esa tan orgánica, no porque sea un referente 2D xD

Bueno en realidad no hace falta uCode ni el uso del RSP para hacer un juego 2D en N64, aunque si es recomendable, ya venía en forma de S2DEX para la libultra, dado que los 3 componentes trabajan en paralelo la mejora puede ser considerable.

(Todos mis tests se basan en ignorar al RSP, sería rendimiento 2D usando CPU+RDP, donde la CPU copia el display list en la RAM y el RDP lee de ahí, si se hace por uCode la comunicación entre el RDP/RSP puede ser muy rápida, se evitan accesos extra a la RAM y beneficiaría por ejemplo la creación de las capas de scroll que se controlan por código y son repetición de tiles con patrones previsibles)

Buenas noches señores. Me apunto aqui, que desconocia totalmente este rincon!

@Conker64 ¿alguno sabéis en qué año empezó la producción de los modelos funtastic?

@Sexy MotherFucker A mi me suenan en el 99 o 2000.

EDIT: según he mirado el primer modelo salió con DK64 en el 99, color verde (jungle green en inglés). Pocos meses después, en febrero-marzo del 2000 salió el resto de la línea de colores.

Un saludo!!

@Falkiño gracias tío.

¿Y a partir de entonces cesó la producción de modelos negros, o continuó paralelamente con el mismo upgrade en la placa que las funtastic en la señal de vídeo compuesto?

Lo digo porque a mí realmente el que me mola es el modelo clásico negro. Mi N64 PAL heredada de mi hermana es de los viejos pero con una pegatina de estas de Majora's Mask que regalaron en la revistas ScreenFun y Nintendo Acción:



Y si bien no quiero desprenderme de ellas por nostalgia, estoy planeando comprarme una consola U.S.A, y quisiera repetir en negro pero con el outpout mejorado, y sin pegatinas que desluzcan su sobriedad.

@Sexy MotherFucker Pilla una japonesa que retirando una pieza te será compatible con los juegos americanos y te será incluso más fácil pillar uno de los primeros modelos con facilidad para hacerle mod RGB.
Porque los precios de las americanas... Madre mía...
Si por ebay veo consolas americanas más baratas en Europa que en la propia USA.

Por cierto, muy chula la pegatina del Zelda, aunque se haya amarilleado un poco se sigue viendo de lujo.
Pero pásale un pincel a la rendija, que tiene mucho polvo.