[HILO OFICIAL] Nintendo 64

@EMaDeLoC

Curioso lo de el Excitebike64.
¿A que hack de SM64 te refieres?, no me suena ninguno que prescinda del Z- buffer.

Salud.

No me cabe ninguna duda de que si en N64 se desactivasen efectos como el trilinear filtering y el mipmapping, el rendimiento podría subir como la espuma y se obtendrían framerates mucho mejores que los que obtuvimos en muchos juegos de N64. Supongo que lo mismo para el Z-Buffer.

Pero estos efectos penalizaban demasiado el rendimiento. Demasiados juegos con tirones de framerate y bajones por debajo de los 30 fps. Y aparte escasez de juegos a 60 fps.

Tambien el que la consola no tuviese chip de sonido y tuviese que generarlo a golpe de CPU por norma general tambien influía en el rendimiento de los juegos. Creo que algún juego llegó a salir en mono para tener un rendimiento fluido procesando menos canales de audio.

Y me parece que la consola no fue bien aprovechada ni optimizada en su momento durante su ciclo de vida comercial. Digo esto por el rendimiento impresionante del hack del Mario 64 que va a 60 fps perfectos lo que demuestra que ni la propia Nintendo aprovechaba a tope lo que podía dar de sí la consola.

@dirtymagic , hay un hack del Mario 64 que pasa el juego de 30 fps a 60 fps. Y funciona en una consola real. Lo que ya no sé es si será cierto lo del Z-Buffer o si se trata de otras optimizaciones que hizo el loco que creó el hack.

Saludos.

Seideraco escribió:@dirtymagic , hay un hack del Mario 64 que pasa el juego de 30 fps a 60 fps. Y funciona en una consola real. Lo que ya no sé es si será cierto lo del Z-Buffer o si se trata de otras optimizaciones que hizo el loco que creó el hack.

Saludos.

Creo recordar que ese overclock al juego lo dejaba rotísimo. Supongo que no le daría tiempo a realizar cálculos internos de cámara o colisiones.

Alien_crrpt escribió:Por fin me he pasado el Diddy Kong Racing 64. Parece ser que Wipzip es uno de los boss mas injustos de todos los tiempos. Por lo menos aparece en la lista de los 25 boss mas injustos de la historia.

Parece ser que un boss cuando lo derrotas te cuenta un secreto que nadie lee. Y es que antes de pisar un turbo del suelo tienes que soltar A y justo cuando se acaba el turbo volver a pulsar A. Asi consigues que en vez de llama morada sea llama Verde que es mas velocidad. Y asi se puede derrotar al boss Wipzip de Diddy Kong Racing.

Desesperado ya que era la 3º vez que llegaba al boss y no conseguia ni acercarme entre aqui , puse el traductor y lo explica.
https://www.reddit.com/r/patientgamers/ ... _after_25/

He usado el mando oficial de nintendo online que es una replica de la N64 por bluetooth. Conectado a la Steam Link.

Yo recuerdo en su día saber lo que había que hacer, con ese comentario del "súper-turbo" que hacían en el juego, pero el timming y tiempo de pulsado/soltado exacto... Lo entendí mal o no se explicaba bien, hasta que por fin di con la clave. Una vez se sabe, ya es una carrera fácil.

@dirtymagic No pensaba en que habían salido varios. Me refería en específico al Return of Yoshi's Island de Kaze Emunar. A base de optimizarlo le ha añadido más complejidad a los escenarios y efectos de luz. Sé que también había prescindido del z-buffer en algunas cosas, pero son muchos vídeos los que ha hecho y no sé cual era donde lo explicaba.

Seideraco escribió:No me cabe ninguna duda de que si en N64 se desactivasen efectos como el trilinear filtering y el mipmapping, el rendimiento podría subir como la espuma y se obtendrían framerates mucho mejores que los que obtuvimos en muchos juegos de N64. Supongo que lo mismo para el Z-Buffer.

Por pruebas hechas en hacks e incluso algún juego con debug (Chopper Attack), vistos tanto en este hilo como especialmente en el de detalles y curiosidades de la N64, el trilinear filtering y el mipmapping no penalizan el rendimiento, no al menos de forma sustancial.

Seideraco escribió:Tambien el que la consola no tuviese chip de sonido y tuviese que generarlo a golpe de CPU por norma general tambien influía en el rendimiento de los juegos. Creo que algún juego llegó a salir en mono para tener un rendimiento fluido procesando menos canales de audio.

El RCP también procesa sonido. Hasta tiene documentación expresa de como programar los microcódigos para procesarlo. Si algunos juegos usan CPU es porque se pensaba que para mejorar el rendimiento había que liberar el RCP de generar sonido, pero no sirve de nada si luego la CPU accede a la memoria mientras el RCP esta trabajando. Por ejemplo los creadores de Top Gear Rally metieron el FastTracker 2.0 para generar la música por CPU. Es decir, tanto por CPU como por RCP el sonido no es un problema que afecte al rendimiento, a menos que sature el acceso a memoria mientras el RCP esta rasterizando.

Seideraco escribió:Y me parece que la consola no fue bien aprovechada ni optimizada en su momento durante su ciclo de vida comercial. Digo esto por el rendimiento impresionante del hack del Mario 64 que va a 60 fps perfectos lo que demuestra que ni la propia Nintendo aprovechaba a tope lo que podía dar de sí la consola.

En realidad se aprovechó bien. Lo que ocurre es que estamos hablando del año 95-96, el 3D estaba apenas creciendo, cada compañía de hardware lo hacía como le parecía (Matrox, S3, 3Dfx, Sega, Sony, SGi, etc) y en software era todavía peor. No había nada estandarizado y tampoco había tanto estudio de optimización en los cálculos matemáticos del 3D. Y por si fuera poco, el internet estaba en pañales y apenas se compartía conocimiento y documentación. Si ahora se puede optimizar tan bien un juego es porque han pasado décadas, literalmente, de gente haciendo pruebas, comprobando códigos, midiendo tiempos, analizando el hardware, etc. Cosas que ni los propios diseñadores del hardware sabian. Sin olvidar que no hay una fecha límite de entrega, Kaze lleva 3 años con su hack y todavía sigue. En la época dos años ya era una producción AAA y muy anecdótico. Y por supuesto saber con que se puede contar con 64MB de espacio en ROM ayuda en muchas cosas.
Así que, con lo que se sabía en la época, los juegos no están tan mal optimizados.

@EMaDeLoC
Ningún hack de SM64, va realmente a 60fps, porque los alcanza esporádicamente y normalmente oscilan entre los 30 y 50 Fps, y al tener doble buffer si no alcanza los 60 fps, mete frame skip y va 30 fps.
Creo que desactiva el Z-Buffer en las texturas con transparencia ( como los juegos de Rare).

El filtrado si que no cambia el rendimiento ( que supongo que es a lo que os referís como mip mapping, el Tri-mip mapping ,sí necesita 2 cycles ya que mezcla 2 texturas , otra cosa es que en juegos como los Zelda's que siempre tienen activado el 2 cycles en todas las superficies (por la niebla y el efecto de oscurecimiento cuando cargas el ataque con la espada) , si no se está utilizando 2 texturas para texturizar ( campiña de Hyrule,por ejemplo) , gaste lo mismo usando Tri-mip mapping que no.

Difiero en que se aprovecho desde un principio, sólo hay que ver que el microcódigo 3D tiene 2 actualizaciones grandes y varias menores, por no contar que salvo desde un principio Rare y muy posterior Nintendo, no se intentaba optimizar bien el uso de un tipo de texturas sobre otro, las 3rd party hacían ports sin tocar las texturas si eran de 32x32 16 bits, si eran más grandes las escalaban a esa resolución, en vez de buscar otras soluciones para mantener la resolución de texel, o Ports de PSX con el texelado anti- tembleque en los escenarios en vez de usar polígonos más grandes o aprovechar ese texelado para hacer mosaicos de texturas con mayor resolución ect..., hay cosas que si son achacables a lo verde que estaban algunas herramientas para el 3D o a la inexperiencia en 3D , pero otras era poco interés en aprovechar el potencial de la consola, trabajando con sus especificaciones concretas. Eurocom sin ser una empresa muy tocha, si se le veía el interés por adaptar a la arquitectura de la N64, con resultados dispares, que fueron mejorando con el tiempo.

Salud.

@dirtymagic Sobre lo que difieres del aprovechamiento, olvidas que en el desarrollo hay fecha límite. Bastante tiempo y dinero se pierde en hacer debug y buscar, encontrar y solucionar errores de código o diseño. Se puede dedicar un cierto tiempo y dinero en optimizar el juego, pero pasado ese límite, a la fase de beta que la fecha límite se viene encima.
Evidentemente hubo una evolución del SDK y de las capacidades de todas las desarrolladoras. Pero eso fue con el tiempo y la experiencia ganada. La mayoría de programadores se enfrentaban por primera vez al 3D y a la diferencia de cálculos que hay que hacer, en especial a la coma flotante que supone mucha diferencia tanto en manejo como en coste de computación. A medida que adquirian esa experiencia y tambien se conocía mejor el hardware se pudo optimizar mejor los juegos.
Pero en el momento de salir SM64, se hizo lo mejor que se pudo con las herramientas que se tenían. Y que alguien con el conocimiento acumulado de 20 años documentando el hardware de la N64 y el mismo tiempo en técnicas añadidas de optimizacion de código se tire 3 años optimizando SM64 no significa que el juego se lanzara mal optimizado.

Es como decirle al inventor del motor de 4 tiempos que lo hizo mal porque no usó inyectores de gasolina controlados por microprocesador o turbocompresores.

Señor Ventura escribió:

Seideraco escribió:Pero estos efectos penalizaban demasiado el rendimiento. Demasiados juegos con tirones de framerate y bajones por debajo de los 30 fps. Y aparte escasez de juegos a 60 fps.

Eso era por otro motivo, no recuerdo cual. Si un juego se queda en 59fps, el rendimiento baja automáticamente a 45... o 30... y por eso existen esos bajones. No por falta de potencia, sino por esa clase de condiciones que tiene el hardware.

Por el doble buffer. La consola genera un frame y mientras genera el siguiente, muestra el primero en pantalla. Mientras no acabe con el segundo, muestra el primero, haciendo que los fps varien dependiendo de cuanto le cuesta a la consola mostrar cada fps. En modo 60Hz la consola puede ir a 60, 40, 30, 20 o 15fps, que son divisiones de 60 (30, 20, 15) o multiplos de esas divisiones (20x2=40). A 50Hz ocurre lo mismo. El sistema es bastante susceptible, tiene que estar el frame completamente terminado o no lo saca en pantalla. Es decir, no basta que vaya a 29.99fps, tiene que ir a 30 o más, o lo baja a 20. Kaze explica que su hack lo tiene capado a 30fps aunque pueda llegar a 40, porque a 40fps los frames igualmente se tienen que mostrar en los 60Hz y eso hace que algunos frames duren dos ciclos y otros solo uno. Eso provoca stuttering y es más molesto que si fuese a 30fps estables, por eso lo deja capado.

Además 60fps requieren el doble de ancho de banda de memoria que 30fps, y es el punto flaco de la consola. Para llegar a 60fps hay que recortar el uso de otras partes, como z-buffer, texturas que se cargan en pantalla, resolución, etc. Por aquel entonces no había tanta necesidad de ir a 60fps, como mucho en las revistas decian que el juego iba "muy fluido" o tenían "gran sensación de velocidad" si era de coches. Así que los desarrolladores tiraban más a los 30fps que no requería tanta optimización ni sacrificio de gráficos que los 60fps.

Ay madre mía, cuanta barbaridad... lo primero, el Mario 64 Hack va a 60 fps perfectos, sin caidas estrepitosas de fps ni historias raras. Yo me he hinchado a jugarlo. Y hablo del hack del Mario 64 tal cual, sin niveles añadidos ni nada raro.

Es el Mario 64 a 60 fps. Punto. Y yo lo tengo en formato ROM descargado con el parche aplicado. No es tan difícil hacerse con él y que cada uno de vosotros lo probeis POR VOSOTROS mismos.

Segundo, el que dice que el framerate cuando baja de 60 a 59 fps baja a 30 fps... eso es cuando un juego tiene el Vsync activado. Y por consiguiente, tiene que mostrar el refresco de pantalla de manera que sincronice con el barrido de la televisión. Pero esto no tiene nada que ver con los tirones de framerate de N64 que se sucedían constantemente. No hay más que echarle un vistazo al Extreme G2 que es INJUGABLE.

Y sobre el sonido, ya he afirmado que por norma general, se usaba la CPU aunque tambien se pudiese usar el RCP... pero en ambos casos se quita rendimiento al sistema, bien a la CPU, bien al RCP. No hay milagros y Nintendo consideró que no merecía la pena poner un chip de sonido dedicado... pues ale, a disfrutar de la tontería de tener que usar la CPU u otro componente no diseñado específicamente para eso a realizar esa tarea.

En serio, vaya cúmulo de despropósitos hay que leer por aquí. Pensaba que había mucho más nivel. En otros hilos de EOL sí veo gente capacitada que entiende un cojón y medio del asunto, como el hilo de Amiga vs Megadrive se nota que hay nivel.

Pero esto es una verguenza las tonterías que hay que leer por aquí. Ni siquiera os habeis bajado el hack del Mario 64 a 60 fps disponible desde hace un porrón de tiempo ya. Y sigo esperando que me respondais qué programador español estuvo en Acclaim desarrollando para Nintendo 64. Parece mentira que haya gente española que presumta de entender de videojuegos y de la N64 y no tener ni repajolera idea de qué españoles programaron para esa consola.

Jesús, que agusto me he quedao xD

@Seideraco
¿La rom que dices la has jugado en hardware?¿Tiene contador de frames?, si lo juegas en emulador todos los juegos con framerate desbloqueado se ponen a 60, sólo los juegos con bloqueo de FPS, por tener las físicas o contadores de tiempo atados a ese framerate, son los que los emuladores respetan ese bloqueo, como los Zelda's o el Wacerace.
Nintendo 64 siempre tiene Vsync activado, así que sincroniza en NTSC a 60/30/20/15/12/10 ect y en PAL 50/25/17/12/10/8 ect, así que todo juego que saque menos de esos frames,hara frame skip a su siguiente más bajo. Los Hack ROMs de Kaze, que supongo que te refieres a estas, tiene contador de los frames que consigue renderizar la GPU, pero eso no significa que vaya esos frames, sino al más cercano hacia abajo de los que he puesto, la única forma de evitar esto es triple buffer, pero mete latencia en los controles, de ahí que se suela descartar.
Y sí, los tirones de framerate tienen mucho que ver con la Vsync, ya que salta a un framerate menor incluso de lo que podría pintar, si funciona a 30 fps y pierde rendimiento y baja a 25, el frame skip lo baja al siguiente escalón que es 20fps.

No sé qué edad tienes, pero yo me miraría el tono con que hablas a los demás.

Salud.

Seideraco escribió:Y sigo esperando que me respondais qué programador español estuvo en Acclaim desarrollando para Nintendo 64.

Pablo Toledo Cota, que programó solamente un juego de toda la N64, y me parece muy lamentable que uses a una persona que solo programó un juego y lo más importante, que falleció en 2007, para dartelas de importante.
Define perfectamente tu personalidad y tus intenciones al pasarte por el hilo.

EMaDeLoC escribió:

Seideraco escribió:Y sigo esperando que me respondais qué programador español estuvo en Acclaim desarrollando para Nintendo 64.

Pablo Toledo Cota, que programó solamente un juego de toda la N64, y me parece muy lamentable que uses a una persona que solo programó un juego y lo más importante, que falleció en 2007, para dartelas de importante.
Define perfectamente tu personalidad y tus intenciones al pasarte por el hilo.

Al contrario, mi intención era precisamente que se hablara de él, que de Paco Menendez se ha hablado mil veces y se han escrito un millón de artículos mientras que del gran Pablo Toledo no se dice ni mú.

Uno de los pocos programadores de Commodore 64 en España, programó el Turbo Girl para Dinamic y el Chicagos 30 para Topo Soft. Juegos del montón como corresponde a sus inicios en la programación. Pero despues se desquitó con el gran Budokan de Commodore 64 para Electronic Arts. Juego que tiene el honor de ser el juego español MEJOR puntuado en toda la historia de los 8 y 16 bits. Un 93 de nota se llevó en la ZZap 64 británica.

Tambien destacó haciendo músicas para ordenadores de 8 bits, como la del Chicagos 30 que es cojonuda,la del Silent Shadow que es aúm mejor y la del Mortadelo y Filemón 2 para Animagic.

Despues se fue a Inglaterra, donde trabajó para Acclaim en el Revolt para Nintendo 64. Está acreditado como uno de los programadores de dicho juego y se puede ver en los créditos del mismo.

El problema, que no se adaptó a la vida en Inglaterra y tuvo que volverse a España. Se puso a las órdenes de Gonzo Suarez para participar en la programación del Commandos. Esto se puede ver en la web DeVuego donde aparece como uno de los programadores de dicho Commandos.

Por todos es conocida la mala manera de exprimir que tenía Gonzo a sus programadores, apretándoles las tuercas y que terminaran hasta las narices de él. El mismo reconoció ser un tirano cuando dirigía a la gente en el Commandos y Commandos 2. Esto tuvo que ser el motivo de que Pablo Toledo terminara quemado y hastiado de todo y terminara quitándose la vida en 2007.

Así que ahora explícame como alguien a quien tengo tanta admiración puedo pensar siquiera en usarlo en este hilo para algo negativo. Me parece que el que no soy yo el que tiene la cabeza llena de negatividad.

Venga, a pasarlo bien.

Seideraco escribió:

EMaDeLoC escribió:

Seideraco escribió:Y sigo esperando que me respondais qué programador español estuvo en Acclaim desarrollando para Nintendo 64.

Pablo Toledo Cota, que programó solamente un juego de toda la N64, y me parece muy lamentable que uses a una persona que solo programó un juego y lo más importante, que falleció en 2007, para dartelas de importante.
Define perfectamente tu personalidad y tus intenciones al pasarte por el hilo.

Al contrario, mi intención era precisamente que se hablara de él, que de Paco Menendez se ha hablado mil veces y se han escrito un millón de artículos mientras que del gran Pablo Toledo no se dice ni mú.

Uno de los pocos programadores de Commodore 64 en España, programó el Turbo Girl para Dinamic y el Chicagos 30 para Topo Soft. Juegos del montón como corresponde a sus inicios en la programación. Pero despues se desquitó con el gran Budokan de Commodore 64 para Electronic Arts. Juego que tiene el honor de ser el juego español MEJOR puntuado en toda la historia de los 8 y 16 bits. Un 93 de nota se llevó en la ZZap 64 británica.

Tambien destacó haciendo músicas para ordenadores de 8 bits, como la del Chicagos 30 que es cojonuda,la del Silent Shadow que es aúm mejor y la del Mortadelo y Filemón 2 para Animagic.

Despues se fue a Inglaterra, donde trabajó para Acclaim en el Revolt para Nintendo 64. Está acreditado como uno de los programadores de dicho juego y se puede ver en los créditos del mismo.

El problema, que no se adaptó a la vida en Inglaterra y tuvo que volverse a España. Se puso a las órdenes de Gonzo Suarez para participar en la programación del Commandos. Esto se puede ver en la web DeVuego donde aparece como uno de los programadores de dicho Commandos.

Por todos es conocida la mala manera de exprimir que tenía Gonzo a sus programadores, apretándoles las tuercas y que terminaran hasta las narices de él. El mismo reconoció ser un tirano cuando dirigía a la gente en el Commandos y Commandos 2. Esto tuvo que ser el motivo de que Pablo Toledo terminara quemado y hastiado de todo y terminara quitándose la vida en 2007.

Así que ahora explícame como alguien a quien tengo tanta admiración puedo pensar siquiera en usarlo en este hilo para algo negativo. Me parece que el que no soy yo el que tiene la cabeza llena de negatividad.

Venga, a pasarlo bien.

Si lo admiras y querías hablar de él puedes hacerlo directamente sin andar con tantos rodeos. Y el hack de Mario 64 a 60fps cual es? No había ninguno hace 1-2 años que actualicé el romset del flashcard, había uno que corregía fallos en el código y evitaba ralentizaciones como la de la fase marina, pero poco más.

@Seideraco si lo admiras tanto puedes abrirle un hilo, no pinta nada en un hilo de N64.

EMaDeLoC escribió:Por el doble buffer. La consola genera un frame y mientras genera el siguiente, muestra el primero en pantalla. Mientras no acabe con el segundo, muestra el primero, haciendo que los fps varien dependiendo de cuanto le cuesta a la consola mostrar cada fps. En modo 60Hz la consola puede ir a 60, 40, 30, 20 o 15fps, que son divisiones de 60 (30, 20, 15) o multiplos de esas divisiones (20x2=40). A 50Hz ocurre lo mismo. El sistema es bastante susceptible, tiene que estar el frame completamente terminado o no lo saca en pantalla. Es decir, no basta que vaya a 29.99fps, tiene que ir a 30 o más, o lo baja a 20. Kaze explica que su hack lo tiene capado a 30fps aunque pueda llegar a 40, porque a 40fps los frames igualmente se tienen que mostrar en los 60Hz y eso hace que algunos frames duren dos ciclos y otros solo uno. Eso provoca stuttering y es más molesto que si fuese a 30fps estables, por eso lo deja capado.

Además 60fps requieren el doble de ancho de banda de memoria que 30fps, y es el punto flaco de la consola. Para llegar a 60fps hay que recortar el uso de otras partes, como z-buffer, texturas que se cargan en pantalla, resolución, etc. Por aquel entonces no había tanta necesidad de ir a 60fps, como mucho en las revistas decian que el juego iba "muy fluido" o tenían "gran sensación de velocidad" si era de coches. Así que los desarrolladores tiraban más a los 30fps que no requería tanta optimización ni sacrificio de gráficos que los 60fps.

Es practicamente toda la culpa que tiene este hardware cuando sucede un rendimiento inestable, ¿no?.

La falta de optimización que cause también fluctuaciones, no es algo de lo que se pueda culpar a la máquina, por mucho que se diga.

@Señor Ventura Hombre, toda la culpa no, es un factor a tener en cuenta.
La mayor cuplable es el ancho de banda de la RAM, que a pesar de ser muy alto (hasta medio giga por segundo en 1996 era una barbaridad) esta muy saturado al comerse todos los proceso y no tener memoria de apoyo que permitiese realizar tareas en paralelo, como sí puede PS1 o como ocurre en Gamecube que tiene la misma arquitectura que la N64 pero con los puntos flacos resueltos.
Así que todas las decisiones de diseño, resolución y fps objetivos, etc, han de tenerse en cuenta porque van a repercutir en el rendimiento del juego. Ojo, lo mismo que en PS1 y en Saturn y en cualquier consola, solo que ahí sus puntos flacos son diferentes.
Para la cuestión de los fps, lo que he dicho, para mantener 60fps estables, a la fuerza has de optimizar todo para como mínimo alcanzar los 61fps. Si en algún momento solo alcanzas los 59, el sync del RCP va a bajar a 40fps, o quizá a 50fps. Si son momentos puntuales y asumibles, los dejas, pero si pasase por ejemplo en F-Zero a trozos, pues claro, resulta muy molesto.

Hombre, si la culpa de que algo caiga de 60 a 30 o menos fps no es del hardware es porque entonces quien hace el software lo hace aposta o es un inútil, y viendo el panorama general de la época yo diría que no es el caso, el problema es el hardware que no es capaz de mantener unos rendimientos altos estables para evitar esas reducciones bruscas, podemos decir que se podía optimizar mucho más las cosas, pero para los 90 y los hitos gráficos que se lograron está bastante claro que se mataban y mucho en optimizar lo más posible dentro de lo que sabían para aprovechar hasta el último bit. Buscar la optimización perfecta generaría retrasos importantes, aparición de nuevo hardware o motores gráficos, etc que harían que lo que saques ultraoptimizado salga desfasado. Vease la historia de Duke Nukem Forever que es muy ejemplicativa de lo que pasa cuando buscas la perfección de un proyecto, pero la tecnología no para de avanzar y tú, en tu obsesión, no paras de migrar el proyecto de hardware y de motores gráficos. Al final lo lanzas después de 20 años, con ideas jugables desfasadas o supersobadas, etc.

Lo que se lanza y hace y como se hace para un hardware empieza precisamente por como es ese hardware con todos sus pros y contras. Que luego un Dios como Yu Suzuki sea capaz de adaptar el SEGA Rally a la ensalada de chips de Saturn pues es otro tema, no puedes diseñar algo que sólo cuatro superdotados puedan hacer algo potable, hoy en día hay juegos buenísimos que no están programados por eminencias ni lideres del sector, sino por gente con buenas ideas y creatividad que tienen a su disposición herramientas y hardware que permiten ejecutarlas sin rebanarse el cerebro y perder meses o años pensando como hacer que no gripe el hardware o el motor.

Pero en esa época hasta el más tonto del sector, sería un semi-dios entre la mayoría de desarrolladores actuales porque el que menos, tenía que estar horas y horas matándose para que su juego funcionase en un hardware completamente novedoso, con gráficos 3D también novedosos y según el sistema elegido con mejores o peores SDK e información. Recordemos que la peor mierda lanzada para Saturn en sus primeros años era en ensamblador, hacer esa mierda y que funcionase en 12-18 meses casi seguro que tuvo muchísimo más trabajo intelectual que lanzar lo mismo para PS1 usando C. Así que yo no diría que la culpa no es del hardware cuando algo no va. Otra cosa es lo de siempre y que ya aburre tener que decirla siempre: en 30-40 años los conocimientos de todo han mejorado mucho, se han desarrollado hasta herramientas para consolas retro que facilitan mucho sacar mejores resultados que los de la época con mucho menos esfuerzo, etc. Recordemos que en GB y NES ya hay kits de desarrollo que permiten diseñar juegos sin saber programar arrastrando con el ratón, de hecho esto mismo ya existe en motores actuales para PC para hacer juegos 3D no recuerdo si Unity u otro, lo permite.

@SuperPadLand imagina lo que ha mejorado el asunto que recuerdo leer en el Discord de los proyectos de decompilación de N64 que sin tocar nada del código, sino simplemente recompilándolo de nuevo usando un compilador más actual mejoraba el rendimiento y fps
Ya no te digo si se ponen a corregir errores y a optimizar.

Un saludo!

Falkiño escribió:@Seideraco si lo admiras tanto puedes abrirle un hilo, no pinta nada en un hilo de N64.

A mí me parece que sí teniendo en cuenta que es uno de los poquísimos españoles que programaron para Nintendo 64 durante su ciclo de vida comercial.

Comprendo que para algunos eso no sea importante pero para quienes nos criamos con revistas como la Microhobby o la Micromanía donde se hablaba y se promocionaba a los programadores españoles pues sí es muy importante.

Despues, como los españoles pasamos a no pintar absolutamente nada durante la década de los 90 pues comprendo que las nuevas generaciones no mostrasen interés alguno en lo que hacíamos en España relacionado a videojuegos.

Falkiño escribió:@SuperPadLand imagina lo que ha mejorado el asunto que recuerdo leer en el Discord de los proyectos de decompilación de N64 que sin tocar nada del código, sino simplemente recompilándolo de nuevo usando un compilador más actual mejoraba el rendimiento y fps
Ya no te digo si se ponen a corregir errores y a optimizar.

Un saludo!

Sí, algo vi de eso, pero es que ese tipo de optimizaciones "a mano" en la época ¿Cuánto hubiese llevado? Hubiesemos preferido esperar a el Mario 64 al 2001 (o más) a 60fps cuando ya estaba DC y PS2? Esto ya lo hablamos en otro hilo del Shenmue de si le iba grande a DC,ese mismo juego hubiese triunfado tanto si en lugar del 99 saliese en el 2005 para 360 a 60fps y después de los GTAs de PS2, Morrowind, Max Payne, Deus Ex, etc?

La Ultra64 podría mover M64 a 60fps y con menos optimización? Porque si es así, entonces estamos también ante un tema de hardware. Trasladar hitos del presente al pasado no es realista.

Seideraco escribió:

Falkiño escribió:@Seideraco si lo admiras tanto puedes abrirle un hilo, no pinta nada en un hilo de N64.

A mí me parece que sí teniendo en cuenta que es uno de los poquísimos españoles que programaron para Nintendo 64 durante su ciclo de vida comercial.

Comprendo que para algunos eso no sea importante pero para quienes nos criamos con revistas como la Microhobby o la Micromanía donde se hablaba y se promocionaba a los programadores españoles pues sí es muy importante.

Despues, como los españoles pasamos a no pintar absolutamente nada durante la década de los 90 pues comprendo que las nuevas generaciones no mostrasen interés alguno en lo que hacíamos en España relacionado a videojuegos.

Cuál es el hack de SM64 60fps que quiero probarlo.

Falkiño escribió:@SuperPadLand imagina lo que ha mejorado el asunto que recuerdo leer en el Discord de los proyectos de decompilación de N64 que sin tocar nada del código, sino simplemente recompilándolo de nuevo usando un compilador más actual mejoraba el rendimiento y fps
Ya no te digo si se ponen a corregir errores y a optimizar.

Un saludo!

Yo después de todo lo visto, no me cabe duda de que no se estaba usando este hardware con todo su potencial.

EMaDeLoC escribió:o como ocurre en Gamecube que tiene la misma arquitectura que la N64 pero con los puntos flacos resueltos.

Bueno, tiene tres fallos muy importantes... graves diría, incluso, teniendo en cuenta el nivel de finura que tiene para mucho de todo lo demás.

Ya solo no tener que compartir todo en un bus de 9 bits es lo que hace realmente la magia.

En GC tienes 3MB de ram embebida en el flipper, a razón de 6 bancos de 512KB, lo cual permite lo que estás pensando (una exagerada concurrencia). También quiero comprobar si el uso de la ram para z-buffer, frame buffer, y caché de texturas, está delimitada de forma fija, o si por el contrario es flexible.

Siempre he creído que estaba prefijado, pero es que recientemente he leído que el z-buffer puede ser variable si tu quieres, luego, el hueco de memoria que dejas es aprovechable para otras funciones... y si es aprovechable, por deducción no es fijo...


Lo que tiene que ser esta máquina con un juego instalado en un ssd desde el puerto inferior teniendo en cuenta que su RAM está dividida en dos bloques (leer mientras escribes, escribir mientras lees... una barbaridad desde un ssd, como digo). Ríete de la mega textura de la n64.


No quiero molestar con este tema, es solo que como n64 y gc son prácticamente madre e hija, fácilmente pueden darse los incisos...

@Señor Ventura ya hay un proyecto para usar SSD desde la ranura inferior del SP1. Se llama M.2 Loader.

Un saludo!

Falkiño escribió:@Señor Ventura ya hay un proyecto para usar SSD desde la ranura inferior del SP1. Se llama M.2 Loader.

Un saludo!

Claro, pero como loader para juegos diseñados para llenar la ram a cada carga, no para un juego que lo haga dinámicamente y a altas tasas de lectura (ssd), y escritura (ram, 1t-ram, etc).

El resultado no nos lo creeríamos.

Dicho esto, de N64 no se si me alucinó mas la demo tipo doom 3 (iluminación), que la de la megatextura, mas que nada porque para esa capacidad se pudo haber implementado de sobra en su época, para lo otro hacen falta roms GRANDES, y eso si que no se hubiese podido conseguir por las buenas

Señor Ventura escribió:Yo después de todo lo visto, no me cabe duda de que no se estaba usando este hardware con todo su potencial.

Con un matiz, el potencial que conocemos ahora, con librerias de microcódigos nuevos, mejor conocimiento de cálculos para 3D, mejores formas de optimizar el bus y el RCP... Cosas que ha conseguido la comunidad durante 30 años compartiendo información.

EMaDeLoC escribió:

Señor Ventura escribió:Yo después de todo lo visto, no me cabe duda de que no se estaba usando este hardware con todo su potencial.

Con un matiz, el potencial que conocemos ahora, con librerias de microcódigos nuevos, mejor conocimiento de cálculos para 3D, mejores formas de optimizar el bus y el RCP... Cosas que ha conseguido la comunidad durante 30 años compartiendo información.

Y que la mayoría de ellas, sino todas, son igual de trasladables y aplicables al resto de consolas. No sólo a N64 con cartuchos gigante y GC con SSD del futuro.

@SuperPadLand exacto, las mejoras son aplicables a todas.

Por cierto, hace mucho tiempo que no sale nada nuevo a nivel homebrew o no me he enterado yo? Demos aparte, aunque incluso demos como la megatextura ya son del 2023.

Igual me columpio, pero como ultimamente las libdragon estan avanzando mucho, quizá la gente está esperando a una versión definitiva. Usar el SDK original ya no tiene sentido porque aparte de desfasado no tiene finalidad comercial, al contrario que libdragon y todas las librerias nuevas que están saliendo.

EMaDeLoC escribió:Igual me columpio, pero como ultimamente las libdragon estan avanzando mucho, quizá la gente está esperando a una versión definitiva. Usar el SDK original ya no tiene sentido porque aparte de desfasado no tiene finalidad comercial, al contrario que libdragon y todas las librerias nuevas que están saliendo.

Ah genial, a ver si en unos años vivimos nuevos lanzamientos top. O un port de GTA III

Por ilustrar, estos dos vídeos se pusieron en el hilo de curiosidades estos dos últimos meses.






Creo que ya estan casi listas las librerias, pero todavía están en beta. Y claro, desarrollar un juego, que te salte un error y no tengas ni idea de si el problema esta en tu código o en el código beta de la librería... Pero vamos, parece que el tema esta ya listo o casi.

@SuperPadLand "romsfun" ahí esta necesita el expansion pak.

Tiny3D son unas librerías que están en constante evolución, hace apenas una semana se ha añadido " HDR y Bloom" o más bien ejemplo de como hacerlos ya que el Pseudo HDR es una configuración del combinador y el Bloom tiene que ver con la configuración del buffer de imagen, similar al Blur que muestran varios juegos comerciales, ambos se podían hacer en su época, no es magia negra ni nada, pero la arquitectura de N64 necesita ser entendida y eso necesita tiempo, lo cuál suele chocar con los tiempos de un producto comercial, yo creo que al final saldrán cosas con esas librerías, pero para ello hace falta tiempo y que varios programadores, artistas y músicos se junten.

Salud.

Paso a paso pero avanza la scene, el vídeo del busto Romano es de lo más brutal, de la cara del Mario64 a eso es un salto de varias generaciones, que si que solo es un modelo 3d, pero algo inconcebible en su día, si alguien viajará al pasado y pone un vídeo de esos nadie daría crédito.
Pues detrás del telón hay un desarrollador que nunca se nos olvide.
Y tengo que decirlo, a 1080p y sin caídas de frames

De todas las consolas de esa gen, creo que N64 podría mover un port de Daggerfall en la época, eso sí, en 1999-2000 porque necesitaría el cartucho de 64 megas casi seguro. Me molaría un port de este algún día, me parece un proyecto que supone un buen reto, pero sin caer en fantasías imposibles o megarecortes gráficos.

Estos son los requisitos mínimos en PC a 320x200 (por lo que he leído va "lento" aunque para la época ese "lento" igual eran 20fps y la gente fliparía igual):

En recomendados solo he encontrado 500mb de HDD y 32 de RAM. El sonido es MIDI así que en ese aspecto no habría mucho problema.

¿Opinaciones?

Edit: Dejo imagenes por si alguno no conoce el juego, que lo dudo:

@SuperPadLand Por CPU y GPU no parece que sea un problema de mover el juego. Sin embargo habría que ver la cantidad de contenido y del tipo que es que hay dentro de esos 500MB. Como parece tener mucha variedad de texturas y archivos de sonido, habría que hacer mucho trabajo reaprovechando texturas y comprimiendo audios. Y los FMV habría que cambiarlos por cinematicas.

Es bastante trabajo. Si el juego tuviese disponible el código fuente sería un proceso asumible.

EMaDeLoC escribió:@SuperPadLand Por CPU y GPU no parece que sea un problema de mover el juego. Sin embargo habría que ver la cantidad de contenido y del tipo que es que hay dentro de esos 500MB. Como parece tener mucha variedad de texturas y archivos de sonido, habría que hacer mucho trabajo reaprovechando texturas y comprimiendo audios. Y los FMV habría que cambiarlos por cinematicas.

Es bastante trabajo. Si el juego tuviese disponible el código fuente sería un proceso asumible.

Las FMV las doy por descartadas e imagino que habría que eliminar algunos enemigos, armas o reducir la variedad de edificios/naturaleza/NPC. Pero también habría que contar con la opción de comprimir texturas que parece que N64 lo hace bastante bien y su descompresión debería ser más rápida que cargarlas desde el lector CD de la época indicado ahí que entiendo que para quienes no tenían HDD suficiente cargaría desde ahí directamente, igual había parones o cargas al entrar y salir de edificios, etc.

Si puedes transladar a n64 la geometría de delphino plaza del mario sunshine, puedes transladar este daggerfall.

Señor Ventura escribió:Si puedes transladar a n64 la geometría de delphino plaza del mario sunshine, puedes transladar este daggerfall.

El problema no es la geometría sino todo el juego en su conjunto. De hecho lo he puesto porque me parece un buen reto de conseguir, pero de hacerse no sería a costa de pasar la pulidora y aguarrás al original, sino porque se podría hacer algo muy cercano al original.

@warchunein Pues esta noche me he pasado el segundo final de Diddy Kong Racing 64. Y aunque el primer jefe, una vez sabes lo del súper turbo, se hace mucho más fácil, el del cohete ha sido un dolor de huevos tremendo. Menos mal que tengo el mando de N64 de la Switch Online, porque con otro mando seguro habría costado mucho más.

Ahora, a por otro de RARE: Jet Force Gemini. Nunca llegué a matar al jefe final me estampe varias veces contra el.

Por cierto: https://www.youtube.com/watch?v=GIp7C2ro2T8&t=111s Os descargais el primer enlace del video y selecionais la ROM USA . Y a flipar lo bien que se ve.

Alien_crrpt escribió:@warchunein Pues esta noche me he pasado el segundo final de Diddy Kong Racing 64. Y aunque el primer jefe, una vez sabes lo del súper turbo, se hace mucho más fácil, el del cohete ha sido un dolor de huevos tremendo. Menos mal que tengo el mando de N64 de la Switch Online, porque con otro mando seguro habría costado mucho más.

Ahora, a por otro de RARE: Jet Force Gemini. Nunca llegué a matar al jefe final me estampe varias veces contra el.

Por cierto: https://www.youtube.com/watch?v=GIp7C2ro2T8&t=111s Os descargais el primer enlace del video y selecionais la ROM USA . Y a flipar lo bien que se ve.

Dices de aventura 2 de Diddy Kong racing? O solo has hecho la primera vuelta? Desbloqueaste a TT?

P d. Del jet force buena suerte si vas a por todas las cabezas.

soukai escribió:

Alien_crrpt escribió:@warchunein Pues esta noche me he pasado el segundo final de Diddy Kong Racing 64. Y aunque el primer jefe, una vez sabes lo del súper turbo, se hace mucho más fácil, el del cohete ha sido un dolor de huevos tremendo. Menos mal que tengo el mando de N64 de la Switch Online, porque con otro mando seguro habría costado mucho más.

Ahora, a por otro de RARE: Jet Force Gemini. Nunca llegué a matar al jefe final me estampe varias veces contra el.

Por cierto: https://www.youtube.com/watch?v=GIp7C2ro2T8&t=111s Os descargais el primer enlace del video y selecionais la ROM USA . Y a flipar lo bien que se ve.

Dices de aventura 2 de Diddy Kong racing? O solo has hecho la primera vuelta? Desbloqueaste a TT?

P d. Del jet force buena suerte si vas a por todas las cabezas.

De crio consegui todas las cabezas, pero no sabia como matar al boss. De diddy kong racing he terminado con el boss que va en el cohete.

Desbloquear al reloj T.T. tiene que ser un dolor de huevos tremendo asi que paso completamente. jejeje
Mi admiracion por los que lo hayan conseguido.

Alien_crrpt escribió:

soukai escribió:

Alien_crrpt escribió:@warchunein Pues esta noche me he pasado el segundo final de Diddy Kong Racing 64. Y aunque el primer jefe, una vez sabes lo del súper turbo, se hace mucho más fácil, el del cohete ha sido un dolor de huevos tremendo. Menos mal que tengo el mando de N64 de la Switch Online, porque con otro mando seguro habría costado mucho más.

Ahora, a por otro de RARE: Jet Force Gemini. Nunca llegué a matar al jefe final me estampe varias veces contra el.

Por cierto: https://www.youtube.com/watch?v=GIp7C2ro2T8&t=111s Os descargais el primer enlace del video y selecionais la ROM USA . Y a flipar lo bien que se ve.

Dices de aventura 2 de Diddy Kong racing? O solo has hecho la primera vuelta? Desbloqueaste a TT?

P d. Del jet force buena suerte si vas a por todas las cabezas.

De crio consegui todas las cabezas, pero no sabia como matar al boss. De diddy kong racing he terminado con el boss que va en el cohete.

Desbloquear al reloj T.T. tiene que ser un dolor de huevos tremendo asi que paso completamente. jejeje
Mi admiracion por los que lo hayan conseguido.

Pero la pregunta era si has ganado al Boss que va en cohete en la segunda vuelta de la aventura que tiene todas las pistas en espejo o el normal

@soukai what? Modo espejo? No tenía ni idea. Pero creo que ya he tenido suficiente DKR64

Y por lo que veo cambian de lugar las monedas.

Alien_crrpt escribió:@soukai what? Modo espejo? No tenía ni idea. Pero creo que ya he tenido suficiente DKR64

Y por lo que veo cambian de lugar las monedas.

Si, al derrotar a wizpig en cohete desbloqueas la aventura 2, tienes que hacer una nueva partida y es todo el juego.
En su época yo conseguí completarlo todo sin usar el turbo verde, menos el cerdo en cohete de la segunda aventura y desbloquear al reloj. Para el cerdo volador saber lo del turbo verde fue suficiente, el reloj es el reto final hasta que no dominas todo es imposible se las sabe todas el muy.

X_Glacius escribió:

Ya ha salido para los del patreon y hay reviews

https://defaultdnb.github.io/ReCollect64/blog.html#r54

La verdad es que tiene una pinta increíble y una carta de amor a los que nos gusta la 64 con todas esas referencias a distintos juegos.

El 17/05 sale para todos!!

Buenas! Sabéis si hay alguna forma humana de que el Summercart, Everdrive o similares reconozca un savegame en .fla extraído del cartucho original del Pokemon stadium 2? He probado mil conversores( para hacerlo .sav)toqueteado mil cosas pero no es posible, tal vez sepáis la solución (en caso de haberla)

Por otro lado, al intentar acceder a summercart para actualizar el firmware siempre recibo el mismo error “IO error: Coldn’t reset SC64 device (off)

Es vital actualizarlo? Tiene la versión de enero del pasado año, si veis que es un problema de que tiene algo bloqueado/fastidiado, aún estoy a tiempo de devolverlo

Entiendo que es algo así como que no puede acceder para modificar nada.

Muchas gracias de antemano

Parche para que DKR vaya a 30fps: https://defaultdnb.github.io/ReCollect64/blog.html#b134


Esta son la clase de cosas que me gustaría que llegasen a N64

SuperPadLand escribió:Parche para que DKR vaya a 30fps: https://defaultdnb.github.io/ReCollect64/blog.html#b134


Esta son la clase de cosas que me gustaría que llegasen a N64

Sin duda esto es muy interesante. Para mi los framerates tan bajos de la época hacen que algunos juegos sean menos disfrutables

Ya ha salido! En la descripción esta el link del parche