Hilo de detalles y curiosidades de N64

@Doriandal el Winback en el peor de los casos siempre podías jugar la versión de PS2.

A mi lo que más me molesta de la emulación son esas pequeñas líneas de colores que aparecen en las divisiones de los bitmaps, ver la cara de Mario dividida en 4 en Mario Kart 64 me es bastante molesto

@luis_aig eso es porque subes la resolución creo o era porque no la subías al estirar la pantalla algo así.

@luis_aig Eso pasa por algo del filtrado bilinear o trilinear, que la consola la hace de una manera y el emulador de otra y no cuadra.
Creo que se puede solucionar configurando adecuadamente las opciones gráficas del emulador.

Pero no me hagas mucho caso porque solo he tocado un emulador de N64 una vez, después lo desinstalé, borré todo su rastro del ordenador e inmediatamente me gasté una pasta en un Everdrive64 v3. Las mejores decisiones de mi vida sin duda alguna.

Creo que con esto lo digo todo.

Lo de las líneas rosas o verdes es por el filtrado bilinear en alta resolución. Al aumentar la resolución, la parte de Nintendo 64 entiende que ese color, rosa o verde, es una transparencia, pero la GPU no sabe que eso es una transparencia y al hacer el muestreo en alta resolución se toma ese color para rellenar los nuevos texels.

Aquí está explicado de forma general, no para el caso de Nintendo 64 concretamente: http://www.adriancourreges.com/blog/201 ... nt-pixels/

Conker64 escribió:Está aprendiendo a manejar 3D según progresa, le va a tomar un tiempo:

I'm (re)learning a lot as I go. I haven't done any 3D stuff since an undergrad computer graphics course so long ago

Muy bien el Another World

¿Crees que sería muy complicado adaptar el código fuente de Little Big adventure 1 y 2 (recientemente liberados) a N64?
Sé que soy un poco pesado con estos juegos, pero siempre han sido mi debilidad... y verlos correr en la 64 ( y en Sega Saturn) sería una pasada.
Además, el mando sería especialmente bueno para estos juegos, con su joystick analógico y pudiendo usar los botones C para cambiar entre los 4 estados del personaje.

Si, entiendo el por que pasa, pero me parece curioso como muchos emuladores pueden con eso, pero al menos a mi con los de 64, PS2 y dreamcast siempre pasa

@Conker64 nos deleitarás pronto con algún destripe?

@SuperPadLand
Sí, tengo pendiente un análisis del Misión Imposible, mal porque ya me he olvidado de la película y la tendré que volver a ver para algunas referencias

@bluedark
Con el código en mano se podría adaptar, he mirado por encima y tiene algunos ficheros ASM que habría que adaptar, además de todas las llamadas a bajo nivel para gráficos y sonido.

@Conker64 yo descubrí hace poco que tiene como 24 secuelas

@Conker64 Gracias por la respuesta, pero ahora me he dado cuenta de que lo que han liberado es el motor de los juegos, pero no lo juegos en sí... por lo que la cosa se complica.
Seguramente por eso no haya visto interés por hacer ports en ningún sitio.

@Sogun Te a quedado bastante bien.
Si que es un problema la baja resolución de pantalla que tiene la N64, a la mínima que le pones detalle al texturizado se forma un amasijo de píxeles, yo estoy haciendo pantallas con el editor de Zelda OoT y Majoras y he optado por usar texturas de máximo 64x32 a 8bits o en partes que sean muy grandes, mosaicos de 64x64 en 4bits, he desistido de meter texturas de 128x64 en escala de grises, porque me pasaba lo que a ti, que la mayoría de tiempo se veía con dientes de sierra.
En el Zelda con el doble texturizado hace cosas raras( se corta la textura o se corrompe) si ambas no caben juntas en la caché, me sorprende que en el motor del GE64 y PD, permita mezclar texturas que entre las 2 exceda al tamaño de la caché, tal vez la bajada de rendimiento no sea por usar 2 cycle ( en el Zelda, están todas las superficies en 2 cycle y me a movido escenas de 3500/4000 pol/Frame sin que baje de 20 fps), sino por tener que recargar las texturas para hacer la mezcla y haga 2 veces la misma operación, tal vez si texturizas con 2 texturas que quepan en la caché a la vez, no baje tanto el rendimiento.
Por cierto,¿ tú en los niveles que haces para GE64 y PD, has tenido problemas de Z- fighting entre objetos lejanos?

Salud.

@Sogun se ve bastante bien y por lo que comentas quedaría margen de mejora en la geometría, aunque faltarían los enemigos y físicas que también comerán recursos supongo.

¿Te atreves a hacer lo mismo con las texturas del HL2?

@dirtymagic
Con el ejemplo del Zelda no he sido preciso, aunque lo he mencionado porque el resultado final es parecido. Estoy usando dos capas de polígonos con las mismas coordenadas, cada capa con una textura que por sí misma ya ocupa toda la caché . El otro ejemplo que puse de los edificios de Runway en GoldenEye es exactamente lo que he hecho pero ahí Rare usó texturas más pequeñas.

La ventaja de usar este método frente al del Zelda es que puedo repetir las texturas en patrones distintos (en Zelda la textura pequeña se repite X veces la textura grande) y variar el grado de semitransparencia (con el método Zelda no se permite) a parte de usar dos texturas más grandes. Otra ventaja es que mi método se renderiza sin problemas en emuladores, mientras que hacerlo de la manera Zelda en el motor de GE y PD no funcionaba hasta la irrupción de GlideN64 (en GoldenEye los árboles de Runway, el suelo de Depot o las paredes de Temple. En Perfect Dark las columnas de Rejilla). El principal problema es que la carga poligonal en esas superficies se multiplica por dos, aunque en algún sitio (creo que aquí) se discutió que el rendimiento es similar e incluso superior de la forma en que lo hago yo. De todas formas parece difícil mantener los 30 fps cuando hay demasiada cantidad de semitransparencias en pantalla.

Es una pena porque se pueden hacer cosas muy interesantes con capas dobles de texturas, semitransparencias e incluso mipmaps personalizados todo a la vez. Pero la consola se ahoga (los emuladores ni lo notan).


@SuperPadLand
Half-Life 2 es una bestia muy por encima de lo que puede ofrecer la Nintendo 64. Quizás se podría hacer un pasillo que diera el pego, pero nada que se saliera de ahí.
El primer Half-Life no ofrece nada que no se vea en N64 salvo en mayor cantidad, y es incluso inferior en algunos aspectos:
-Sus escenarios tienen mayor carga poligonal, pero están limitados por estar fabricados en bloques mientras que N64 es más versátil al usar triángulos.
-Las texturas tienen mucha resolución, pero también usan paletas de 256 colores así que se pueden adaptar como lo he hecho yo. A base de aumentar todavía más la carga poligonal ni siquiera habría diferencia. Luego Nintendo 64 tiene posibilidad de jugar con mipmaps o efectos como el envmapping o semitransparencias de los que no recuerdo usos llamativos en Half-Life.
-La iluminación se basa en el coloreado de vértices, igual que en Nintendo 64. Aunque Half-Life hace un uso intensivo de mapas de sombras y pocos juegos de Nintendo 64 usan algo parecido y sólo en momentos específicos.
-Donde sí le da un repaso Half-Life es en efectos de partículas (y rayitos). Ahí se junta todo lo que le cuesta a Nintendo64: muchos polígonos juntos, texturas en alta resolución y animadas, transparencias. Hay juegos que tienen un poco de cada cosa, pero jugablemente es inviable a un nivel ni siquiera cercano.
-Half-Life que yo recuerde no usa buffers para crear efectos gráficos que sí puede hacer Nintendo 64 para cosas vistosas como sombras y reflexiones en tiempo real.

Visualmente se podría hacer algo más llamativo en Nintendo 64 que lo que muestra Half-Life. En el propio mapa que he hecho hubiera estado bien tener una textura envmap que simulara un deslumbramiento en el mapamundi de Black Mesa como sí que ocurre en muchas superficies de Perfect Dark.


EDITO que me lo había dejado:

dirtymagic escribió:Por cierto,¿ tú en los niveles que haces para GE64 y PD, has tenido problemas de Z- fighting entre objetos lejanos?

El buffer-Z no tiene una precisión lineal, sino que es mucho más preciso cerca de la cámara y pierde precisión según se aleja. Es un buffer de 8-bits así que tiene 256 niveles de profundidad, pero si el elemento más lejano está a 256 metros, no hace saltos de 1 metro para saber lo que tiene que dibujar delante o detrás, sino que por ejemplo en el primer metro ya gasta 50 niveles, hasta los 10 metros otros 50, hasta los 50 metros otros 50 y al final el último paso no distingue lo que hay delante o detrás en 20 metros y hay más posibilidades que se produzca Z-fighting.
Cuanto más lejano sea el final del escenario a renderizar, más separados están los pasos y peor precisión tiene a lo lejos.

En GoldneEye pasa y hay hasta formas de hacerlo peor . Hay un parámetro que te permite graduar la distancia a la que la niebla se vuelve más densa y debe de afectar también al buffer-Z. Si alejas mucho la niebla es como si repartieras los niveles de profundidad más equitativamente y el Z-fighting se hace más notable. Especialmente en objetos, ya que están en una escala diferente al escenario y tienen los vértices más juntos.

Sogun escribió:@dirtymagic
Con el ejemplo del Zelda no he sido preciso, aunque lo he mencionado porque el resultado final es parecido. Estoy usando dos capas de polígonos con las mismas coordenadas, cada capa con una textura que por sí misma ya ocupa toda la caché . El otro ejemplo que puse de los edificios de Runway en GoldenEye es exactamente lo que he hecho pero ahí Rare usó texturas más pequeñas.

Ahh vale, eso me cuadra más.

Sogun escribió:La ventaja de usar este método frente al del Zelda es que puedo repetir las texturas en patrones distintos (en Zelda la textura pequeña se repite X veces la textura grande) y variar el grado de semitransparencia (con el método Zelda no se permite) a parte de usar dos texturas más grandes. Otra ventaja es que mi método se renderiza sin problemas en emuladores, mientras que hacerlo de la manera Zelda en el motor de GE y PD no funcionaba hasta la irrupción de GlideN64 (en GoldenEye los árboles de Runway, el suelo de Depot o las paredes de Temple. En Perfect Dark las columnas de Rejilla). El principal problema es que la carga poligonal en esas superficies se multiplica por dos, aunque en algún sitio (creo que aquí) se discutió que el rendimiento es similar e incluso superior de la forma en que lo hago yo. De todas formas parece difícil mantener los 30 fps cuando hay demasiada cantidad de semitransparencias en pantalla.

En el editor del zelda, la textura principal se puede ajustar a UV, espejar o ajustar al polígono, tanto en X como en Y, variar el grado de transparencia y repetir o estirar en X o Y y tintar, de un solo color el objeto.
La textura de arriba sólo se puede repetir o estirar en X o Y , variar la transferencia y usarla como máscara de textura.
Luego aparte tiene acceso al mezclador donde hay lo puedes cambiar los parámetros por separado a cada textura y permite configurar cada ciclo del modo 2 cycle, pero es un jaleo,xD.
Claro en emulador nunca he tenido problemas con el Z-fighting que provoca que 2 polígonos estén tan cerca uno del otro, pero yo que hago los escenarios para que los mueva la N64, no puedo hacerlo como lo haces tú, porque es el festival del parpadeo de texturas,xD, yo configuro el emulador para que sea lo más preciso a como funciona en N64.
Claro, las semitransparencia siempre van a consumir mucho fillrate al tener que pintar varios píxeles en un mismo sitio, cuantas más capas más le cuesta.

Sogun escribió:Es una pena porque se pueden hacer cosas muy interesantes con capas dobles de texturas, semitransparencias e incluso mipmaps personalizados todo a la vez. Pero la consola se ahoga (los emuladores ni lo notan).

En mi opinión, la N64 se nota, que está basada en una estación de trabajo, puede hacer muchos efectos y mezclas de búfer y texturas, que en una estación de trabajo va bien, porque quieres la máxima fidelidad sin importar la velocidad de fotogramas, pero en una consola no, le falta potencia de cómputo, para no ahogarse con todos los efectos, aún así, era lo más puntero de su época.

Sogun escribió:@SuperPadLand
Half-Life 2 es una bestia muy por encima de lo que puede ofrecer la Nintendo 64. Quizás se podría hacer un pasillo que diera el pego, pero nada que se saliera de ahí.
El primer Half-Life no ofrece nada que no se vea en N64 salvo en mayor cantidad, y es incluso inferior en algunos aspectos:
-Sus escenarios tienen mayor carga poligonal, pero están limitados por estar fabricados en bloques mientras que N64 es más versátil al usar triángulos.
-Las texturas tienen mucha resolución, pero también usan paletas de 256 colores así que se pueden adaptar como lo he hecho yo. A base de aumentar todavía más la carga poligonal ni siquiera habría diferencia. Luego Nintendo 64 tiene posibilidad de jugar con mipmaps o efectos como el envmapping o semitransparencias de los que no recuerdo usos llamativos en Half-Life.
-La iluminación se basa en el coloreado de vértices, igual que en Nintendo 64. Aunque Half-Life hace un uso intensivo de mapas de sombras y pocos juegos de Nintendo 64 usan algo parecido y sólo en momentos específicos.
-Donde sí le da un repaso Half-Life es en efectos de partículas (y rayitos). Ahí se junta todo lo que le cuesta a Nintendo64: muchos polígonos juntos, texturas en alta resolución y animadas, transparencias. Hay juegos que tienen un poco de cada cosa, pero jugablemente es inviable a un nivel ni siquiera cercano.
-Half-Life que yo recuerde no usa buffers para crear efectos gráficos que sí puede hacer Nintendo 64 para cosas vistosas como sombras y reflexiones en tiempo real.

Visualmente se podría hacer algo más llamativo en Nintendo 64 que lo que muestra Half-Life. En el propio mapa que he hecho hubiera estado bien tener una textura envmap que simulara un deslumbramiento en el mapamundi de Black Mesa como sí que ocurre en muchas superficies de Perfect Dark.

Pienso lo mismo, pero ya tendrías que adaptar todo, como se hizo en Quake 2.

Sogun escribió:EDITO que me lo había dejado:

dirtymagic escribió:Por cierto,¿ tú en los niveles que haces para GE64 y PD, has tenido problemas de Z- fighting entre objetos lejanos?

El buffer-Z no tiene una precisión lineal, sino que es mucho más preciso cerca de la cámara y pierde precisión según se aleja. Es un buffer de 8-bits así que tiene 256 niveles de profundidad, pero si el elemento más lejano está a 256 metros, no hace saltos de 1 metro para saber lo que tiene que dibujar delante o detrás, sino que por ejemplo en el primer metro ya gasta 50 niveles, hasta los 10 metros otros 50, hasta los 50 metros otros 50 y al final el último paso no distingue lo que hay delante o detrás en 20 metros y hay más posibilidades que se produzca Z-fighting.
Cuanto más lejano sea el final del escenario a renderizar, más separados están los pasos y peor precisión tiene a lo lejos.

En GoldneEye pasa y hay hasta formas de hacerlo peor . Hay un parámetro que te permite graduar la distancia a la que la niebla se vuelve más densa y debe de afectar también al buffer-Z. Si alejas mucho la niebla es como si repartieras los niveles de profundidad más equitativamente y el Z-fighting se hace más notable. Especialmente en objetos, ya que están en una escala diferente al escenario y tienen los vértices más juntos.

¿El buffer- Z es de sólo 8 bits?, pensaba que tenía que coincidir la profundidad de bits con el buffer de imagen, ahora si me cuadra la "poca" precisión que tiene.
Donde más lo noto es en esta cinemática, cuándo se aleja la cámara, hay z- fighting entre los edificios y su suelo y en los focos .


Entonces a lo mejor cambiando la escala a la escena se solucione.
Salud.

dirtymagic escribió:¿El buffer- Z es de sólo 8 bits?

El Z-buffer de N64 es de 16 bit

Es de hecho el mismo formato que el framebuffer de 16 bit , con lo cual se pueden aplicar efectos y diferentes usos de forma ingeniosa, aquí tienes más info.

@Sogun
Muy currado ese escenario del HL

@Conker64 ¿Entonces porqué hay un Z-fighting tan acusado a partir de x distancia?¿con 16 bits no es suficiente?
Salud.

dirtymagic escribió:@Conker64 ¿Entonces porqué hay un Z-fighting tan acusado a partir de x distancia?¿con 16 bits no es suficiente?
Salud.

Igual se sigue quedando corto, no dejan de ser 65535 posiciones, los Z-Buffer suelen ser de 24 o 32bit, quizás se distribuyen más valores de cerca que de lejos porque es la parte más notoria, pero en principio depende de como se configure o lo que haga cada juego en particular.

@Conker64 estoy viendo las películas de Misión Imposible que las han metido en el prime y sigo deseando ese destripe del juego.

dirtymagic escribió:

Entonces a lo mejor cambiando la escala a la escena se solucione.
Salud.

Vengo a comentar ese video... me ha dado un vuelco el corazón ver ese fragmento de la intro de mi idolatrado FF VII en N64... ¿es tuya esa intro o hay algún proyecto respecto al tema?

He visto otro video y joder que maravilla, es uno de los "what if" por excelencia de la historia de los videojuegos (al menos para mí)

@bluedark
Hola, sí, esta hecho por mi,mi idea es recrear los escenarios y cinemáticas hasta el Bar de Tifa, se podría hacer las batallas y los menús, pero ya habría que programar en C.
Es más que nada es para ver cómo podría haber sido el FF7 en N64, prescindiendo de las FMV y escenarios prerenderizados.
Como voy haciendo en los ratos libres, voy a paso de tortuga.

Salud.

@dirtymagic Pues queda muy bien, la verdad. ¿Se podría reemplazar a Link por Cloud? ¿Se puede intercambiar fácilmente el modo de vista en primera persona y el de la cámara fija desde arriba?

Me gustaría trastear con ese editor, aunque estos meses voy a tener poco tiempo.

Están desarrollando un flashcart para N64 con un Raspberry Pico.

Hablamos de que hacerse uno mismo este flashcart podría estar por debajo de los 20€.

https://github.com/kbeckmann/PicoCart64/tree/develop

bluedark escribió:@dirtymagic Pues queda muy bien, la verdad. ¿Se podría reemplazar a Link por Cloud? ¿Se puede intercambiar fácilmente el modo de vista en primera persona y el de la cámara fija desde arriba?

Me gustaría trastear con ese editor, aunque estos meses voy a tener poco tiempo.

Hola, sí, se pueden reemplazar a Link seguro y creo que al resto de personajes también.
Sí se puede configurar la cámara por estancias, desde diferentes distancias de la cámara "libre" a fijas, el cambio de cámara con el "C arriba" también se puede configurar, desde primera persona, otro ángulo de cámara o inactivo.
El editor te deja configurar todo lo que sale en los Zelda de N64, hacer escenarios es relativamente fácil, siempre siguiendo unas pautas, tanto en el nombre de las salas y etiquetas que se le puede poner en blender, para que el editor sepa si esa superficie es resbaladiza, escalable, el sonido de las pisadas ect...
Dentro del editor se puede configurar el inventario, la música, climatología, cambio de iluminación noche y día, luces dinámicas, rutas de los PNJ, hacer cutscene, texturas animadas ect...
Si usas los objetos y PNJ originales es tan fácil como elegir en una lista y colocarlos en el mapa, si quieres hacer objetos y PNJ propios ya se complica un poco más, ya que creo que tienes sustituirlo por uno existente, pero no lo tengo claro porque esa parte no la he tocado aún.
Ya si quieres modificarlo para hacer algo distinto en mecánica a los Zelda ya tienes que programar en C.
Salud.

Alguno sabe donde encontrar análisis técnicos de juegos de N64, sobre todo de rendimiento? En Google veo muy pocos

@dirtymagic perfectamente puedes ambas cosas sin programar hasta puedes poner la espada de cloud

SuperPadLand escribió:Alguno sabe donde encontrar análisis técnicos de juegos de N64, sobre todo de rendimiento? En Google veo muy pocos

No creo que encuentres mucha cosa en internet, en su época, las revistas tampoco ponían mucho énfasis en ello, como mucho promesas de los desarrolladores con que alcanzarían 25 fps (Duken nuken : Zero hour por ejemplo), o destacar mucho los 50 Fps de F- Zero X, pero por ejemplo le daban más importancia a la sensación de velocidad en los juegos de conducción que a la suavidad ( extreme G), el único que me suena de quejarse por los Fps fue el GT64 pero es que este esta en el limite de percepción del movimiento, para los seres humanos, xD.

@Flash-Original, sí lo sé, me refiero a cambiar las mecánicas propias del juego, ( por ejemplo, combates por turnos, que he visto que alguien lo hizo, eso se tiene que programar)

Salud.

No sé si se compartió, pero aquí hacen un análisis técnico a fondo de montones de consolas, enlazo al de N64:
https://www.copetti.org/es/writings/con ... ntendo-64/

Y abro pregunta ¿No fue muy desafortunado no optar por un chip de sonido para aligerar a la CPU principal? Aunque el chip fuera cutrongo.

@SuperPadLand N64 en general está plagada de decisiones cuestionables

@Falkiño sí, pero lo del chip de sonido me ha llamado bastante la atención, pero bueno supongo que es como lo del tema del RGB que por 5 céntimos lo caparon, cuando les compensaba más dejarlo y quitar el slot para el 64DD en Occidente.

SuperPadLand escribió:No sé si se compartió, pero aquí hacen un análisis técnico a fondo de montones de consolas, enlazo al de N64:
https://www.copetti.org/es/writings/con ... ntendo-64/

Uf, lo cogería con pinzas. Mete un lío explicando la RDRAM que no me lo explico si está bastante fácil de encontrar información. Por ejemplo no sabe si son 250 o 500MHz. Son 250MHz, pero la RDRAM es capaz de transmitir dos datos por ciclo de reloj, lo que le da un rendimiento de 500MHz comparado con memorias convencionales de la época.
Y la explicación de bits en paralelo y en serie... Buf...

SuperPadLand escribió:Y abro pregunta ¿No fue muy desafortunado no optar por un chip de sonido para aligerar a la CPU principal? Aunque el chip fuera cutrongo.

Cuando se decantaron por la memoria unificada cualquier chip de apoyo estaba descartado. Se supone que la gracia del RCP es que al ser GPU y chip de sonido en uno abarata costes de producción. Meter un chip de sonido habría complicado la arquitectura. Y tampoco es que hubiese aligerado mucho CPU o RCP, ya que solo se trata de mezclar canales o generar música por MIDI, y requiere de muy pocos recursos.
En la PS1 tiene más sentido al no tener la memoria unificada y cada procesador tener su propia memoria dedicada, sin entorpecerse los unos a los otros.

Falkiño escribió:@SuperPadLand N64 en general está plagada de decisiones cuestionables

Para mí la principal es crear el expansion pak. Entiendo que la RDRAM salía cara y más si cuando salió la consola había que meter dos chips de 2MB en la placa. Eso significa que de haber sacado la consola ya con 8MB, habría que meter 4 chips y practicamente no hay espacio, aunque aún cabrían.
Obviamente hicieron las cuentas, las necesidades de los desarrolladores en ese momento (4MB de RAM era una locura en la época) y vieron que incluso pagando el slot extra para el expansion pak, su tapa, y encargar los jumper pak que debían costar su dinero, les salía más a cuenta que los dos chips extra de RAM aún incluso ahorrandose todo lo anterior. No se adelantaron a que la RDRAM bajaría de precio y enseguida la diferencia se acortaría.
De haber salido de principio con 8MB, los desarrolladores habrían tenido mucho más margen para todo y más técnicas increibles habrían salido antes.

SuperPadLand escribió:No sé si se compartió, pero aquí hacen un análisis técnico a fondo de montones de consolas, enlazo al de N64:
https://www.copetti.org/es/writings/con ... ntendo-64/

Y abro pregunta ¿No fue muy desafortunado no optar por un chip de sonido para aligerar a la CPU principal? Aunque el chip fuera cutrongo.

Intenta leer la version en inglés (https://www.copetti.org/writings/consoles/nintendo-64/) que está mas actualizada. La versión española es una traducción y depende de voluntarios.

EMaDeLoC escribió:

SuperPadLand escribió:No sé si se compartió, pero aquí hacen un análisis técnico a fondo de montones de consolas, enlazo al de N64:
https://www.copetti.org/es/writings/con ... ntendo-64/

Uf, lo cogería con pinzas. Mete un lío explicando la RDRAM que no me lo explico si está bastante fácil de encontrar información. Por ejemplo no sabe si son 250 o 500MHz. Son 250MHz, pero la RDRAM es capaz de transmitir dos datos por ciclo de reloj, lo que le da un rendimiento de 500MHz comparado con memorias convencionales de la época.
Y la explicación de bits en paralelo y en serie... Buf...

• Al final del artículo puedes ver las fuentes.
• Precisamente hay un diagrama donde explica que la velocidad de bus de memoria es de 250 MHz, pero gracias a la tecnología 'Rambus Signaling Logic', el rendimiento efectivo es de 500 MHz, tal y como mencionas.
• Si encuentras errores siempre puedes ayudar reportando los fallos aquí: https://github.com/flipacholas/Architecture-of-consoles

@jua958 gracias!

Hola, este modder de SM64, que a ido mejorando el motor original de SM64, dice que consigue mover 8.000 polígonos por frame, el juego tiene desbloqueado el framerate así que oscila entre 45 y 20 fps, aunque al menos en el video mayoritariamente va 30fps, teniendo en cuenta que el pico de geometría lo alcance cuando va a 20fps, estaría moviendo 160.000 pol/sec, siendo el juego que más geometría mueve de N64 y sin prescindir del Z- Buffering como WDC, en otros videos comenta que se podría mejorar más el rendimiento, pero habría que tocar más internamente el código y los emuladores no podría ejecutarlo, @Conker64 ¿ crees que viendo las mejoras que se a conseguido y las posibles mejoras que comenta, se podría alcanzar los 8.000 pol/ frame @ 30 fps, acercándose al rendimiento en geometría de una Model 2?

Salud.

@dirtymagic
Ah, vi el vídeo hace una semana o así, pero pensé que igual no interesaría demasiado.

Cuando pone toda esa geometría explica que lo hace desde lo alto, donde la mitad de la pantalla es cielo (salvo que inclinara la vista), así que todos esos polígonos son muy pequeños, no es realmente rendimiento a pantalla completa.

Si está moviendo 160K/pol ya es una burrada, sobretodo si usa Fast3D, que es todavía más lento que F3DEX2 y que yo sepa ningún ucode oficial de Nintendo calcula más de 2 elementos por ciclo (cuando puede hacer 8), entre otras cosas, pero claro si quiere mantener la compatibilidad con emus tiene las manos bastante atadas en ese terreno.

Al final consigue más fps depurando el código del juego, que es lo que comenté a lo largo del hilo, como la memoria es unificada y todo va al mismo pozo todo cuenta, y se traduce en más fps.

SuperPadLand escribió:Alguno sabe donde encontrar análisis técnicos de juegos de N64, sobre todo de rendimiento? En Google veo muy pocos

Aquí mismo, pero a estas alturas deben estar desperdigados, aunque normalmente no los analizo como hacen algunos canales de youtube, sino que accedo a código debug para saberlo, miro algunos tramos y comento medias.

Si quieres algún canal que se dedique a jugar con un medidor o comparar versiones tienes este, un tío que le encantan los juegos de carreras, pone muchos juegos de N64 y no lo hace del WDC

Conker64 escribió:Ah, vi el vídeo hace una semana o así, pero pensé que igual no interesaría demasiado.

Por Miyamoto, ¿cómo puedes infravalorar así nuestro interes en la N64?

@dirtymagic espera, ese video es en consola real y, por una vez, no se mejora porque no iría en emuladores en lugar de hardware original?

@Conker64 aquí interesa todo siempre y sí, las cifras que diste tú también las he mirado; pero están desperdigadas. Gracias por la web, creo que ya la habíamos comentado aquí también, pero no la recordaba.

EMaDeLoC escribió:

Conker64 escribió:Ah, vi el vídeo hace una semana o así, pero pensé que igual no interesaría demasiado.

Por Miyamoto, ¿cómo puedes infravalorar así nuestro interes en la N64?

La verdad es que sí, aquí a un grupo pequeño pero fiel nos interesa todo lo que sale de N64, no tengas dudas de hacer todo los aportes que creas necesarios.

Yo todo lo que sea demostrar que N64 se acerca a una model 2 me vale. Que en ese vídeo queda margen desactivando efectos gráficos que no soporta la model 2

@EMaDeLoC
Ahora voy a hacer yo una pregunta

Para una N64 PAL FRA con mod RGB (cable c-sync) que no saca S-Video cual es la mejor (y barata) alternativa para conectarla en una TV moderna?

- Lo ideal sería hacerle el mod HDMI, pero hace ya mucho que no hablo con Marshall, años de hecho, me he dado una vuelta por ebay y me he mareado, había una con el mod por 600€
- Me consta el OSSC, veo el de Kaico por 175 leuros (en amazon, miro sitios donde sea fácil devolver algo si no me convence), se me va un poco del presupuesto (hay que sumar también una tele nueva, una odisea encontrar algo a medio camino entre lo nuevo y lo antiguo, los tacaños han quitado también componentes, los botones, el jack, el marco cada vez más fino, al final te venderán la tele en un estor plegable... el caso es que el OSSC también tiene componente además de RGB, en ebay veo otros modelos, pero al final es eso, devolverlo si luego a la tele no le gusta o algo)
- Nintendo 2X Line-Doubling N64, 60€, no parece agarrar RGB, no pinta para tirar cohetes, a pesar del precio.
- Hace tiempo en otro hilo de EOL recomendaban uno de caja cuadrada que ponía HD Converter, de unos 20-30€, ni idea del input lag

He visto otros cables, que si EON, Hyperkin (colores feos) pero entre que algunos parecen para NTSC y otros se van de precio..

Conker64 escribió:@dirtymagic
Ah, vi el vídeo hace una semana o así, pero pensé que igual no interesaría demasiado.

Cuando pone toda esa geometría explica que lo hace desde lo alto, donde la mitad de la pantalla es cielo (salvo que inclinara la vista), así que todos esos polígonos son muy pequeños, no es realmente rendimiento a pantalla completa.

Si está moviendo 160K/pol ya es una burrada, sobretodo si usa Fast3D, que es todavía más lento que F3DEX2 y que yo sepa ningún ucode oficial de Nintendo calcula más de 2 elementos por ciclo (cuando puede hacer 8), entre otras cosas, pero claro si quiere mantener la compatibilidad con emus tiene las manos bastante atadas en ese terreno.

Al final consigue más fps depurando el código del juego, que es lo que comenté a lo largo del hilo, como la memoria es unificada y todo va al mismo pozo todo cuenta, y se traduce en más fps.



Aquí mismo, pero a estas alturas deben estar desperdigados, aunque normalmente no los analizo como hacen algunos canales de youtube, sino que accedo a código debug para saberlo, miro algunos tramos y comento medias.

Si quieres algún canal que se dedique a jugar con un medidor o comparar versiones tienes este, un tío que le encantan los juegos de carreras, pone muchos juegos de N64 y no lo hace del WDC

Ya tenemos medio daytona usa, y con z-buffering.

Vamooooos.

@Conker64 yo tengo un OSSC de aliexpress que me costó 70-79€, tuve que buscar y no sé si con lo de Shangai y Ucrania han subido. En mi caso es PAL-Española con el mod RGB de Emadeloc, pero va perfecta.

Un OSSC si usas algo más que N64 creo que es la mejor opción, no es necesario irse al nuevo OSSC que va a salir por 400-500€ ni al Retrotink5x también carísimo, con el OSSC de toda la vida vas muy bien servido para montones de máquinas, yo estoy encantado. Mis tele son 1080p así que por ahora tampoco iba a aprovechar un reescalador 4K, lo único los filtros CRT y otros shaders, pero con las scanlines del OSSC normal voy sobrado.

@Conker64 lo sé, es una pena que en ese momento que lo explica no esté el contador de FPS, para hacer números, creo que una de las modificaciones que hace es precisamente es que usa FD3DX2, o como mínimo Z- sort.
En cuánto a poner la N64 en una LCD, ni idea, yo la tengo conectada por compuesto en un crt de 14".
@SuperPadLand , eso es lo que dice, supongo que los emuladores cycle accurate no habría problema, pero los que simplemente interpretan las librerías estándar tendrían problemas como en su día lo tuvieron con el WDC, SW: Battle of Naboo, Indiana Jones y alguno más que tenía microcodigo propio.
A mi personalmente, la gracia es que tire en la consola original, para hacer un mod visual, no haría falta que fuese una rom de N64, puedes usar el código fuente o replicarlo en un engine moderno, como hace uno, que esta haciendo un juego con la estética de un juego de N64 pero en unreal.
Salud.

@SuperPadLand
- Por RGB solo N64
- Por componentes tengo un cable multi para Wii / PS2 / Xbox

Ese OSSC de 70€ tiene salida HDMI? Los que veo tan baratos tienen salida componentes

--

Por cierto este documental pinta interesante

@Conker64 que yo sepa todos los OSSC sacan o HDMI o VGA. Y todos aceptan RGB, Componentes y VGA.

Lo que no aceptan es compuesto ni S-Video.

El mío saca HDMI, es bastante raro verlos ya con salida VGA.

@SuperPadLand
Igual es una mala traducción de algunos artículos que he mirado... gracias por la info

Conker64 escribió:Para una N64 PAL FRA con mod RGB (cable c-sync) que no saca S-Video cual es la mejor (y barata) alternativa para conectarla en una TV moderna?

De los escaladores, solo he probado con OSSC y RGB y la calidad es buena, dentro de lo que puede dar la consola sin hacerle deblur.
A modo de curiosidad, el N64Digital saca RGB con deblur perfecto, y no me convence. Las cosas lejanas parecen pegotes de píxeles.
Y como otra curiosidad, puedes activarle S-video a la PAL FRA. Lleva el chip BA6592F, el mismo que la SNES, y añadiendo los componentes que aparecer en los esquemas de la SNES, pues sacas S-video.

Conker64 escribió:- Nintendo 2X Line-Doubling N64, 60€, no parece agarrar RGB, no pinta para tirar cohetes, a pesar del precio.

Creo que hay cables para SNES que pasan a HDMI y pillan RGB. En principio deberían funcionar también con N64 modificadas.

Conker64 escribió:Ese OSSC de 70€ tiene salida HDMI? Los que veo tan baratos tienen salida componentes

Creo que te refieres a un convertidor SCART a YUV. Solo convierte señales. No es para tirar cohetes, para empezar no tiene la mejor circuitería. Y aunque el YPbPr tenga una calidad estupenda, las teles modernas son basura para procesar señal analógica de cualquier clase. Cualquier OSSC les da mil vueltas.

Como termino medio en precio tienes el Retroescaler 2x. Acepta RGB además de YPbPr, s-video y compuesto. Es lo más polivalente y no tiene mala calidad de imagen para el precio que es. No sé si será alguna clase de clon de los Retrotink, tiene pinta que si.
Yo de ti haría un esfuerzo invirtiendo en un OSSC. Ahora mismo lo mejor en relación calidad-precio.

Bueno pues aprovechando que al final he pillado un OSSC estoy repasando todos los juegos de carreras de N64, mi intención es fijarme en cuales son estables o mayoritariamente estables, ya que en otros géneros no molesta tanto como en conducción o carreras

Estaba probando S.C.A.R.S y me ha gustado el arranque de la pista:


El engine es bastante interesante, tiene algunos defectos como que ha veces el trozo de suelo más cercano a la pantalla desaparezca de golpe, pero gracias a eso es consistente en rendimiento, dibuja y calcula solo lo necesario, no me ha parecido verlo bajar de frames, normalmente pruebo contrarreloj y si va bien intento con más coches, en ambos casos cumple, obviamente no es necesario fijarse en el juego entero, cuando un juego va bien el 99% del tiempo pues eso, cuando otro a poco que pone un par de edificios baja, pues ya sabes que esperar del juego completo.

San Francisco Rush - Extreme Racing
Tiene caídas, en la contrarreloj, no es necesario ni probar una carrera con más vehículos, me parece bastante feo.

Rush 2
Es un calco del anterior, hasta el sistema de menús es el mismo, tiene más detalle y por ello ralentiza un poco más, yo creo que estos 2 son tan feos, a parte de por el color pasteloso, por el modo de vídeo que usan con ruido aleatorio (quizás quieren conseguir dar más sensación de velocidad con ello? Bueno el caso es que si ralentiza, también lo hace el ruido..)

San Francisco Rush 2049
Este es el bueno, mucho mejor gráficamente, con una distancia de dibujado casi infinita y para colmo consigue mantenerse en los 30fps más tiempo que los anteriores, sin embargo tiene ralentizaciones no puntuales, permanentes según la zona por la que te muevas, con lo cual no es necesario probar una carrera.

Top Gear Rally
30 fps como rocas en la contrarreloj (o 99% del tiempo), es lo que pasa cuando es Boss Studios con un microcódigo propio, física avanzada para el manejo de los coches, yo siempre lo recomiendo, hay que probarlo.

Las carreras ponen hasta 20 vehículos, obviamente separados, igual verás algunos juntos, puede rascar si hay varios coches levantando polvo cerca de la pantalla, el tipo de ralentización es sin frameskip, va algo más lento pero la pantalla no pega tirones, esta es la decisión más inteligente, porque pasar de 30 a 20 es muy molesto a la vista.

Top Gear Rally 2
Diferente equipo y engine, gráficamente diría que es "más completo" que el anterior, desafortunadamente entra más en la categoría de voy más tiempo ralentizado que bien, es disfrutable este tipo de juegos de carreras? Para mi hoy día no, en su tiempo seguramente sí.

Top Gear Overdrive
Más suave que el 2, disfrutable en ese sentido, aunque no parecen 30, pero tampoco los tiene el Wave Race 64 y se disfruta porque es consistente, música cantada en las carreras, los cristales del vehículo se transparentan y se puede ver el interior, asientos, conductor.

En carreras con 12 coches ya rasca algo, donde está la contrarreloj en este y el anterior? Debería estar penado hacer un juego de carreras y no poner ese modo.

World Driver Championship
30fps estables en la contrarreloj, salvo levantar polvo cerca o muy cerca de la cámara.

Lo mismo en las carreras mayoritariamente, dependiendo del tramo y el número de coches que se agrupen, según veo tiene 2 modos, si es leve la ralentización es de tipo cámara lenta, si baja demasiado da paso al frameskip y ya es más notorio, al chocarse y levantar polvo en todas las direcciones por ejemplo, no recordaba esas rascadas, pero si recuerdo ser un manco en este juego.

La verdad es que la música y el control del coche nunca me han gustado, me quedo con su anterior trabajo (el TGR) en esos aspectos.

A pesar de matizar este juego, junto a TGR y S.C.A.R.S están en el mismo grupo de juegos sólidos en rendimiento.

Stunt Racer 64
Pues otro más de Boss Studios, también estable en la contrarreloj, de hecho más estable que WDC (polvo somos y en polvo nos convertiremos), respuesta tardía en los controles, se me hace extraño y no demasiada sensación de velocidad a pesar de ser suave.

Y estable en las carreras, ya van 4 en esta categoría.

El que no use Z-Buffering se nota más en este juego, por el tipo de pista yo creo, la pista gira 360 grados y deja los objetos en la otra parte de la superficie viendo como se traspasan desde abajo.

Como opinión personal, no sé que tiene que se me hace muy aburrido.

Roadsters Trophy
Es de Titus (no tiene porque ser el mismo equipo que Superman 64 ) y la cosa es que no está nada mal, muy buen modelado de vehículos, descapotables con retrovisor y todo lujo de detalles, escenarios interesantes y es similar en rendimiento a Top Gear Overdrive, pero sin las ralentizaciones, a matizar.

Es estable, pero no son 30 fps y lo es en la contrarreloj, desafortunadamente es de esos juegos donde si afecta la carrera, esperable por otra parte viendo el detalle de los vehículos, igual podría mirar de extraerlos, siento curiosidad.

El fallo va a más y aunque los pierdas de vista hay tirones intermitentes, quizás la IA, las colisiones o lo que sea roban el poco margen que tenía en el time attack, lo cual no descarta que escenarios más complejos vayan peor en ese modo, no los he probado todos.

Quizás lo que más me echa para atrás sea el dibujo de los pilotos, parecen canis to chulos ahí con el neng de castefa.

Rally Challenge 2000
Intenta ir a 30fps, pero rasca en tramos completos incluso en la contrarreloj.

Tiene detalles muy interesantes, el modelado de los vehículos pero en especial el reflejo del escenario en los cristales del coche, algo muy avanzado para esa época.

Cruis'n USA
La mejor forma de definirlo es.. ¿se mueve inexplicablemente mal?

Cruis'n World
Cambio a mejor, la contrarreloj son 30fps prácticamente todo el tiempo salvo si nos movemos hacia los laterales, porque este tipo de juegos son muy rectos y agrupan todo el detalle en los lados, en plan muchos matorrales amontonados en fila, así que si la cámara centra todo eso en tamaño completo mal asunto.

En carrera sin embargo funciona un poco a cámara lenta (sin frameskip) cuando hay una vista completa de los otros 9 competidores, se arregla según se despeja, pero no le da para entrar en la categoría de "cuasi perfecto"

Cruis'n Exotica
Ahora sí, dadle una cerveza a estos programadores, estable con todas las movidas que hay en pantalla, con tráfico, objetos por medio y el resto de vehículos, escenarios muy coloridos.

Entra en la categoría aunque no he probado absolutamente todo.

Hago recuento y sigo otro día:

Juegos de carreras recomendables (por rendimiento, suavidad o como quieras llamarlo)
- Cruis'n Exotica
- S.C.A.R.S
- Stunt Racer 64
- Top Gear Rally
- World Driver Championship

5 de 14.

@Conker64 Prueba si puedes el GT 64, a ver porqué se ve tan lento, porque no parecen ralentizaciones... a lo mejor simplemente es la sensación de velocidad, que es muy baja...