Hilo de detalles y curiosidades de N64

Conker64 escribió:juegos de luces, si se van a usar muchas capas simultaneas y algunas a pantalla completa lo que más me preocuparía es por mirar en cuales se puede desactivar el Z-Buffer, como hacen Goldeneye y Perfect Dark por ejemplo.

Es cierto que en las invocaciones, como los ángulos de cámara siempre son los mismos, no debería ser díficil ordenar la escena a mano y desactivar el Z-Buffer todo lo que se pueda para ganar más fill rate.

Lo único que se echaría en falta entonces es el blending aditivo, ya que como muchas capas de efectos son muy brillantes o directamente blancas, es imposible evitar voltear los colores.

Señor Ventura escribió:Si sustituyes una ram por otra físicamente exactamente igual, pero con mejores latencias, para los programas es exactamente igual, pero para el hardware además mejora el rendimiento.

¿Puede llegar a acelerar juegos?, o solo aumentar tasa de frames... pues depende del programa.

Pero en si, incompatibilidad de hardware, absolutamente cero mientras respetes el tipo de memoria, su disposición física, etc.

Hablamos de la ram de la n64 con otra exactamente igual, pero que siempre ofrezca tasas de transferencia cercanas a 500MB/s tanto con bloques grandes de datos, como con bloques pequeños de datos.

Pues oye, igual te casca un 25% mas de rendimiento, lo suficiente para que los juegos bloqueados a 30fps nunca bajen a 20, o 15fps. Ya es algo.

Me da que hasta me quedo corto.

Pero esto es en cierto modo, hacer un OC a la RAM, algo que no he visto en ningún emulador donde el OC suele meterse a la CPU, pero entiendo que se podrá "emular" una RAM más veloz. Pero bueno, aun así eso entraría dentro de la "lógica" ya conocida de N64, lo que yo preguntaba es cuando empezamos a cambiar cosas del diseño donde en lugar de memoria RAM unificada metemos la RAM troceada en pozos dedicados como hace PS1 o cuando metes caches de datos que nunca existieron, etc. Vamos cuando conviertes N64 en una GC underclock por llamarlo de alguna forma.

@riffraff Me he perdido un poco en el hilo de todo lo que estaís debatiendo, pero me ha llamado mucho la atención de esos videos que pones sobre las invocaciones en Zelda. Efectivamente para tratarse de un título de peso, las invocaciones son realmente casposas.

No sé lo que juega en contra, si el cartucho, los límites poligonales, la capacidad de texturas... Sea lo que sea se ve terriblemente...casposo.

AxelStone escribió:@riffraff Me he perdido un poco en el hilo de todo lo que estaís debatiendo, pero me ha llamado mucho la atención de esos videos que pones sobre las invocaciones en Zelda. Efectivamente para tratarse de un título de peso, las invocaciones son realmente casposas.

No sé lo que juega en contra, si el cartucho, los límites poligonales, la capacidad de texturas... Sea lo que sea se ve terriblemente...casposo.

La verdad es que las magias del Pokémon Stadium también son bastante cutres

(Y eso que lo tiene más fácil que los Final Fantasy, ya que las batallas son de uno contra uno y cuando sale una magia casi nunca muestran a los dos bichos a la vez.)

Con todo y con eso, el frame rate cae cuando hay demasiadas transparencias en pantalla:

¿Invocaciones en el Zelda?
El tema de lo poco vistosos que son los ataques en PS, diría que es más dirección artística que potencia per sé, no me suena ningún Pokemón puntero ni gráfica, ni artísticamente en ninguna plataforma.
Y en los propios FF de PSX, se nota que la dirección artística hace más, que la potencia bruta, en FF7 todos los modelos 3D tienen más polígonos que sus homónimos en entregas posteriores y sin embargo es el que peor se ve.

Salud.

@riffraff Madre mía, se ven fatal.

@dirtymagic Entiendo que la dirección artística también contribuye, pero al final todo suma. La realidad es que en N64 este tipo de invocaciones quedan como el culo. En Pokemon podríamos argumentar que es un juego sin aspiraciones técnicas, pero Zelda...

Es llamativo que incluso las invocaciones del Shining the Holy Ark de Saturn, siendo una consola minoritaria y con limitaciones 3D, resultan más llamativas. No dudo una vez más que la parte artística puede influir, pero al final lo importante es lo que nos transmite el juego. Y esas invocaciones de N64 transmiten un...¿¡WTF!?

Por un motivo o por otro es una consola a la que siempre le veo mucho saltar las costuras, no termina de romper.

Por poner algo más, pongo magias del Ogre Battle.

Tampoco son muy allá, peores que las del Final Fantasy Tactics y eso que el fondo es un plano 2D:

@riffraff
Sí, el additive blending no se usaría de forma comercial, solo en la scene si sabes lo que haces.

--
Con relación al rendimiento:

Ayer puse el FFIX (en una PS3) y vi algunas caídas alarmantes, este ataque de Steiner baja de los 2 dígitos, faltaría por comprobar en la consola real, pero fue tal cual este vídeo (y en otros que he buscado):


Lo que viene a ser completamente normal, ninguna consola se salva de esos primeros planos con tan limitado fillrate.

Conker64 escribió:@riffraff
Sí, el additive blending no se usaría de forma comercial, solo en la scene si sabes lo que haces.

Si una de las capas del blending es blanca, da igual lo que sepas hacer, te comes el overflow de color sí o sí

@Conker64 hablo de memoria y de hace eones, pero creo recordar lo que me parecían micro pausas al ejecutar algunos ataques en FFIX, parecido al Zelda TP cuando hacía el ataque cargado golpeando a varios enemigos.

@riffraff
Los componentes son RGB, el blanco sería la suma de todos ellos, Krom en su día me comento de separar en un buffer por componente (3 buffers), aunque fue una respuesta improvisada y habría que ponerla en práctica, yo creo que lo ideal para salir de dudas (si es un tema que interesa) sería pasarse por el discord de la scene ahora que está onfire y preguntar si hay alguna forma viable.

Otra opción es usar la CPU, gracias al acceso del framebuffer, en porciones que permitan trabajar con sus 8KB de datos y subir el resultado a TMEM como textura para dibujar por hardware, podría servir, para cosas pequeñas, no es una idea loca, es justo lo que hacía para este efecto de deformación de la llama en el fondo, a 60fps sin problema:


Pero como digo querer buscar a una solución a un blending sin clamp, es querer romperse la cabeza.

@SuperPadLand
En el vídeo es una caída sostenida de rendimiento, te refieres a otro tipo de pausas para intensificar los golpes? En el Wind Waker es bastante notorio al pegar espadazos.

Los 2 Zeldas de N64, ninguno tiene invocaciones, así que es un poco difícil compararlas con unos juegos donde es donde más fuerza bruta y espectacularidad quieren dar, eso sí, justitos de FPS y con bajones, que parece que ahora PSX era una roca del rendimiento, cuando como todas tenía sus rascadas.
Y no me vale comparar una cutscenes, donde los efectos que muestra son utilitarista de lo que se quiere contar, no buscan ninguna espectacularidad.

Está escena perse no es muy espectacular, pero está moviendo 8.000 Pol/ frame, seguramente mucho más que cualquier invocación de un FF de PSX, pero reconozco que es más espectacular las invocaciones.

Salud

@Conker64 puede ser, como digo es algo que me queda muy lejos


@dirtymagic 8000 por 30fps? Son 240000 pol/s ¿Estás seguro de esas cifras? En PS1 los juegos más tochos que yo sepa no pasan de los 2000-3000 por frame que son 60-90K pol/s. Claro que esto baila mucho según resoluciones, tipo de polígnos planos, sombreados y texturizados que se usan en cada frame y que pueden ir variando continaumente, efectos de luz, trasparencia, IA, físicas, etc.

@SuperPadLand
Es con el motor del Zelda OoT, 20 Fps posiblemente en el punto más alejado 15 fps, 2 cycle, cutscene y geometría sin colisión, cuando la cámara está lo más alejada y se ve el escenario entero son 7800 triángulos, el backculling, le rebajará un poco pero tampoco creo que mucho por la perspectiva, tiene mucho por optimizar, que es en lo que estoy trabajando, LOD en CADA sector , Torre y reactor y Cull manual, para evitar renderiza zonas que tapan otras estructuras y pasar las superficies que se puedan a 1 cycle.

Salud.

@dirtymagic ah vale, eso ya son cifras más acordes. La verdad no me pareció que fuera a 20fps, está muy bien hecho.

Edit: ¿Lo has hecho tú? Mis dieses

dirtymagic escribió:@SuperPadLand
Es con el motor del Zelda OoT, 20 Fps posiblemente en el punto más alejado 15 fps, 2 cycle, cutscene y geometría sin colisión, cuando la cámara está lo más alejada y se ve el escenario entero son 7800 triángulos, el backculling, le rebajará un poco pero tampoco creo que mucho por la perspectiva, tiene mucho por optimizar, que es en lo que estoy trabajando, LOD en CADA sector , Torre y reactor y Cull manual, para evitar renderiza zonas que tapan otras estructuras y pasar las superficies que se puedan a 1 cycle.

Salud.

¿camino de 160 mil polígonos por segundo?, que salvajada.

Conker64 escribió:Otra opción es usar la CPU, gracias al acceso del framebuffer, en porciones que permitan trabajar con sus 8KB de datos y subir el resultado a TMEM como textura para dibujar por hardware, podría servir, para cosas pequeñas, no es una idea loca, es justo lo que hacía para este efecto de deformación de la llama en el fondo, a 60fps sin problema:

¿Dónde se encuentrsn esos 8KB?.

@Señor Ventura
La CPU tiene 8KB de cache para datos, puedes ahorrar lecturas en la RAM si todo lo que necesitas hacer cabe dentro, como tener las 2 muestras, una origen y otra de destino.

Es probable que también puedas saltarte el paso de subir a TMEM y de ahí dibujar, volcando el resultado de la cache o copiando después a la zona que corresponde, ahora no recuerdo porqué decidí hacerlo de la primera manera, pero al final sería buscar la solución que más le guste a la consola.

@dirtymagic Ya te lo dije hace un tiempo, pero esas escenas de FFVII en N64 me parecen espectaculares.

Cuando consiga liberarme de unos asuntos me gustaría aprender a manejar esas herramientas y echarte una mano con ese "port"... o al menos trastear un poco. Jugar aunque fuera la primera hora completa de FF VII en N64 sería para mí un sueño cumplido.

Conker64 escribió:@Señor Ventura
La CPU tiene 8KB de cache para datos, puedes ahorrar lecturas en la RAM si todo lo que necesitas hacer cabe dentro, como tener las 2 muestras, una origen y otra de destino.

Es probable que también puedas saltarte el paso de subir a TMEM y de ahí dibujar, volcando el resultado de la cache o copiando después a la zona que corresponde, ahora no recuerdo porqué decidí hacerlo de la primera manera, pero al final sería buscar la solución que más le guste a la consola.

Que coincidente que justo la caché de la cpu sea el doble que la memoria de texturas, pero si fuese posible dibujar la textura en un polígono sin pasar por la memoria de texturas, ¿cabe la posibilidad de texturizar dos polígonos simultáneamente?.

El ritmo de texturizado sería diferente, pero si no entrase en conflicto es una oportunidad de ganar rendimiento, ¿no?.

@bluedark
Pues ahora lo tengo "parado" porque he cambiado de herramienta de SharpOcarina a Fast64, y el uso de materiales no es compatible, así que estoy rehaciendo todo el tema de las texturas en los modelos que voy a reutilizar y además estoy rehaciendo la estación de trenes y la entrada del reactor, aparte que hay parte del escenario que quiero convertir en objetos para reutilizarlos en otras partes y no este ligado a la geometría del nivel, niveles de LOD, mejorar visualmente los escenarios usando 2 texturas como aquí.





Vamos que por faena no será, mi idea era hacer desde el principio hasta el bar de tifa, incluidas la intro y las cutscenes que hay.Pero es un faenon para una persona sola.
@Señor Ventura
Una cosa es que la CPU pueda manipular el Framebuffer que esta en RAM, y otra rasterizar con soltura , aparte que se perdería el filtrado de texturas, yo creo que con el tema de texturizar con 2 texturas sacas suficiente detalle para una imagen de 320x240 que es el estandar de esa generación.
Salud.

@dirtymagic Claro, como caso de probabilidad, que es lo que comenta conker64.

Suena mas útil postprocesar una textura en su caché, y enviarla a la tmem, pero ya puestos, si la cpu pudiese texturizar desde su caché estaría curioso poder ver un benchmark desde un agujerito.

Bueno, pues queda claro que la Nintendo 64 podía hacer cualquier juego de la PSX (quitando escenas de vídeo y audio de calidad CD) y viceversa (bajando los polígonos).

Y vamos a dar por bueno que Square, pese a sus declaraciones, cambió la N64 por la PSX por dinero.

Hasta aquí todo bien, pero... ¿cómo se explica entonces que para la N64 solo salieran 8 RPG y para la PSX, 421? ¿Compró Sony a todos o había algo más?

PABEOL escribió:Bueno, pues queda claro que la Nintendo 64 podía hacer cualquier juego de la PSX (quitando escenas de vídeo y audio de calidad CD) y viceversa (bajando los polígonos).

Y vamos a dar por bueno que Square, pese a sus declaraciones, cambió la N64 por la PSX por dinero.

Hasta aquí todo bien, pero... ¿cómo se explica entonces que para la N64 solo salieran 8 RPG y para la PSX, 421? ¿Compró Sony a todos o había algo más?

Los costes totales de desarrollar y distribuir un juego en PS1 eran infinitamente más baratos que en N64 y en eso Sony metió mucho la mano, no es una compra con maletines directamente, pero si una compra indirecta, que no tiene nada de malo, me parece una forma de competencia muy sana. Y ojo no es sólo que fuera "más barato" en PS1, si en N64 algo era más caro de hacer, pero esperas que reporte igualmente beneficios lo haces porque aunque el margen sea menor, siguen siendo beneficios que sumas. Lo que pasa es que estos menores costes implican al mismo tiempo un muchísimo menor riesgo al lanzar un juego porque necesitas menos ventas para cubrir gastos y eso hizo que PS1 en esa época fuera un poco la consola de los indies experimentales, sobre todo en Japón donde era todavía más barato distribuir el juego. Ahí tienes juegos a patadas que son experimentos, cosas de bajo presupuestos, ports de máquinas anteriores, casuals estilo Nintendogs, etc.

Un RPG por definición es un desarrollo de los más caros donde puedes meterte y por tanto, más ventas necesitas para justificarlo que sumado a lo dicho de N64 hacía que todavía necesitaras más ventas y eso reduce el número de valientes que lo intentaron. Métele que Nintendo tampoco estaba por la labor de licenciar cosas 2D, no hay fuente de esto, pero da la sensación de que si era algo en 3D te lo licenciaban aunque fuera malo (Superman 64, Daikatana, Carmagedon 64, etc), pero si era 2D subían el listón, lo que reduce los RPG todavía más porque muchísimos de esta época siguieron siendo en 2D (Suikoden, Arc the Lad, Alundra, SaGa, Vandal Hearts, Front Mission, Legend of Mana, Valkyrie Profile) porque, imagino, era más barato de desarrollar que hacerlos en 3D y como ya he dicho, los tiempos de desarrollo de un RPG son siempre más largos y costosos así que con el 2D economizaban. A veces hacían un combo 2D y 3D (Persona). Pero a esto, se añade que si bien el desarrollo 2D podía ser más barato, su traslado al formato físico de Nintendo 64 no, eso aceptando que cabiesen en 32-64 megas y alguien quisiera lanzar su juego a un PVP muy superior al resto del catálogo, porque evidentemente en cartuchos de menos de 32 no iban a entrar todos los 2D/3D que usaron fondos prerrenderizados (Star Ocean, Chrono Cross, Kouldeka, Parasite Eve, etc).

En definitiva, es un cúmulo de cosas, sin embargo sí podemos señalar que el primer RPG de PS1 en completo 3D poligonal que nos llegó a Europa se le puso mucho énfasis en los análisis de la época en indicar eso, que era 3D y por eso molaba, blablabla. El juego es Legends of Legaia.

Entonces tenemos que sí, mucho querer RPGs, pero cuando sale uno en 3D y no en 2D o con fondos, era algo llamativo para ese momento ¿Y quien tiene en su biblioteca un montón de RPG en 3D? Pasaron desapercibidos sí, pero ahí están y puede que Quest 64 no pueda compararse con un FF, pero su público era el infantil ofreciendo un RPG sencillo al nivel de Guardian's Crusader de PS1 por ejemplo y le puede plantar cara sin problemas. Uno muy olvidado, pero que técnicamente no hay nada igual a ello en PS1 es Aidyn Chronicles: The First Mage, un juego de mundo abierto donde ya puedes ver a los enemigos y decidir si luchar o no con ellos, el mundo tiene un ciclo de tiempo dia/noche que sino recuerdo mal afecta a las cosas, el combate está bien, pero se le criticó con razón que es bastante lento, pero acaso en PS1 los RPG que triunfaron eran todos combates rápidos? (Vagrant Story, Xenogears, Chorno cross, por ejemplo).

Al final lo que pasaba aparte de los costes, era que el marketing en PS1 hacía mejor su función de vender juegos y crear deseos de RPG, mientras que en N64 se enfocaba en vender FPS, plataformas y aventuras 3D, Star Wars, etc. Star Wars es un gran ejemplo de esto, PS1 tuvo bastantes juegos de la saga (todos peores que los de N64, pero es otro tema), pero como la publicidad se enfocaba en vender sobre todo lo que salía en N64 y no tanto en PS1 las ventas de Star Wars en N64 son buenas, no recuerdo el nombre del juego de lanzamiento de N64 de esta saga, pero tuvo muy buenas ventas, pese a competir con Mario Kart 64, Super Mario 64, Wave Race 64.

Ahí tienes un cúmulo de circunstancias y posibilidades que debes examinar juego a juego para ver cuales se le aplican.

Aparte de todo lo dicho por SuperPadLand, creo que el hecho de que la N64 fuera la tercera en ventas en Japón, y muy buenas ventas en USA y occidente, hizo que su catálogo fuera más hacia contentar los gustos occidentales, como le pasó a Mega Drive en la generación anterior.

Salud.

Otro punto de vista; los juegos poligonales con texturas repetidas pesan menos que los gráficos que necesitaban los RPGs; pero N64 estuvo enfocada a esos gráficos, y no podía disponer de una amplia variedad de texturas en sus juegos.

Un RPG hecho del mismo modo o directamente con el motor de Super Mario 64, igual podía acabar pareciendo más un juego de Net Yaroze que un RPG deseado, porque en esos juegos importa mucho más ver variedad y riqueza en los entornos, al tener que recrear vastos mundos con vida.

Hmmm.......... No sé, yo creo que los desarrolladores de RPG también apreciaban la facilidad de programar en la PSX y el tema del precio de los juegos, de los cartuchos, etc. Y no sé hasta que punto influiría esto:

[People who play RPGs are] “depressed gamers who like to sit alone in their dark rooms and play slow games.”

– Hiroshi Yamauchi in a 1999 interview

Pero eso de que no podían hacer muchas texturas diferentes... pues hombre, cuando veo los vídeos del Final Fantasy VII con el motor del Zelda, parece que cualqueir cosa es posible. Pero sí es cierto que muchos juegos de la N64 tienen texturas sorprendentemente simples e incluso el Ocarina es feo por momentos (ese bosque inicial).

PABEOL escribió:Bueno, pues queda claro que la Nintendo 64 podía hacer cualquier juego de la PSX (quitando escenas de vídeo y audio de calidad CD) y viceversa (bajando los polígonos).

Sin todos los post procesos, una nintendo 64 igual se te planta en 250k polígonos por segundo con el doble de memoria por textura, y con las ventajas de streaming del cartucho.

Comparado con los 80k/90k que puede mover la playstation, con texturas menores, y limitado únicamente a lo que te quepa en la ram, y ya... pues si, hay una diferencia.

Luego está la cpu, que para rematarlo podría ser fácilmente mas de tres veces mas potente, como comparar un 486 sx a 25mhz con un pentium 90.


Pentium 66 vs 486 DX5 133mhz
https://youtu.be/tm5lIQ_47Ko?t=591

Lo que en teoría podría ser en la práctica es difícilmente realizable.

La CPU de N64 es la misma arquitectura que la PSX (MIPS), y es de hecho 3 veces más potente y el RSP es equivalente al GTE pero el primero es programable. Pero dada la arquitectura de N64, en un juego normal la CPU está constantemente ociosa o sin posibilidad de acceder a datos. Ten en cuenta que la PSX puede lanzar el raster y mientras se está pintando todo puedes dejar que la CPU trabaje libremente en otra cosa, en la N64 mientras el raster pinta puede estar bloqueando el acceso a memoria de la CPU constantemente.
La N64 intenta mitigar varios de esos problemas con pequeñas memorias locales bastante más grandes que PSX (8k de cache de datos vs 1k, 16k de código vs 4k, 4k de textura vs 2k, +4k para el RSP), pero dado como prefiere los datos el RDP es bastante fácil salirse constantemente.

Para la transformación y proyección de vértices, aunque la PSX puede hacer proyecciones de 3 vértices en 21 ciclos de su reloj, en teoría la N64 es más capaz, pero otra vez en la práctica las cifras no son tan dispares, aparte del constante hándicap del acceso a memoria, la N64 delega a la CPU (normalmente al RSP) un trabajo que comúnmente se encarga al raster: el cálculo de los incrementos de un triángulo (esta parte en PSX la hace la GPU) y esto no es nada trivial, ahora mismo el código que uso para calcular los incrementos lleva ya varios intentos de optimización por la comunidad de Libdragon y está ahora mismo en unos 200 ciclos por triángulo (a esos ciclos habría que sumar los de la proyección normal). Siempre se pueden hacer optimizaciones específicas para cada proyecto pero eso da una idea del peso de calcular eso.

La diferencia de texturas no es tal, de hecho, es al revés la PSX puede usar texturas de 256x256. Para alguna demo técnica puede tener su uso, pero para escenarios reales eso da un poco igual en las dos consolas.

La desactivación de efectos para que parezca una PSX es una optimización que depende mucho del proyecto y en algunos casos hasta es contraproducente. Por ejemplo, en mi caso, con una escena sin Zbuffer tengo 20fps, si activo el Zbuffer con los polígonos de atrás para adelante tengo -3 frames, si los activo con los polígonos de adelante para atrás tengo +1.
Pero hay juegos documentados que tienen mejoras de rendimiento al desactivar el Zbuffer, el impacto depende mucho de cada proyecto.

Y sobre el streaming ya se habló antes, la n64 tiene lío de sobra con lo que tiene para aprovechar la velocidad extra que te da la ROM, incluso para la PSX el CD puede servir geometría y texturas más rápido de lo que un juego puede consumir. Accesos pequeño aleatorios a archivos, sí, eso le viene mejor a la N64, pero más que porque no entre en la RAM, es porque con los accesos pequeños a RAM en la N64 pierdes mucha eficiencia y además cargas el bus afectando a los demás componentes.

Aún así, es un escenario ideal donde el RDP moleste muy poco a la CPU puedes alcanzar 200000 polys/sec, creo que Kaze tenía una ejemplo de eso (una pared de una montaña o algo así). Pero usando la misma textura para todos, a 320x240, polígonos muy pequeños, con 0 overdraw (ningún polígono detrás otros), todos los polígonos mirando a la cámara para que no tengas que hacer back fase culling. sin ningún tipo de ordenamiento de polígonos, sin que la CPU haga ninguna otra cosa como colisiones, etc…

A nadie le ha dado por hacer un demo así en PSX, no creo que llegue a esas cifras, pero teniendo en cuenta que Spyro esta sobre los 100k triángulos por segundo a 512x240. Si bajas 320x240 y desactivas todo pues lo mismo te acercas bastante.

En términos de potencia bruta creo que la N64 es la más potente de esa generación, pero ni siquiera veo a la Saturn muy lejos.
Luego la N64 ofrece otras cosas que no son potencia bruta que habrían sido muy bienvenidas en otras plataformas. Como la corrección de perspectiva para poder poner polígonos gigantes cerca de la pantalla, la precisión subpíxel del raster para que la geometría parezca más solida, o el blending por hardware de los mipmaps.

Misscelan escribió:Lo que en teoría podría ser en la práctica es difícilmente realizable.

La CPU de N64 es la misma arquitectura que la PSX (MIPS), y es de hecho 3 veces más potente y el RSP es equivalente al GTE pero el primero es programable. Pero dada la arquitectura de N64, en un juego normal la CPU está constantemente ociosa o sin posibilidad de acceder a datos. Ten en cuenta que la PSX puede lanzar el raster y mientras se está pintando todo puedes dejar que la CPU trabaje libremente en otra cosa, en la N64 mientras el raster pinta puede estar bloqueando el acceso a memoria de la CPU constantemente.
La N64 intenta mitigar varios de esos problemas con pequeñas memorias locales bastante más grandes que PSX (8k de cache de datos vs 1k, 16k de código vs 4k, 4k de textura vs 2k, +4k para el RSP), pero dado como prefiere los datos el RDP es bastante fácil salirse constantemente.

Para la transformación y proyección de vértices, aunque la PSX puede hacer proyecciones de 3 vértices en 21 ciclos de su reloj, en teoría la N64 es más capaz, pero otra vez en la práctica las cifras no son tan dispares, aparte del constante hándicap del acceso a memoria, la N64 delega a la CPU (normalmente al RSP) un trabajo que comúnmente se encarga al raster: el cálculo de los incrementos de un triángulo (esta parte en PSX la hace la GPU) y esto no es nada trivial, ahora mismo el código que uso para calcular los incrementos lleva ya varios intentos de optimización por la comunidad de Libdragon y está ahora mismo en unos 200 ciclos por triángulo (a esos ciclos habría que sumar los de la proyección normal). Siempre se pueden hacer optimizaciones específicas para cada proyecto pero eso da una idea del peso de calcular eso.

La diferencia de texturas no es tal, de hecho, es al revés la PSX puede usar texturas de 256x256. Para alguna demo técnica puede tener su uso, pero para escenarios reales eso da un poco igual en las dos consolas.

La desactivación de efectos para que parezca una PSX es una optimización que depende mucho del proyecto y en algunos casos hasta es contraproducente. Por ejemplo, en mi caso, con una escena sin Zbuffer tengo 20fps, si activo el Zbuffer con los polígonos de atrás para adelante tengo -3 frames, si los activo con los polígonos de adelante para atrás tengo +1.
Pero hay juegos documentados que tienen mejoras de rendimiento al desactivar el Zbuffer, el impacto depende mucho de cada proyecto.

Y sobre el streaming ya se habló antes, la n64 tiene lío de sobra con lo que tiene para aprovechar la velocidad extra que te da la ROM, incluso para la PSX el CD puede servir geometría y texturas más rápido de lo que un juego puede consumir. Accesos pequeño aleatorios a archivos, sí, eso le viene mejor a la N64, pero más que porque no entre en la RAM, es porque con los accesos pequeños a RAM en la N64 pierdes mucha eficiencia y además cargas el bus afectando a los demás componentes.

Aún así, es un escenario ideal donde el RDP moleste muy poco a la CPU puedes alcanzar 200000 polys/sec, creo que Kaze tenía una ejemplo de eso (una pared de una montaña o algo así). Pero usando la misma textura para todos, a 320x240, polígonos muy pequeños, con 0 overdraw (ningún polígono detrás otros), todos los polígonos mirando a la cámara para que no tengas que hacer back fase culling. sin ningún tipo de ordenamiento de polígonos, sin que la CPU haga ninguna otra cosa como colisiones, etc…

A nadie le ha dado por hacer un demo así en PSX, no creo que llegue a esas cifras, pero teniendo en cuenta que Spyro esta sobre los 100k triángulos por segundo a 512x240. Si bajas 320x240 y desactivas todo pues lo mismo te acercas bastante.

En términos de potencia bruta creo que la N64 es la más potente de esa generación, pero ni siquiera veo a la Saturn muy lejos.
Luego la N64 ofrece otras cosas que no son potencia bruta que habrían sido muy bienvenidas en otras plataformas. Como la corrección de perspectiva para poder poner polígonos gigantes cerca de la pantalla, la precisión subpíxel del raster para que la geometría parezca más solida, o el blending por hardware de los mipmaps.

Gracias por el aporte

El tema de las resolución y rendimientos en N64 siempre se deja en un segundo plano, pero lo cierto es que cuando hice capturas nativas con un emulador para adornar mi blog me topaba con bastantes sorpresas, yo pensaba que la res interna sería siempre 320x240 con excepciones a 640x480, pero luego me salían cosas muy raras, montones de res no "estandar" inferiores a 320x240, si usaba modos hi-res subía, pero también se situaba en torno a los 320-360p. Pero cuando hablo de resoluciones raras, me refiero a que no eran ni siquiera números redondos acabados en cero sino 295x206 o algo así en F-Zero por ejemplo. Y había como una relación medio directa entre resoluciones bajas-mejor rendimiento vs resoluciones altas-peor rendimiento.

En PS1 tienes un dithering enorme, serruchos y toda la inestabilidad que quieras, pero montones de juegos tienen unas resoluciones envidiables para su época y funcionando a 30fps estables o casi estables y a veces incluso 60. Algunos que tengo anotados:*



etc.


Pero claro, la pregunta del millón es ¿Por qué apostar por estas resoluciones y no hacer como N64 e irse a 256x224 para mejorar la calidad 3D? No iba a alcanzar tampoco la calidad de N64, pero parece como contraproducente subir resoluciones en este caso ¿Le salía gratis o más fácil a PS1 subir la resolución que no mejorar la calidad gráfica aunque fuera a 224p? Supongo que los tiros van por ahí, porque en esa gen las revistas no indicaban nada de resoluciones a las que iban los juegos así que como marketing daba igual. Pero incluso sin mejorar la calidad 3D, no era mejor un Driver a 320x240 o 256x224 y con mejor rendimiento?



*Son anotaciones sacadas de un listado que hice, están sacadas de la difunta meristation que tenían un listado allí, a las que sumé otras fuentes que fui encontrando además de cosas probadas por mi. Puede haber errores por tanto, pero es una mera referencia.

Lo de la PSX yo creo que se explica con que era muy fácil de programar y luego, al ver cosas como el Ridge Racer Type 4, eso es el resultado de varios de los mejores equipos de programación del mundo centrados exclusivamente en un sistema durante 5 años. El Silent Hill tampoco creo que tenga muchos polígonos, pero sacaron fotos de un pueblo real para hacer las texturas y transformaron la niebla de "liability" en "asset".

SuperPadLand escribió:[

Pero claro, la pregunta del millón es ¿Por qué apostar por estas resoluciones y no hacer como N64 e irse a 256x224 para mejorar la calidad 3D? No iba a alcanzar tampoco la calidad de N64, pero parece como contraproducente subir resoluciones en este caso ¿Le salía gratis o más fácil a PS1 subir la resolución que no mejorar la calidad gráfica aunque fuera a 224p? Supongo que los tiros van por ahí, porque en esa gen las revistas no indicaban nada de resoluciones a las que iban los juegos así que como marketing daba igual. Pero incluso sin mejorar la calidad 3D, no era mejor un Driver a 320x240 o 256x224 y con mejor rendimiento?.

Me imagino que porque les sale gratis. La CPU y la GPU en PSX no se pisan los pies y trabajan independientemente.

Si por ejemplo, quieres hacer un juego a 30fps, la CPU y la GPU tienen que terminar el trabajo antes de 33ms. Si la CPU está tardando 32ms y la GPU 10ms quiere decir que puedes achuchar más a la GPU sin que afecte a la CPU. Esto es subir la resolución por ejemplo, si quieres más polígonos ya sería más trabajo para la CPU y te pasarías de los 33ms.

@Misscelan ojo, que el spyro tiene mucho gouraud.

Igual que el mario 64, aunque actualmente lo están optimizando y ya ronda los 60fps, ¿con 2000 polígonos por frame? (me suena que mas, pero no quiero decirlo muy alto).

Lo de la cpu ociosa... bueno, era esperable, aunque da lástima. En GC por suerte no es mayormente así, pero claro, asocio ambas arquitecturas, y luego te llevas estas sorpresas... pero digo yo que habrán situaciones en las que puedas hacer constar diferenciar esa superioridad de procesamiento mas allá de trabajar desde su caché.

¿No hay ram unificada en ps1?.

La sensación que da no es que sea culpa de la arquitectura, sino del tipo de ciertos componentes. La ram es la máxima culpable según entiendo de lo que os leo.

Si no fuera tan inconsistente podrías alternar entre cpu y gpu sin tanto input lag, por mucho que el mal endémico de la memoria unificada siga estando ahí. Algo paliaría.

En GC no es así, la RAM consta de dos módulos gestionados por el northbridge, que intuyo que en n64 esa gestión no es independiente, permitiendo a la cpu y a la gpu trabajando cada una en un sitio simultáneamente... a menos que por el motivo que sea necesites cambiar de banco y la sincronización no sea perfecta. Cuestión de programarlo bien, claro.


P.D:
Tu que sabes un huevo de gc... ¿te suena un email de factor 5 hablando de un port cancelado del rogue squadron 2 en xbox, hablando de cifras y rendimiento?.

Lo leí un vez, y no me lo guardé

Básicamente, mismos polígonos, 60fps en gc, 12fps en xbox.

Las mejoras de Kaze en el Mario 64, entre muchas era que conseguía meter todo el código en la caché de la CPU, para que no accediera a la RAM y me suena que WDC y los juegos de Factor5 hacen lo mismo o como mínimo intenta que acceda lo mínimo posible.
Luego la scene parece que las mejoras son más encaminadas a mejorar visualmente con efectos que conseguir una mejora sustancial del rendimiento, aunque por lo visto el F3DEX3 corrige un bug del RSP y tiene algo más de rendimiento.
Salud.

@Señor Ventura hay que ser muy inútil para portear cualquier juego de GC a Xbox y perder como un 85% de rendimiento. Salvo que fuera los primeros pasos del port a machete sin adaptar nada que en ese caso tiene bastante mérito que lo mueva a pelo sin más viniendo de otra arquitectura.

La entrevista que igual buscas es la de la Retrogamer UK número 168.

No dice nada de eso que comentas, lo que dice sobre Xbox es esto (tradu de GPT):

Increíblemente, los equipos de LucasArts estaban trabajando en un juego similar llamado Star Wars: Starfighter, pero no estaban al tanto del desarrollo de Rogue Leader. Cuando se enteraron, la fricción resultante puso en peligro todo el proyecto de Rogue Leader, como recuerda Julian. “Cuando se reprodujo el legendario tráiler en la presentación de GameCube, la mayoría de las personas en LucasArts se quedaron en shock”, explica. “Intentaron cancelar Rogue Leader para evitar que el juego eclipsara a Starfighter, y casi lo lograron debido a que Microsoft ofreció incentivos a LucasArts para trasladar Rogue Leader a la Xbox. Fueron cuatro desagradables meses de luchas políticas con nosotros en Factor 5, como socio tecnológico de Nintendo, atrapados en medio.”

Página 26.


También dice esto por si no era obvio:


Lo que no quita que en calidad/precio y por tanto mejor diseño la GC es infinitamente mucho mejor que Xbox que lo que vendieron fue un PC en un trasto enorme y megacaro. Si Nintendo diseñara la GC con el mismo PVP que salió Xbox a saber que bestia sacaba porque por 199$ saco una maravilla.

Edit: Y justo hoy aquí hemos hablado de como Wii dopa los juegos de GC si usas Nintendont y en ese vídeo puedes ver como Star Wars RL2 en GC va a 30-45fps no a 60: hilo_a-que-jugais-ahora-mismo-con-vuestra-cube_1049970_s2300#p1754946468

Es que no vas a ver 12 millones de polígonos en xbox con bump mapping y ese número de luces simultáneas (ya sea por vértice, o por pixel).

Julian no es ningún inutil, puede que no transladase completamente el rogue squadron a las particularidades de la xbox, pero doom 3 y riddick tienen un poly count bajo por un motivo (cuello de botella del bus, ineficiencia de sus memorias que lo desaprovecha aún mas, etc)... y 8 luces son dos pasos completitos, eso en gc no es así.

Ahora, aún con 12fps, el resultado visual debía ser mejor. Mejores texturas, mas nítidas, mejor bump mapping, mejor iluminación, audio 5.1 real, y no ese dolby 4.0 interpolado para sacar 5.1 de alguna manera...

Ya digo, me arrepiento muchísimo de no haber guardado ese email, daba unos cuantos detalles muy interesantes.

Señor Ventura escribió:Es que no vas a ver 12 millones de polígonos en xbox con bump mapping y ese número de luces simultáneas (ya sea por vértice, o por pixel).

Julian no es ningún inutil, puede que no transladase completamente el rogue squadron a las particularidades de la xbox, pero doom 3 y riddick tienen un poly count bajo por un motivo (cuello de botella del bus, ineficiencia de sus memorias que lo desaprovecha aún mas, etc)... y 8 luces son dos pasos completitos, eso en gc no es así.

Ahora, aún con 12fps, el resultado visual debía ser mejor. Mejores texturas, mas nítidas, mejor bump mapping, mejor iluminación, audio 5.1 real, y no ese dolby 4.0 interpolado para sacar 5.1 de alguna manera...

Ya digo, me arrepiento muchísimo de no haber guardado ese email, daba unos cuantos detalles muy interesantes.

No te digo ni que no ni que sí, sólo te digo que si hubiera un port de cualquier juego de GC a Xbox no hay ningún motivo para que funcione peor y no se vea mejor usando menos poligonos o magia borrás. Salvo que seas un inútil o que realmente sea lo dicho, un port por las risas sin adaptar nada.

Lo de meter más poligonos también lo hacía PS1 sino recuerdo mal y no por eso lucía mejor porque hay cosas que no puedes suplir ni imitar sólo por aumentar la carga poligonal. La Xbox caga por todas su compañeras de generación y le saca los colores en algunos aspectos todavía a Wii aunque a mi su catálogo sea el que menos me llame de todas.

Supongo que alguna mierda mal porteada a Xbox y bien a GC habrá, pero en general cuantos juegos hay multiplataforma que vayan claramente mejor en GC? Porque todos los que he examinado son siempre lo mismo: PS2 la peor versión, GC la intermedia y Xbox la experiencia VIP que sólo superaban los PC caros a veces con menos diferencias entre versiones y a veces con más. Pondrá más polígonos, no lo sé porque como Xbox no le importa a nadie la verdad que no hay demasiados analisis técnicos ni entrevistas a fulano famoso de la época que hizo juego muy querido y recordado hoy, etc. También es verdad que Xbox iba tan sobrada que no hay ninguna historia épica que contar sobre un port imposible o una creación de la quinta venida de cristo explicando como sorteaban carencias y grandes fallos de diseño como un soporte físico de tamaño reducido, falta de caches, memoria RAM unificada, etc. Como vendió una mierda ni siquiera tuvo la oportunidad de recibir ports downgrade de la siguiente gen, tiene el Farcry y no sé si alguno más.

Edit: Y te he escrito eso mientras juego a GameCube a Blood Omen 2, que no viene a cuento, pero para quien decía que en la sexta gen ya todo era perfecto y superado, este juego todavía usa control tanque.

gynion escribió:Entiendo que si a ti (o al bloguero) el contenido de FFVII no te gusta o te parece adorno puedas quitarlo como si nada, y que consideres que no se pierde gran cosa; es más, igual hasta te da igual que el juego entero no esté en N64, si tus gustos van por otro lado, cosa que desconozco, pero de momento ya sé que gran parte del juego lo esquilmarías sin dramas. En cambio, tanto los creadores de ese juego (por la entrevista, digo), como los jugadores a los que nos gusta, no pensamos igual. Ahora mismo no te puedo decir qué recortes toleraría yo en juegos que o bien no me gustan, o no me acaban de gustar; pero vamos, te puedes imaginar que igual que tú; serían varios y sin dramas

Por mi parte no es que el FFVII no me guste, es que no me llama. Ya jugué al VIII y dejé el IX a medias, y del VII me he comido ya no se cuantos spoilers super importantes, así que no me apetece tirarme 30 o 40 horas de tedioso combate por turnos. Y digo esto sin desmerecer que será un juegazo y que tiene su lugar en la historia del videojuego.
Del blogero no sé, pero creo que se lo habrá jugado y le gustará.

El caso sobre lo que cuentas de la historia y perder cosas. El juego que más me impactó por como se cuenta la historia es Max Payne. No es ningún alarde técnico, pero el rollo cine negro con los comics y tal está genial. Si ahora el juego se redujerá al mínimo sin comics ni voces y fuese solo párrafos de texto, pues evidentemente pierde bastante de esa ambientación y sería un bajón.

Ahora bien, lo fundamental: sería un bajón porque ya me conozco la historia de una manera.
Si hiciesen un remake del juego y sustituyesen los comics, por escenas brutales y fieles que mejorasen mucho esa sensación de cine negro etc, etc. Pues eso sería un subidón, comparado con el juego original.

La cuestión aquí es que por supuesto que habiendo salido el FFVII en 3 CDs cualquier port a N64 con algún sacrificio va a ser "inaceptable" para los fans. Pero si el caso fuese al reves, con un FFVII en N64 cambiando FMV por cinemáticas del motor del juego, menos variedad de escenarios, tal vez una o dos horas menos de juego por lo que sea, etc, pero que lograse mantener tanto la parte emotiva de la historia como la parte entretenida del gameplay y consiguiese complacer a los fans como la versión de PS1... En ese mundo paralelo un port de FFVII a PS1 con algunos extras evidentemente sería bien recibido, pero seguiría siendo el mismo juego.

El caso es que si Square hizo FFVI y anteriores en SNES y con cartucho y la gente alaba la historia y tal... Ese hipotético FFVII en N64 no debería ser muy diferente, pero aprovechando el 3D.

gynion escribió:Sobre lo del 64DD, pues si la prioridad de Nintendo era mantener el precio de la consola, y, como sugieres, situaron al lector CD como el factor más peligroso contra ese propósito, para acabar teniendo que tirar del 64DD para un juego que al fin y al cabo iba a ser exclusivo de N64 y podía ser cómo ellos quisieran, solo puedo pensar dos cosas: vaya cagada; y dos, si un juego se te queda corto, planteándolo desde cero, es que sí o sí necesitas el CD, igual que PC Engine lo necesitó (en realidad, solo necesitarían algo más tamaño que una hucard, pero no tuvieron miedo en usar el CD, que es a lo que vamos), para juegos de la generación anterior que ni siquiera eran de Neo-Geo, sino de una consola de 8 bits.

Esto es volver a lo que dije antes: de quedarse Square con Nintendo, el FFVII se habría diseñado de otra manera. De hecho en la entrevista aseguran que no sabian si situar el juego en Nueva York o algo así cuando aún estaban en Nintendo, y luego te dicen que siempre tenian en mente el CD... Sí, claro, no sabías qué hacer, pero ya sabías como hacerlo en la competencia... Es una de tantas por la que esa entrevista me parece un lavado de cara para ellos y ensuciar a Nintendo de paso.

Estoy seguro de que en Square sabian perfectamente las prestaciones de la nueva consola y estaban adaptadonse a usar un cartucho o diskette y el 3D. No estarian aspirando a más de lo que las especificaciones le permitian porque podrán ser muchas cosas, pero no eran, ni son, incompetentes en su trabajo. Es más, para ese fin compraron las estaciones Indy, para poder empezar a diseñar los juegos en N64 y hasta hicieron una demo de un combate con gráficos pre-renderizados.
Pero como dije, la N64 sufría continuos retrasos, el 64DD tenía una fecha indefinida de lanzamiento y los únicos ingresos de Square eran los juegos que salían en una SNES que ya estaba de capa caida. Hicieron lo que tuiveron que hacer para aguantar empresarialmente y se pasaron a Sony. Y no les culpo por ello.

Señor Ventura escribió:Si sustituyes una ram por otra físicamente exactamente igual, pero con mejores latencias, para los programas es exactamente igual, pero para el hardware además mejora el rendimiento.

¿Puede llegar a acelerar juegos?, o solo aumentar tasa de frames... pues depende del programa.

Pero en si, incompatibilidad de hardware, absolutamente cero mientras respetes el tipo de memoria, su disposición física, etc.

Hablamos de la ram de la n64 con otra exactamente igual, pero que siempre ofrezca tasas de transferencia cercanas a 500MB/s tanto con bloques grandes de datos, como con bloques pequeños de datos.

Pues oye, igual te casca un 25% mas de rendimiento, lo suficiente para que los juegos bloqueados a 30fps nunca bajen a 20, o 15fps. Ya es algo.

Me da que hasta me quedo corto.

Depende mucho de cómo trabaje la RAM y como esté hecho el controlador de memoria. Es muy posible que si metes una memoria con otra latencia, que no está por capricho, sin ajustar el controlador o sin que este se pueda adaptar al cambio, tengas corrupciones a cascoporro y no se pueda ejecutar nada.

@EMaDeLoC si cambiar la RAM a una mejor sin más funcionase sería la hostia, pero teniendo en cuenta que incluso los PC no soportan cualquier cambio a mejor si la placa no está diseñada para ello, lo dudo. La N64 no fue diseñada para actualizarse por componentes como un PC y lo dicho, aunque yo le meta a mi Pentium III una DDR3 no va a funcionar Pero, la misma memoria con un overclock del 10 o 20%? Eso podría funcionar no?

En realidad... ¿la misma memoria pero que no varíe la tasa de transferencia con bloques grandes como con bloques pequeños?.

Misma latencia, mismo tipo de memoria, pero siempre transfiriendo a 500MB/s hagas lo que hagas...

SuperPadLand escribió:Pero, la misma memoria con un overclock del 10 o 20%? Eso podría funcionar no?

El problema con la N64 es que tiene dos relojes que rigen todo. Uno para la CPU, que acelera el gameplay de los juegos sin mejorar framerate, y el otro que acelera RCP y RAM pero descoloca la salida de vídeo y por tanto se pierde imagen.

Señor Ventura escribió:En realidad... ¿la misma memoria pero que no varíe la tasa de transferencia con bloques grandes como con bloques pequeños?.

Misma latencia, mismo tipo de memoria, pero siempre transfiriendo a 500MB/s hagas lo que hagas...

Realmente siempre se está transfiriendo los datos a 500MB/s sean paquetes grandes o pequeños. El problema es que también la latencia es la misma con independencia del tamaño del paquete, 40 nanosegundos. Si se piden 256 bytes de datos, el paquete más grande que maneja la RDRAM, se tarda 40ns de latencia más 512ns de datos. Si se piden 4 bytes, el mínimo, se tarda 40ns de latencia y 8ns de datos. Si hacemos cuentas, en lo que se tarda en transmitir un paquete grande se pueden enviar 11'5 paquetes de los más pequeños, resultando en transmitir 46 bytes frente a los 256 bytes. La tranferencia de datos es la misma, la latencia es la misma, pero al hacerse varios paquetes pequeños, se multiplican las latencias, alargandose el tiempo en que se tranfieren datos pequeños y por tanto bajando la transferencia de datos efectiva.

La solución sin tocar nada es estructurar los datos en paquetes grandes para minimizar las perdidas de transferencia por las latencias. Siendo el máximo 256bytes, no es difícil, pero el problema con N64 es que muchos datos no llegan a ese tamaño y de hecho son muy pequeños. Creo, si no me equivoco, que las comparaciones de z-buffer se hacen pixel a pixel y son paquetes mínimos, lo que significa estar con la tasa de transferencia al mínimo, unos 90MB/s.

Trucos así a lo rápido que se me ocurren para optimizar la RAM con los gráficos:

• Poner los polígonos lo más horizontal posible (algún juego ya lo hace)
• Texturas de 4KB, o de 2KB con paleta y que todas compartan paleta (creo que son 256 colores, con algo de estilo es suficiente)
• No usar texturas, simplemente pintar vertices, para minimizar las lecturas. Juegos de primera hornada ya lo hacen
• Organizar los datos que necesite la CPU en paquetes de 256bytes y que así se transfieran rápido
• Ver vídeos de Kaze Emunar

EMaDeLoC escribió:El problema con la N64 es que tiene dos relojes que rigen todo. Uno para la CPU, que acelera el gameplay de los juegos sin mejorar framerate, y el otro que acelera RCP y RAM pero descoloca la salida de vídeo y por tanto se pierde imagen.

Señor Ventura escribió:En realidad... ¿la misma memoria pero que no varíe la tasa de transferencia con bloques grandes como con bloques pequeños?.

Misma latencia, mismo tipo de memoria, pero siempre transfiriendo a 500MB/s hagas lo que hagas...

Realmente siempre se está transfiriendo los datos a 500MB/s sean paquetes grandes o pequeños. El problema es que también la latencia es la misma con independencia del tamaño del paquete, 40 nanosegundos. Si se piden 256 bytes de datos, el paquete más grande que maneja la RDRAM, se tarda 40ns de latencia más 512ns de datos. Si se piden 4 bytes, el mínimo, se tarda 40ns de latencia y 8ns de datos. Si hacemos cuentas, en lo que se tarda en transmitir un paquete grande se pueden enviar 11'5 paquetes de los más pequeños, resultando en transmitir 46 bytes frente a los 256 bytes. La tranferencia de datos es la misma, la latencia es la misma, pero al hacerse varios paquetes pequeños, se multiplican las latencias, alargandose el tiempo en que se tranfieren datos pequeños y por tanto bajando la transferencia de datos efectiva.

La solución sin tocar nada es estructurar los datos en paquetes grandes para minimizar las perdidas de transferencia por las latencias. Siendo el máximo 256bytes, no es difícil, pero el problema con N64 es que muchos datos no llegan a ese tamaño y de hecho son muy pequeños. Creo, si no me equivoco, que las comparaciones de z-buffer se hacen pixel a pixel y son paquetes mínimos, lo que significa estar con la tasa de transferencia al mínimo, unos 90MB/s.

Trucos así a lo rápido que se me ocurren para optimizar la RAM con los gráficos:

• Poner los polígonos lo más horizontal posible (algún juego ya lo hace)
• Texturas de 4KB, o de 2KB con paleta y que todas compartan paleta (creo que son 256 colores, con algo de estilo es suficiente)
• No usar texturas, simplemente pintar vertices, para minimizar las lecturas. Juegos de primera hornada ya lo hacen
• Organizar los datos que necesite la CPU en paquetes de 256bytes y que así se transfieran rápido
• Ver vídeos de Kaze Emunar

¿Sería técnicamente posible enviar varios paquetes pequeños dentro de uno grande?... es decir, si fuese así ya se habría hecho, pero es la primera idea que te surge a la mente, ¿cual es el problema en este caso?.

P.D: He visto un vídeo de kaze emanuar enseñando un ejemplo a 300 mil polígonos por segundo xD
https://youtu.be/GC_jLsxZ7nw?t=6

EMaDeLoC escribió:Por mi parte no es que el FFVII no me guste, es que no me llama. Ya jugué al VIII y dejé el IX a medias, y del VII me he comido ya no se cuantos spoilers super importantes, así que no me apetece tirarme 30 o 40 horas de tedioso combate por turnos. Y digo esto sin desmerecer que será un juegazo y que tiene su lugar en la historia del videojuego.
Del blogero no sé, pero creo que se lo habrá jugado y le gustará.

Me trae recuerdos eso que dices de los combates por turnos, porque ya se comentaba en su momento; no me suena a crítica nueva. En mi caso, aunque es cierto que ahora ya es otra historia, y los juegos nuevos los prefiero un poco más dinámicos o tipo action RPG (antes del FVII mis referentes eran Illusion of Time y The Story of Thor), los de turnos clásicos nunca me han molestado especialmente. El rollo estrategia es algo que también me gusta.

EMaDeLoC escribió:El caso sobre lo que cuentas de la historia y perder cosas. El juego que más me impactó por como se cuenta la historia es Max Payne. No es ningún alarde técnico, pero el rollo cine negro con los comics y tal está genial. Si ahora el juego se redujerá al mínimo sin comics ni voces y fuese solo párrafos de texto, pues evidentemente pierde bastante de esa ambientación y sería un bajón.

Ahora bien, lo fundamental: sería un bajón porque ya me conozco la historia de una manera.
Si hiciesen un remake del juego y sustituyesen los comics, por escenas brutales y fieles que mejorasen mucho esa sensación de cine negro etc, etc. Pues eso sería un subidón, comparado con el juego original.

Sí, es lo que te decía, que cuando te gusta un juego y lo conoces, lo que para otros no es importante para ti sí lo es. De todas formas, Max Payne tiene una versión para GBA que no está nada mal. Un Max Payne para Nintendo 64 sí que lo veo, pese a ser de una generación posterior. Tirando de entornos 3D, y las cutscenes hechas rollo Perfect Dark, para mí que se podría adaptar muy bien a N64. Además de que encaja perfecto en la linea occidental de la consola.

EMaDeLoC escribió:La cuestión aquí es que por supuesto que habiendo salido el FFVII en 3 CDs cualquier port a N64 con algún sacrificio va a ser "inaceptable" para los fans. Pero si el caso fuese al reves, con un FFVII en N64 cambiando FMV por cinemáticas del motor del juego, menos variedad de escenarios, tal vez una o dos horas menos de juego por lo que sea, etc, pero que lograse mantener tanto la parte emotiva de la historia como la parte entretenida del gameplay y consiguiese complacer a los fans como la versión de PS1... En ese mundo paralelo un port de FFVII a PS1 con algunos extras evidentemente sería bien recibido, pero seguiría siendo el mismo juego.

El caso es que si Square hizo FFVI y anteriores en SNES y con cartucho y la gente alaba la historia y tal... Ese hipotético FFVII en N64 no debería ser muy diferente, pero aprovechando el 3D.

Claro, de hecho creo que a los fans más fans de una saga les gusta jugar a todas las versiones existentes, y saben apreciarlas de forma individual, según lo que le ofrezca cada máquina. En este caso, pese a los recortes y detalles, pues seguro que N64 podía ofrecer cosas que PS1 no, y cosas importantes, tratando de compensar lo que no podía. Para mí sería una estupidez despreciar cualquier versión de un juego que te gusta sin antes probarla al menos. No digamos ya especulando y sin que ni siquiera exista esa versión. La intención al comparar o hacer hipótesis no siempre implica rechazo a la versión que consideras peor (o como en este caso, estimo por mí parte que sería peor).

EMaDeLoC escribió:Esto es volver a lo que dije antes: de quedarse Square con Nintendo, el FFVII se habría diseñado de otra manera. De hecho en la entrevista aseguran que no sabian si situar el juego en Nueva York o algo así cuando aún estaban en Nintendo, y luego te dicen que siempre tenian en mente el CD... Sí, claro, no sabías qué hacer, pero ya sabías como hacerlo en la competencia... Es una de tantas por la que esa entrevista me parece un lavado de cara para ellos y ensuciar a Nintendo de paso.

Estoy seguro de que en Square sabian perfectamente las prestaciones de la nueva consola y estaban adaptadonse a usar un cartucho o diskette y el 3D. No estarian aspirando a más de lo que las especificaciones le permitian porque podrán ser muchas cosas, pero no eran, ni son, incompetentes en su trabajo. Es más, para ese fin compraron las estaciones Indy, para poder empezar a diseñar los juegos en N64 y hasta hicieron una demo de un combate con gráficos pre-renderizados.
Pero como dije, la N64 sufría continuos retrasos, el 64DD tenía una fecha indefinida de lanzamiento y los únicos ingresos de Square eran los juegos que salían en una SNES que ya estaba de capa caida. Hicieron lo que tuiveron que hacer para aguantar empresarialmente y se pasaron a Sony. Y no les culpo por ello.

Pues también veo posible que no mintiesen ahí. Había sistemas usando CD ya por esas fechas de SNES, mucho antes de salir PS1, e incluso Nintendo estuvo haciendo intentonas, como hemos ido comentando. Squaresoft trabajó intensamente para SNES por esa misma época. Es perfectamente posible, y tal vez probable, que en algún momento de esos, por ejemplo tras terminar el FFVI, pensasen que la futura sucesora de SNES iba a tener formato CD.

Puede ser que no mientan, y que el juego no fuese planteado para una PS1, sino para una N64 CD. Supongo que cabe la posibilidad de que antes de decidirse por el formato de N64, durante la gestación de ésta, Nintendo tuviera al menos alguna idea sobre las especificaciones de la consola y la compartiese con sus socios, para que empezasen a trabajar en las ideas antes de disponer de los kits. Una vez con los equipos de desarrollo listos, y sabiendo que el formato sería cartucho, igual ahí sí puede ser que los de Square actuasen como dices, y tuvieran clarinete de antemano lo de pasarse a PS1.

Tengo curiosidad si se podrá meter un expansión pack superior a 4mb y un lector de CD el la expansión del 64dd,, una N64 con mucha más RAM y lector de CD se podrían portar o mejorar todo tipo de juegos (como la snes con el msu-1 o los juegos de cartucho que están metiendo banda sonora de CD con la Megadrive+mega CD)

ziu escribió:lector de CD

https://en.wikipedia.org/wiki/Doctor_V64

riffraff escribió:

ziu escribió:lector de CD

https://en.wikipedia.org/wiki/Doctor_V64

Ostras! Podías ver videoCds y escuchar CDs, y no lo aprobecharon para juegos?

¿Quizás con un. Everdrive moderno se pueda tener un CD en la N64 con cargas rápidas y q la roms lo aprovechen para meter el audiocd o texturas con más calidad?

ziu escribió:

riffraff escribió:Ostras! Podías ver videoCds y escuchar CDs, y no lo aprobecharon para juegos?

¿Quizás con un. Everdrive moderno se pueda tener un CD en la N64 con cargas rápidas y q la roms lo aprovechen para meter el audiocd o texturas con más calidad?

Otras consolas menos potentes lo permiten, así que dudo mucho que la N64 no pueda:

Señor Ventura escribió:P.D: He visto un vídeo de kaze emanuar enseñando un ejemplo a 300 mil polígonos por segundo xD
https://youtu.be/GC_jLsxZ7nw?t=6

Ese es la escena de la montaña que comentaba en un post anterior. En ese vídeo hay un poco de picaresca.
La escena tiene 10000 triángulos, pero no se muestran todos de una vez, se acerca con un picado y luego cuando está cerca mira de izquierda a derecha. Que no quita que sea impresionante de cualquier manera.

Después también mira fuera de pantalla y dice que en ese caso se dispara a a 60 fps, como dando a entender que para la CPU está haciendo el trabajo total de calcular 10000 polys para mandar al RDP, pero el caso es que cuando un triángulo no se muestra en pantalla es obviamente menos trabajo para el RDP, pero también bastante menos para la CPU/RSP ya que después de calcular la proyección si el tríangulo queda fuera de la pantalla puedes abandonar cualquier proceso siguiente para ese triángulo, si está dentro de la pantalla te toca calcular los intervalos (eso que comenté arriba que en libdragon eran unos 200 ciclos).

He aprendido muchas cosas viendo sus videos que no sabía, pero siempre hay un punto un poco "sensacionalista" que me tira un poco para atrás.
J. Lambert (el de Portal y la demo de Megatexture) me parece más comedido en ese aspecto, y luego si tenéis Discord, y estáis interesados en el aspecto técino, en el N64Brew hay gente como Wiseguy (el que acaba de sacar lo de la static recompilation), HailToDodongo (el de Tiny3d) o Rasky (el que ahora mismo está haciendo más aportes a Libdragon) de los que se aprende mucho con solo leer sus comentarios. Y bueno, por aquí está Conker, (entre otros "sospechosos" habituales de este hilo) que aportó un montón de cosas a Libdragon cuando no era mainstream .

dirtymagic escribió:Las mejoras de Kaze en el Mario 64, entre muchas era que conseguía meter todo el código en la caché de la CPU

Supongo que eso se referirá a alguna parte crítica de código y no a todo? Los 16k de cache de código dan para unas 4000 instrucciones, eso para un proyecto del tamaño de SM64 es relativamente poco.

Una de las cosa que sirven para optimizar cualquier proyecto de N64 en términos generales, y que creo que no se ha comentado, es tener los buffers (color y zbuffer) en diferentes bancos de memoria (cada 1mb es un banco). Cada banco tiene una especie de cache que no utilizas si estás escribiendo constantemente en sitios diferentes del mismo banco, añadiendo latencia de acceso.

Otro práctica un poco más chapucera y limitante en lo artistico, es usar muy pocas texturas pero en blanco y negro y darle color através del coloreado de vértices, podría ser la misma textura para la hierba y la pared de una montaña y luego colorear los vértices de uno en verde y del otro en marrón. Esto no sé si me suena que lo usó Rare en algún proyecto.

Misscelan escribió:darle color através del coloreado de vértices, podría ser la misma textura para la hierba y la pared de una montaña y luego colorear los vértices de uno en verde y del otro en marrón. Esto no sé si me suena que lo usó Rare en algún proyecto.

Goldeneye por ejemplo usaba mucho esa técnica:
https://www.emutalk.net/threads/goldeneye-007.39165/post-366608
https://www.reddit.com/r/gamedev/comments/rhto3m/comment/hoszbtf/

riffraff escribió:

Misscelan escribió:darle color através del coloreado de vértices, podría ser la misma textura para la hierba y la pared de una montaña y luego colorear los vértices de uno en verde y del otro en marrón. Esto no sé si me suena que lo usó Rare en algún proyecto.

Goldeneye por ejemplo usaba mucho esa técnica:
https://www.emutalk.net/threads/goldeneye-007.39165/post-366608
https://www.reddit.com/r/gamedev/comments/rhto3m/comment/hoszbtf/

Si, algunos juegos de RARE, sobretodo GE, PD, BK, DK64 y BT usan muchas texturas en i4 y CI4 para luego colorear los vértices, luego estaban los que hicieron, DKR, JFG y MSR, que era todo lo contrario, mosaicos de varias texturas a 16bits,😅.

Salud.

Señor Ventura escribió:¿Sería técnicamente posible enviar varios paquetes pequeños dentro de uno grande?... es decir, si fuese así ya se habría hecho, pero es la primera idea que te surge a la mente, ¿cual es el problema en este caso?.

Si, es lo que he comentado antes:

EMaDeLoC escribió:La solución sin tocar nada es estructurar los datos en paquetes grandes para minimizar las perdidas de transferencia por las latencias.

Por ejemplo, agrupas la información de varios polígonos en una cadena y en un orden adecuado para meterlos en la cache del RSP.
La cuestión es si los microcódigos soportan este tipo de formatos o hay que hacer microcódigos a propósito. También depende del controlador de memoria. Y además el mayor paquete es de 256 bytes, para datos pequeños como vertices de triángulos puede servir para agrupar algunos, u otros determinados datos, pero no da para empaquetar cosas más grandes como texturas.

@gynion A ver, no está mal el combate por turnos, de hecho va muy bien para preparar una estrategia contra los enemigos. Pero los combates se hacen largos esperando que tus personajes cojan turnos, y sobretodo, que si tenías que ir de un punto a otro rapidamente, te comias 4 o 5 combates aleatorios y perdias 10 minutos o más.
Sobre Square, creo que el CD estaba descartado desde el principio del desarrollo de la consola. Empezó en 1993, cuando ya Nintendo había desechado la consola de Sony y los juegos en CD-i de Philips. Así que ya estaba bastante claro que el soporte sería un cartucho, y posiblemente también el 64DD.

Pero sí te compro que mientras todas las compañías estaban apostando por el CD, Nintendo fue la única que no, y Square y otros desarrolladores esperaban desarrollar los juegos en CD por el tema de costes de desarrollo y soporte. Pero insisto, no pongo el CD como el motivo principal del cambio de compañía.

ziu escribió:Tengo curiosidad si se podrá meter un expansión pack superior a 4mb

Supuestamente la scene consiguió meterle 12MB de RDRAM. De hecho en la base es sencillo: coges una consola con dos chips de 2MB de RDRAM, los cambias por dos chips de 4MB (se hace mucho para portabilizar consolas) y le insertas un expansion pak. Creo que es necesario modificar las librerias o crear software a propósito para poder ver los 4MB extras, pero funciona.
¿Utilidad? Ninguna. Si apenas hay juegos que usen el expansion pak, mucho menos los 12MB. Pero solo por poder hacerlo ya mola.

ziu escribió:

riffraff escribió:

ziu escribió:lector de CD

https://en.wikipedia.org/wiki/Doctor_V64

Ostras! Podías ver videoCds y escuchar CDs, y no lo aprobecharon para juegos?

¿Quizás con un. Everdrive moderno se pueda tener un CD en la N64 con cargas rápidas y q la roms lo aprovechen para meter el audiocd o texturas con más calidad?

Era un accesorio no oficial creado por terceros. De hecho Nintendo trató de tumbarlo legalmente y pudo hacerlo en algunos sitios. Pero no carga del CD directamente, la ROM grabada en el disco es cargada en una memoria interna y de ahí se carga en la consola como si fuera un cartucho. Los flascharts hacen lo mismo, pero en vez de CD es una tarjeta SD. En el caso de V64 la memoria es de 16MB, así que ciertos juegos ya no se pueden ejecutar. Después sacaron la versión jr. con más memoria pero sin lector que había que conectar directamente al PC para cargar juegos.


Al no ser oficial, tener los mismos límites de espacio efectivos que un cartucho y además estar Nintendo batallando legalmente, nadie le sacó un juego. Aunque aparentemente sí fue usado como alternativa a las estaciones Indy para desarrollar juegos en la N64.