Hilo de detalles y curiosidades de N64

@SuperPadLand Si te refieres a lo de tratar de hacer un GTA3 para N64... no se, Quizá pensandolo a fondo no sea tan imposible lograr algo SIMILAR, pero en vez de tratar de reducir GTA3 hasta que quepa en N64, puede que sea mas viable partir de alguna decompilación, si es que la hay o la llega a haber, de algún juego mas modesto de conducción en entorno abierto, y tratar de expandirlo.
Es que de GTA3 da la impresión de que habría que quitarle mucha enjundia para llegar a una base razonable para la máquina y luego tratar de reintroducir algunas cosas pero de forma simplificada y muy optimizada. Si partimos de algo que ya está a una escala mas asequible, solo hay que hacer lo segundo, o sea, añadir cosas.

E igual me equivoco, igual no sería tan terriblemente imposible calzar un GTA3 en N64, pero no da esa impresión a priori. Que se puede hacer un entorno abierto con vehículos y todo eso, sin duda que se puede, pero que sea precisamente un juego potente de la siguiente generación... suena a mucho pedir. De poderse hacer algo, creo que habría que recudir muchas cosas.

A la N64 la veo mas capaz de un Counter-Strike's que un GTA 3 .

radorn escribió:@SuperPadLand Si te refieres a lo de tratar de hacer un GTA3 para N64... no se, Quizá pensandolo a fondo no sea tan imposible lograr algo SIMILAR, pero en vez de tratar de reducir GTA3 hasta que quepa en N64, puede que sea mas viable partir de alguna decompilación, si es que la hay o la llega a haber, de algún juego mas modesto de conducción en entorno abierto, y tratar de expandirlo.
Es que de GTA3 da la impresión de que habría que quitarle mucha enjundia para llegar a una base razonable para la máquina y luego tratar de reintroducir algunas cosas pero de forma simplificada y muy optimizada. Si partimos de algo que ya está a una escala mas asequible, solo hay que hacer lo segundo, o sea, añadir cosas.

E igual me equivoco, igual no sería tan terriblemente imposible calzar un GTA3 en N64, pero no da esa impresión a priori. Que se puede hacer un entorno abierto con vehículos y todo eso, sin duda que se puede, pero que sea precisamente un juego potente de la siguiente generación... suena a mucho pedir. De poderse hacer algo, creo que habría que recudir muchas cosas.

Igual me expliqué mal, no digo de hacer un GTA III tal cual lo conocemos, sino un hipotetico what if de como sería si después de GTA 1 y 2 en PS1 y PC hubiesen decidido ya en ese momento hacer GTA 3D y hubiesen elegido para ello N64 como hizo Konami por ejemplo con los Castlevania Hasta donde podría haber llegado dicha adaptación poligonal, pero sabiendo que los dos primeros ya asientan unas mecánicas que son básicas de la saga hasta nuestro días y que por tanto tienen que existir en este what if 64 (robo de autos, tiroteos en las calles y un sistema de persecución policial según el grado de búsqueda). Existiendo Driver 2, no creo que en N64 sea imposible aspirar a menos, evidentemente como dijo emadeloc podemos partir de que existe Carmagedon como punto de partida o Body Harvest, etc.

doblete escribió:A la N64 la veo mas capaz de un Counter-Strike's que un GTA 3 .

Pues tiene una versión de Rainbow Six muy digna que soporte para multijugador a cuatro, en PS1 esta versión es deleznable incluso en single player y tuvieron que quitar el multijugador, ni siquiera a dos.

radorn escribió:@SuperPadLand Si te refieres a lo de tratar de hacer un GTA3 para N64... no se, Quizá pensandolo a fondo no sea tan imposible lograr algo SIMILAR, pero en vez de tratar de reducir GTA3 hasta que quepa en N64, puede que sea mas viable partir de alguna decompilación, si es que la hay o la llega a haber, de algún juego mas modesto de conducción en entorno abierto, y tratar de expandirlo.
Es que de GTA3 da la impresión de que habría que quitarle mucha enjundia para llegar a una base razonable para la máquina y luego tratar de reintroducir algunas cosas pero de forma simplificada y muy optimizada. Si partimos de algo que ya está a una escala mas asequible, solo hay que hacer lo segundo, o sea, añadir cosas.

E igual me equivoco, igual no sería tan terriblemente imposible calzar un GTA3 en N64, pero no da esa impresión a priori. Que se puede hacer un entorno abierto con vehículos y todo eso, sin duda que se puede, pero que sea precisamente un juego potente de la siguiente generación... suena a mucho pedir. De poderse hacer algo, creo que habría que recudir muchas cosas.

UNREAL.

Con sus reflejos, y su todo. Al rendimiento que sea, y a 640x480.

Que se vea un fotograma renderizado por la consola.

SuperPadLand escribió:gual me expliqué mal, no digo de hacer un GTA III tal cual lo conocemos, sino un hipotetico what if de [...]

Ah. Yo me lo tomé como referencia al port de GTA3 para Dreamcast que han publicado hace no mucho, hecho a partir de un código fuente que no se si se obtubo por decompilación o que se filtró el original.
En cualquier caso yo mismo pensé en esa posibilidad. pero claro, es un tanto... demasié.

Pero si, claro, Body Harvest, que era un desarrollo realmente de primera generación para la consola, deja claro que poder se podría hacer un freeroaming 3D con vehículos y combate y tal. Con las mejora de programación y compilado que existen ahora, y un cartucho con mucha ROM y quizá acceso a almacenamiento masivo, pues daría para mucho.
Sin duda se podrían superar los freeroaming de PS1 con creces. Si esa consola podía cargar dinámicamente trozos de un mundo abierto desde un CD 2X (150KB/s de velocidad punta, que rara vez se alcanzan en realidad), pues mucho mas con cartucho a no se si se habían mencionado unos 4.5MB/s por DMA, con tiempo de acceso nulo.
Y no se si ese límite de velocidad es inherente al bus PI (la interfaz de cartucho, para los que no lo sepan), o es una limitación de los chips ROM usados en los cartuchos originales y quizá un cartucho de emulación ROM moderno ("flash"), o un repro, puedan dar mayor rendimiento. No lo se, es especulativo.

Señor Ventura escribió:
UNREAL.

Con sus reflejos, y su todo. Al rendimiento que sea, y a 640x480.

Que se vea un fotograma renderizado por la consola.

Tienes un Perfect Dark ahí dándolo todo y en la época... A mí me llama más este que mil Unreal.

Sobre el GTA para la N64, la verdad es que el Carmageddon con un motor más actualizado podría valer perfectamente, añadiendo la opción de ir a pie, coger armas, añadir las misiones, la policía...

bluedark escribió:

Señor Ventura escribió:
UNREAL.

Con sus reflejos, y su todo. Al rendimiento que sea, y a 640x480.

Que se vea un fotograma renderizado por la consola.

Tienes un Perfect Dark ahí dándolo todo y en la época... A mí me llama más este que mil Unreal.

Sobre el GTA para la N64, la verdad es que el Carmageddon con un motor más actualizado podría valer perfectamente, añadiendo la opción de ir a pie, coger armas, añadir las misiones, la policía...

Perfect Dark tiene la fase en la ciudad que llueve y hay algún peatón que quita el hipo. Pero Unreal tiene entornos 3D enormes con bastantes enemigos muchas veces y no son enemigos PS1-style, los cabrones se mueven, buscan rodearte y esquivar tus ataques, etc. Las IA junto con las f´sicas comen bastantes más recursos que los gráficos, sólo hay que ver que PC necesitas para montarte una IA casera, tienes diferentes IA con más o menos capacidades y el salto en recursos a medida que la IA es mejor es tocho tocho. Y eso que hoy las IA se apoyan en GPU diseñadas para ello, pero en N64 todo eso iba a golpe de CPU (creo).

PS2 ya suda tinta para mover GTAIII, sobretodo cuando la lías y en un mismo sitio viene la ambulancia, la policía con todos los NPCs acumulados. (vivos y muertos)

Los modelados los vi en su momento y no eran tampoco para volverse loco, pero si que están muy por encima de lo que mueve la generación, en el orden de 800-3000, yo creo que no podría representarse sin pasar bastante la tijera.

Y luego está la distancia de dibujado y los mapas, llenos de geometría y altitudes, el motor tendría que ser muy bueno descartando caras para no desperdiciar fillrate.

Además de todo lo anterior creo que el engine también me preocuparía (era RenderWare?), la cantidad de memoria que crea y destruye, el peso en sí del programa, la CPU aunque es potente para su generación y normalmente desaprovechada sería interesante ver como se desenvuelve, recuerdo darle propiedades de tren al taxi y las colisiones de roce podían consumir bastante, los NPC no andan por toda la ciudad, se crean cerca del área del protagonista, con patrones muy previsibles, hay mucho engaño.

El juego sin emisoras de radio pesaba como 600MB, lo veo todo un poco improbable, adaptación si (juego de 0 que simula GTA3), pero port directo con recortes no.

En DS hay un buen ejemplo, el C.O.P Recruit, y aunque se ve genial las carreteras no parecen tener demasiados desniveles, como suele tener el GTA, así que es más fácil de gestionar la geometría, tampoco es que me haya mirado todos los mapeados del juego, lo tengo en DS y el primer mapa que juegas es ese, o la parte del parque, pero se entiende.


Yo creo que este si que te lo movería, a más resolución, con más efectos, pero no a 60fps como lo hace DS.

El vídeo es un poco mierder, pero tampoco veo otros que no sean emulados.

@Conker64 Sí, GTAIII usa un Renderware arcaico. Ya con el port de Dreamcast lo han tenido dificil para hacer la versión actual que, todo hay que decirlo, la han pulido lo suficiente como para haberlo lanzado comercialmente en su día, y más si la hubieran desarrollado desde DMA/Rockstar.
Creo que sin las emisoras de radio incluso pesa menos, unos 200-300 megas en su versión PC.

Ese COP Recruit de DS se ve impresionante! Me suena un juego parecido para PS1, pero éste era todo el tiempo en coche, sin opción a bajar e ir caminando.

Conker64 escribió:PS2 ya suda tinta para mover GTAIII, sobretodo cuando la lías y en un mismo sitio viene la ambulancia, la policía con todos los NPCs acumulados. (vivos y muertos)

Los modelados los vi en su momento y no eran tampoco para volverse loco, pero si que están muy por encima de lo que mueve la generación, en el orden de 800-3000, yo creo que no podría representarse sin pasar bastante la tijera.

Y luego está la distancia de dibujado y los mapas, llenos de geometría y altitudes, el motor tendría que ser muy bueno descartando caras para no desperdiciar fillrate.

Además de todo lo anterior creo que el engine también me preocuparía (era RenderWare?), la cantidad de memoria que crea y destruye, el peso en sí del programa, la CPU aunque es potente para su generación y normalmente desaprovechada sería interesante ver como se desenvuelve, recuerdo darle propiedades de tren al taxi y las colisiones de roce podían consumir bastante, los NPC no andan por toda la ciudad, se crean cerca del área del protagonista, con patrones muy previsibles, hay mucho engaño.

El juego sin emisoras de radio pesaba como 600MB, lo veo todo un poco improbable, adaptación si (juego de 0 que simula GTA3), pero port directo con recortes no.

En DS hay un buen ejemplo, el C.O.P Recruit, y aunque se ve genial las carreteras no parecen tener demasiados desniveles, como suele tener el GTA, así que es más fácil de gestionar la geometría, tampoco es que me haya mirado todos los mapeados del juego, lo tengo en DS y el primer mapa que juegas es ese, o la parte del parque, pero se entiende.

Yo creo que este si que te lo movería, a más resolución, con más efectos, pero no a 60fps como lo hace DS.

El vídeo es un poco mierder, pero tampoco veo otros que no sean emulados.

En otras palabras, un driver+ si, un gta3- no.

Conker64 escribió:PS2 ya suda tinta para mover GTAIII, sobretodo cuando la lías y en un mismo sitio viene la ambulancia, la policía con todos los NPCs acumulados. (vivos y muertos)

Los modelados los vi en su momento y no eran tampoco para volverse loco, pero si que están muy por encima de lo que mueve la generación, en el orden de 800-3000, yo creo que no podría representarse sin pasar bastante la tijera.

Y luego está la distancia de dibujado y los mapas, llenos de geometría y altitudes, el motor tendría que ser muy bueno descartando caras para no desperdiciar fillrate.

Además de todo lo anterior creo que el engine también me preocuparía (era RenderWare?), la cantidad de memoria que crea y destruye, el peso en sí del programa, la CPU aunque es potente para su generación y normalmente desaprovechada sería interesante ver como se desenvuelve, recuerdo darle propiedades de tren al taxi y las colisiones de roce podían consumir bastante, los NPC no andan por toda la ciudad, se crean cerca del área del protagonista, con patrones muy previsibles, hay mucho engaño.

El juego sin emisoras de radio pesaba como 600MB, lo veo todo un poco improbable, adaptación si (juego de 0 que simula GTA3), pero port directo con recortes no.

En DS hay un buen ejemplo, el C.O.P Recruit, y aunque se ve genial las carreteras no parecen tener demasiados desniveles, como suele tener el GTA, así que es más fácil de gestionar la geometría, tampoco es que me haya mirado todos los mapeados del juego, lo tengo en DS y el primer mapa que juegas es ese, o la parte del parque, pero se entiende.

Yo creo que este si que te lo movería, a más resolución, con más efectos, pero no a 60fps como lo hace DS.

El vídeo es un poco mierder, pero tampoco veo otros que no sean emulados.

Interesante, de todas formas por GTA III no me refiero a port del de PS2 sino a como hubiese sido si el tercero de la saga saliese en 1998-2001 para N64 directamente y pensando en adaptarlo al 3D como era habitual en esa época con sagas 2D. Por ejemplo la altitud de GTA en PS2 en N64 podría ser menor una ciudad ambientada en plan México DC (creo que es esta ciudad) que es muy extensa, pero hay mucho edifico de 2-3 plantas. Y tampoco hay que descartar usar popping a lo loco y a dos pasos como Driver que lo disimula con el fondo 2D, pero no está tampoco renderizando nada bestial. De hecho veo que usa bastante los edificios de las calles no alineados de forma que la mitad de los edificios disimulan su popping siendo tapados por otros que tienen la fachada más cerca de la acera, la otra mitad es popping puro y duro: https://www.youtube.com/watch?v=qhdKYL8Of_U

Otro juego ejemplo de mapa grande o ciudad es Simcity64, el juego de 64DD.
Puedes hacer zoom hasta pasear por las calles. Teniendo en cuenta que la ciudad es diferente según el usuario y que la optimización esta complicada, no se mueve mal.



Evidentemente un GTA 64 sería mucho más simple que el de PS2, y de hecho se echa en falta cualquiera de los dos primeros, ya que su vista 3D cenital y sprites los movería la N64 con bastante soltura.

EMaDeLoC escribió:Otro juego ejemplo de mapa grande o ciudad es Simcity64, el juego de 64DD.
Puedes hacer zoom hasta pasear por las calles. Teniendo en cuenta que la ciudad es diferente según el usuario y que la optimización esta complicada, no se mueve mal.

Evidentemente un GTA 64 sería mucho más simple que el de PS2, y de hecho se echa en falta cualquiera de los dos primeros, ya que su vista 3D cenital y sprites los movería la N64 con bastante soltura.

Este es uno de los pocos que no pude probar en el flashcard chinorro porque daba error.

@Señor Ventura
Bueno el caso es que GTAIII ya es trabajar a gran escala, 32MB de RAM (en PS2), puede que entre la carga del binario, variables, estructuras y los diferentes buffers de memoria que crea / destruye de forma dinámica ya se coman la mayoría de RAM disponible en N64, y ni has empezado a meter gráficos, sonido ni nada.

Mi sospecha es que igual te quedarías corto antes de ni siquiera empezar el proyecto.

@SuperPadLand
Yo creo que lo más parecido al 3 hubieran sido los ejemplos que ya han puesto, el Carmageddon 64, el Body Harvest...

Quizás un Vigilante 8 más orientado a ciudad?


Ahora viéndolo con perspectiva se podría hacer algo más avanzado.

Con altitud me refería al terreno, si te fijas en el vídeo del Driver 2 parece una pista de aterrizaje, todo llano, los edificios al final son como muros y dentro o detrás de ellos no hay nada, luego tienes parques con terreno desigual, pero son como piezas de lego, como el que usa el editor de Tony Hawk y pone una pieza por otra.

Luego claro que habrá alguna inclinación, alguna cuesta, un puente, manzanas, incluso se ve una autopista con distintos caminos e inclinaciones (creo que es lo más avanzado que he visto en ese vídeo), pero todo eso también forma parte de ese puzzle bien medido y diseñado en forma de cuadrícula para requerir lo mínimo.

En el caso de GTA3 te ponen un escenario 3D y el motor lo gestiona, puedes explorar los huecos, meterte donde no debes, y seguirá estando todo modelado y con colisiones para que puedas moverte, lleno de carga innecesaria pero en una generación con potencia de sobra.

En realidad no es muy distinto a Goldeneye, en el sentido de que también hicieron los escenarios sin tener muy claro lo que iba a pasar en ellos, podías moverte y explorar, incluso en partes que no servían para nada, dando ese aire fresco de libertad.

@Conker64 me suena que en Driver 1 había ciudad de San Francisco con sus pedazo cuestas, pero no estoy 100% seguro si era ese juego. De todas formas como esto es un what if de haber creado el primer GTA 3D en N64 antes de existir PS2 podemos aceptar que sería 99% llano. No es lo que más me importaría (los 2D son llano también) me preocupa más que haya un tráfico y peatones decentes además del sistema de la policia si incumples la ley. Bueno y que los coches tienen que dañarse, sacar fuego cuando vayan a explotar y que exploten

Anda, el Vigilante 8. Creo que ese no me di cuenta de comprobarlo cuando empecé a darme cuenta de que los juegos en alta resolución entrelazada (480i, 576i) no renderizaban a escala 1:1 con la pantalla.
Podría ser que efectivamente este si que haga 480 reales en FB, por lo mucho que ralentiza a veces.

@radorn
He encontrado 2 capturas en mi cuenta, las pondría en algún sitio pero no encuentro donde, supongo que son extracciones con el plugin angry lyon, había que poner el código MAX_RESOLUTION, por defecto no te deja alcanzar esa resolución, según marca si todo es correcto 639x474:

@Conker64 "el código MAX_RESOLUTION"? donde? en el juego? es algo del emulador/plugin?

En fin, aunque 639x474 numéricamente no es 640x480, lo importante es si el mapeado a pantalla es 1:1 o estirado por VI, por eso suelo insistir tanto en esa terminología del 1:1 (pixels FB a pixels pantalla). Siendo números tan cercanos, no creo que se pusieran a hacer estirados sin sentido. Mostrarán esos pixels en pantalla sin estirar por VI, como muchos juegos 240p que no llegan exactamente a 240 en el FB.

Pues, gracias por desenterrar esas capturas. Parece claro el diagnóstico.
Es posible que V8 sea de los pocos o el único juego 640x480 1:1.
Sería interesante saber si PAL mantiene esta tradición y hace 576p 1:1 o estira los casi 480 hasta casi 576

Conker64 escribió:@radorn
He encontrado 2 capturas en mi cuenta, las pondría en algún sitio pero no encuentro donde, supongo que son extracciones con el plugin angry lyon, había que poner el código MAX_RESOLUTION, por defecto no te deja alcanzar esa resolución, según marca si todo es correcto 639x474:

Hostias, que si hay 480p en n64 xD (internamente, que es lo que cuenta si se habla de músculo).

Según el youtuber, video en hardware real capturado desde s-video.


Es bastante sorprendente lo bien que se mueve teniendo en cuenta la resolución.

@EMaDeLoC

This is a capture of the hidden ultra resolution mode in Vigilante 8 on the Nintendo 64. This is not an emulator. This footage was captured directly from my Nintendo 64 using an actual Vigilante 8 cartridge.

"hidden ultra resolution mode", debe ser eso a lo que se refería @Conker64 con lo del "código"
No recordaba yo algo así.

radorn escribió:@EMaDeLoC

This is a capture of the hidden ultra resolution mode in Vigilante 8 on the Nintendo 64. This is not an emulator. This footage was captured directly from my Nintendo 64 using an actual Vigilante 8 cartridge.

"hidden ultra resolution mode", debe ser eso a lo que se refería @Conker64 con lo del "código"
No recordaba yo algo así.

En 0:25 puedes ver como mete el código.
Luego en 1:40 cambia la resolución de normal a high y luego ultra.

En un comentario hacen entender que sería necesario el expansion pak para que funcione el código de alta resolución.
No recordaba este juego, la verdad. Es básicamente un Twisted Metal...

También está su segunda parte "Vigilante 8 2nd Offense" y también tiene código de alta resolución: GO_MAX_REZ

Me suena que @Conker64 ya analizó esos modos de alta resolución hace años ¿Puede ser?

A mí me sorprende lo bien que se ve y sobretodo lo fluido que va, en otros juegos al activar el modo alta resolución se resentía el framerate y en el vídeo se ve fluido, a lo mejor al ser un port de ps1 al tener menos carga puede permitirse el modo hirez?

@Segastopol
Supongo que no le supone una bajada de rendimiento notable el subir la resolución , por como renderiza el juego el terreno, donde texturiza a pocos metros del jugador y el resto es gouraund, eso ahorra fillrate, que es donde más corto se quedaba esa generación de PSX,SS y N64.

Salud.

@dirtymagic El fillrate es pintar un pixel en el framebuffer. No importa si es gouraud, textura o sprite, pintar el pixel cuesta lo mismo.
Otra cosa es que el gouraud ahorre ancho de banda de RAM al no cargar textura o se procese más rápido, siendo más óptimo.
Según aquí, la consola tiene un fillrate de 62 megapixels/s de 15bits. Eso le da que teoricamente puede pintar 200fps de 640x480. Evidentemente eso no ocurre, y me temo que los datos de esa página tanto de la N64 como de las otras consolas son límites teóricos en situaciones muy favorables.

dirtymagic escribió:@Segastopol
Supongo que no le supone una bajada de rendimiento notable el subir la resolución , por como renderiza el juego el terreno, donde texturiza a pocos metros del jugador y el resto es gouraund, eso ahorra fillrate, que es donde más corto se quedaba esa generación de PSX,SS y N64.

Salud.

Sí, pero aun así es soprendente que funcione a 480p y con un rendimiento decente. En PS1 los juegos 640x480 eran puzzles o de lucha texturizando nada o lo mínimo, aunque a su favor iban a a 30 o 60fps. Si no recuerdo mal esto iba a 640x480x60fps:


Y la secuela a 640x480x30:


Esto sería otro de los 480x60fps:


Que ni tan mal que conste, pero el Vigilante 8 ofrece escenarios abiertos y explorables, con su cámara, varias IA rivales,físicas, explosiones, edificios, etc. Lo veo mucho más exigente a mi parecer. También salio en PS1 por cierto, aquí comparativa:

@EMaDeLoC La cuestión es que le cuesta menos pintar un polígono con gouraud que uno texturizado,y que ese puede ser la razón de que no vaya tan justo de fps en comparación de otros juegos cuando se sube la resolución, en N64 aparte de la secuela, sólo me suena que use esta forma de renderizar el escenario el SW: Battle of Naboo, con menos resolución, aunque más alta que el estándar de la consola y con bastante más profundidad.
La tabla que has puesto, me la tomaría con cautela, los datos que muestra me parecen demasiado optimistas en general y en SS en particular .

Salud.

La tabla de segaretro es pedirle una carta a los reyes magos.

Por ejemplo habla de bitmap framebuffer, tile fillrate, sprites o tilemap y aunque N64 no tenga un motor 2D, porque usa rectángulos, rellena igualmente de información esa tabla.

Y sin salir de esos apartados:
15-bit color/pixel - 62 MPixels/s
8-bit color/pixel - 120 MPixels/s
4-bit color/pixel - 250 MPixels/s

Ahí se da a entender que la profundidad de las texturas tiene un impacto tremendo.

Sobre esto ya puse ejemplos comparando texturas de 4, 8 y 16bit, la diferencia era mínima, a favor de 4bit si se usa en tamaño extra horizontal, pero si recarga mucho la paleta puede que sea contraproducente, más en 2D donde se cargan cientos, menos en 3D donde hay muchas menos, la de 8bit requiere un uso inteligente, de recargar solo la textura y que todas usen una paleta compartida de 256 colores, mientras que la de 16bit sigue siendo rápida y sin darle demasiado a la cabeza, porque lo que te dan las texturas paletizadas, te lo quitan restando tamaño del cache con la paleta.

Lo que de verdad podría cambiar el rendimiento es usar el modo COPY, 4 pixel por ciclo, o no usar el Z-Buffer (aquí pintas el doble), luego por supuesto hay parámetros que suman o restan, pero no tan cruciales como estos 2.

Si Vigilante 8 usara flat en las superficies más lejanas podría usar FILL (y hasta quitar Z), luego goraud (1CYCLE) y luego texturizar, todas tienen impacto en el rendimiento, viendo los resultados en alta resolución creo que lo hacen bastante bien.

@SuperPadLand
Si mal no recuerdo los Tobal son 512 de ancho.

PD: Que le pasa a EOL con los login? Si cambio de la torre al portátil me desloguea de un sitio y viceversa, ya lleva unos meses así, es alguna nueva medida de seguridad?

Conker64 escribió:La tabla de segaretro es pedirle una carta a los reyes magos.

Por ejemplo habla de bitmap framebuffer, tile fillrate, sprites o tilemap y aunque N64 no tenga un motor 2D, porque usa rectángulos, rellena igualmente de información esa tabla.

Y sin salir de esos apartados:
15-bit color/pixel - 62 MPixels/s
8-bit color/pixel - 120 MPixels/s
4-bit color/pixel - 250 MPixels/s

Ahí se da a entender que la profundidad de las texturas tiene un impacto tremendo.

Sobre esto ya puse ejemplos comparando texturas de 4, 8 y 16bit, la diferencia era mínima, a favor de 4bit si se usa en tamaño extra horizontal, pero si recarga mucho la paleta puede que sea contraproducente, más en 2D donde se cargan cientos, menos en 3D donde hay muchas menos, la de 8bit requiere un uso inteligente, de recargar solo la textura y que todas usen una paleta compartida de 256 colores, mientras que la de 16bit sigue siendo rápida y sin darle demasiado a la cabeza, porque lo que te dan las texturas paletizadas, te lo quitan restando tamaño del cache con la paleta.

Lo que de verdad podría cambiar el rendimiento es usar el modo COPY, 4 pixel por ciclo, o no usar el Z-Buffer (aquí pintas el doble), luego por supuesto hay parámetros que suman o restan, pero no tan cruciales como estos 2.

Si Vigilante 8 usara flat en las superficies más lejanas podría usar COPY (y hasta quitar Z), luego goraud (1CYCLE) y luego texturizar, todas tienen impacto en el rendimiento, viendo los resultados en alta resolución creo que lo hacen bastante bien.

@SuperPadLand
Si mal no recuerdo los Tobal son 512 de ancho.

PD: Que le pasa a EOL con los login? Si cambio de la torre al portátil me desloguea de un sitio y viceversa, ya lleva unos meses así, es alguna nueva medida de seguridad?

Acabo de mirar y Tobal 640x480, Tobal 2 son 512x480, pero según mis notas ambos son 60fps y no 30 el segundo como puse. Vamos que la he liado parda con mi post anterior. Aun así esto son mis notas y pueden estar mal

Sean 640 o 512 no son malas cifras para PS1 y usan muy inteligentemente la no texturización para que encaje. Aunque como digo Vigilante 8 es un pasó más allá porque lo veo más complejo y en PS1 no sé la resolución no lo tengo en mi lista, pero supongo que será 320x240.


A tu PD, acabo de loguearme en el móvil conectándome por datos para no usar el mismo wifi y no me desloguea ni nada. De hecho en el móvil no me tuve que loguear pese a venir del PC. Pregunta en feedback a moderación o mira las opciones de perfil si hay alguna de seguridad o así para que sólo haya una sesión activa.

Hostias la gráfica esa xD

16 mil sprites la sega saturn. Por lo ya expuesto me da a mi que planos infinitos aparte la que mas 2D puede renderizar es la n64.

Los datos de SEGA Retro son menos confiables que Trump, si son los que yo recuerdo haber leído, era incluso superior a N64. Como explicó Misscelan y otros muchos, si tú coges los datos de los cálculos que cada procesador puede hacer por separado y los sumas sí, pero es que ya está de sobra comentado y explicado y analizado y demostrado en su época y con homebrew que Saturn no es la suma de sus partes sino más bien la resta de ellas.

No sé porque les cuesta tanto admitir que si yo tengo cuatro repartidores de pizza y una sola moto para todos ellos, mi capacidad de entregar pizza es una de cada viaje no cuatro. Los tres ociosos podrán ayudar a cargar y descargar la moto más rápido y poco más, no es tan difícil de entender.

Siganme para más explicaciones técnicas demostrando mi completa unitilidad para ello, pero usando comida. Viva la pizza.

SuperPadLand escribió:Perfect Dark tiene la fase en la ciudad que llueve y hay algún peatón que quita el hipo. Pero Unreal tiene entornos 3D enormes con bastantes enemigos muchas veces y no son enemigos PS1-style, los cabrones se mueven, buscan rodearte y esquivar tus ataques, etc. Las IA junto con las f´sicas comen bastantes más recursos que los gráficos, sólo hay que ver que PC necesitas para montarte una IA casera, tienes diferentes IA con más o menos capacidades y el salto en recursos a medida que la IA es mejor es tocho tocho. Y eso que hoy las IA se apoyan en GPU diseñadas para ello, pero en N64 todo eso iba a golpe de CPU (creo).

Me suena de leer en alguna revista de hace mil años, que en su epoca, empezaron a desarrollar unreal para psx, pero lo abandonaron por que la consola era a todas luces insuficiente.
Yo de psx no digo nada, porque es evidente que no da, pero ojo, una n64 haciendo streaming de un cartucho de 128mb no lo veo nada descabellado, si es verdad que los 8mb de ram se pueden quedar cortos (teniendo en cuenta que en ps2 va perfecto con 32mb) no se, me haria gracia verlo, la verdad

Señor Ventura escribió:Por lo ya expuesto me da a mi que planos infinitos aparte la que mas 2D puede renderizar es la n64.

De "aparte" nada. Ya que el VDP2, que es el que genera el 50% de una escena 2D en Saturn, se encarga también de los planos de fondo clásicos, no sólo de los "Modo-7" like.

Por ejemplo en un plataformas 2D el VDP-2 te puede calzar:

- 4 planos de fondo totalmente escalables/rotables (de hacer falta).
- Un plano frontal para marcadores.

Dejando todo el fillrate del VDP1 para "sprites". Luego poca broma la Saturn. Para las 2D su tasa de relleno es VDP1+VDP2, la cual combinada iguala a la de N64. En 2D. Para el 3D es la peor porque en la práctica sólo cuenta la del VDP1, aunque puedas hacer "ñapas" con fondos 2D (Virtua Fighter 2, Last Bronx).

Potencialmente aquí la que se queda última es PlayStation.

Pero una Saturn + 4MB de RAM extra VS Nintendo 64 + 4MB de RAM extra y ROMs de 64MB se tutean.

@Sexy MotherFucker ya solo los 4KB de caché de texturas, que sin mip mapping ni nada mas que una textura plana sin filtrar ni postprocesar, me ofrece dudas a esa afirmación. Usas dos polígonos para una textura que necesitas dividir en varios trozos en máquinas con cachés inferiores, y varias veces mas polígonos, o quads, que en la de nintendo.

4 planos en n64 tendrían que ofrecer mucho detalle para obligar a la n64 a no construirlos con, literalmente, 8 polígonos (no digas nada, no es literal), y reservar todo el potencial para todo lo demás. Y luego su cpu, su ram ampliada con un ancho de banda mayor que el de cualquier otra ampliación de cualquier otra máquina... no se, no se.


P.D: Por cierto, ¿no se ha dicho que oficialmente el expansion pack añade 4MB, pero que podría ampliarse con una cantidad abusrdamente mayor?.


Si te apetece hablar de saturn, usemos su hilo para que no nos digan nada, así me informo, porque hay cosas que no me cuadran... pero esta noche trabajo, y es fín de semana, así que no se si me dejarán tiempo para descansar, o que.

Soy batman.

Sexy MotherFucker escribió:Pero una Saturn + 4MB de RAM extra VS Nintendo 64 + 4MB de RAM extra y ROMs de 64MB se tutean.

En Saturn estarías añadiendo 4MB de Work RAM, pero en N64 estás metiendo 4MB de memoria unificada.

En N64 esa RAM puede servir para todo, sin tener que empezar a montar sistemas sofisticados, o hacer transferencias y desperdiciar ancho o ciclos, o toparte con techos como la VRAM dedicada y sus posibles limitaciones, todo lo que ve disponible, todo puede ir a pantalla.

Saturn si mal no tengo entendido es incluso más enrevesada con diferentes tipos de RAM principal, 1MB de memoria rápida, donde pones código y todo lo crucial, y 1MB de memoria más lenta, donde almacenas lo menos crítico.

Si alguien tiene datos de tests reales en condiciones reales de la VDP1, como cuantos sprites mueve, idénticos / únicos, tamaño de los mismos, (de VDP2 ya me hago una idea) podemos extender el debate, pero por lo menos en el tema memoria/cartucho/cpu, N64 es idónea para 2D, ni mejor ni peor, te lo va a dar todo.

Lo único es que no es un hardware específico 2D, lo cual es menos purista, y por eso una saturn o una jaguar son otro rollo, pero la n64 si parece la mejor máquina para 2D. Ya de dreamcast hacia adelante no tiene ningún sentido mencionarlas.

@Conker64
Luego está que no tengo tan claro que el VDP pueda ponerse a manejar 4 planos, y que el VDP1 no se resienta cuando tienen que compartir buses y todo el rollo. Si es que si, es que si, pero sin saber, diría que tiene que afectar.

@Señor Ventura
Claro, ahí empezaría el debate, al final un juego es la unión de muchos apartados y no puedes contar con 1 solo, puede que todo el rendimiento se vaya al garete a la que empiezas a poner código, o la combinación de muchas texturas, o los efectos o transparencias.

Saturn es todavía peor, es como un bicho raro, no tenía misscelan algunas demos en ella? Estoy buscando por ahí opiniones de diferentes desarrolladores indie, a ver que es lo que se cuentan y hay de todo:

I'm not clear on the actual speed of the VDP1. An old Sega tutorial lists an equation to approximate the cycles it takes for the VDP1 to draw something, but if I assume the 28.6 million cycles from the main clock and 16x16 sprites, I get something ridiculous, like ~4 MPixel/sec. Using no textures and very large sprites (to reduce memory read and VDP1 setup overhead), I got up to ~10 MPixel/sec, the last time I checked the equation. This is disturbingly low and yet it jibes in with the few developers who commented on how slow the VDP1 is compared to the PSX (which has a theoretical peak of 33MPixel/s, and some demos have done ~24MPixel/s in practice).
I also don't know if that equation takes 8bit or 16bit sprites into the equation.

Por supuesto siempre te vas a quedar lejos del pico teórico, al final la cuestión es cuanto, y bajo que condiciones.

@Conker64
Voy un poco pillado de tiempo, para responderte sobre el tema del fillrate aquí va un poco más de info. Me he leído un poco por encima los últimos posts así que casi seguro que me he perdido algo por el camino.

Los números teóricos como siempre hay que cogerlos con muchas pinzas. En Ps1 está el ejemplo ese de las bolas rebotando, si no recuerdo mal eran sprites de 16x16 y cuando llegaba sobre las 2000, la cosa empezaba a bajar de los 60 fps, lo que en este caso daría cerca de unos 29M pixels por segundo (este número ahora me suena muy alto tendría que probar esa demo otra vez).

El mismo ejemplo se intentó replicar en Saturn y creo que no llegaba a 800 bolas, lo que pondría al VDP1 en unos 13M de pixels por segundo.

La n64, si no recuerdo mal, pusiste un ejemplo que habías probado tú en real hardware que era de un Sprite de 16x32 y salían como 1100 que salen como 34M.

En estos 3 ejemplos además se usan “sprites” y las 3 consolas tienen un “fast-path” en el raster para ese tipo de paquete. Todo esto está lejos de los escenarios reales…

En Saturn (y la 3do), al mapear usando “forward” va recorriendo todos los texels a la hora de rasterizar, así que al contrario de PS1 y N64 que usan “inverse” y recorren el polígono, el tamaño de texturas penaliza más que el tamaño de polígonos (al revés en PS1 y n64). Por esa razón hacer downsampling en Saturn, tiene poco efecto (salvo que actives la función HSS que hace que se salta uno de cada dos pixels cuando tiene que hacer downsampling). Además tiene el problema añadido del malgaste de fillrate cuanto más oblicuo es el polígono.

Pero ahí se acaban los problemas de Saturn y empiezan los problemas de las otras dos.
Para el VDP2 podrías usar dos planos a la vez (otra vez estoy hablando de memoria pero no tengo tiempo para checkear), y estos planos podrían tener resoluciones de 704x480 @ 60fps, así que usando dos tendrías otros 40M de pixeles. Tanto el VDP1 y VDP2 tienen su VRAM dedicada y sus andaduras no tienen implicación en buses de la CPU u otros componentes.

Además, ahora entramos en el tema de caches. Cuando la texturas dentro de un juego empezasen a variar (ósea usar diferentes texturas), la balanza se va a ir decantando del lado de Saturn. La Saturn no tiene cache de texturas pero sirve a la misma velocidad que la PS1 cuando si tiene la info dentro de la cache.
Aquí quería puntualizar que las caches de PS1 y N64 tiene un funcionamiento diferente. La cache de N64 está dividida en 4 bancos, cada banco tiene su información compartimentalizada y cada banco se puede acceder simultáneamente. Puedes poner por ejemplo datos de color en 2 bancos, y el CLUT en otro, pero no puedes juntar en un mismo el CLUT y los datos.

La PS1 mueve los datos de VRAM a cache por líneas, no mueve la textura entera, por eso puedes renderizar texturas de 256x256 aunque la cache sea de 2k (y la CLUT se almacena fuera de esa cache). La penalización por no tener una línea en cache y tener que bajar a VRAM es del doble de velocidad. Y eso era el pan nuestro de cada día, ya que con el algoritmo del pintor no puedes asegurar la repetición de texturas.

En n64 una perdida de cache texture, es mucho más crítica que en los otros sistemas y la cuantía de la pérdida depende de muchos factores.

Así que como mencioné antes, la Saturn recuperaría buena parte de esas pérdidas iniciales a medida que los juegos usasen más texturas y esta tirase del VDP2.

Los números teóricos son mejores que no tener nada, pero rara vez se pueden extrapolar a situaciones reales. Al final se pueden encontrar ejemplo donde un sistema se impone sobre otro y viceversa. Y es lo bonito de esa generación que son sistemas muy diferentes.

@Misscelan
Ok, sin prisa , cuando tengas tiempo sería genial saber esos detalles o más que conozcas, al final no por compararlas, como dices hay muchos matices y lo que importa es lo que cada una aporta dentro de sus peculiariades, pero por mera curiosidad.

El test de las bolas supongo que texturizadas? También se me antoja alto, en el caso de Saturn más en la línea de lo que esperaba, quizás incluso más bajo viendo tests de chillywilly.

Sí, el ejemplo que puse es uno del Mario de 16x32x16bit, en realidad monté unos cuantos y todos los resultados de la lista (sacada del SDK oficial) encajan y son fiables:


En todos los resultados es subiendo una única textura a cache durante todo el test.

Le pasé a Krom el código de uno de estos test de fillrate que hice, lo convirtió en ASM para PSX y el resultado era como un 30% inferior, de eso ya hará unos años, pero más o menos la idea iba por ahí, siendo Saturn un total desconocido.

Luego tenemos lo que ya se sabe en N64, dibujar a lo ancho, es más rápido que a lo largo, una vez llegados a 1cycle algunos efectos extra no tienen demasiado impacto, por ejemplo la libdragon antigua tenía mal configurado el color combiner y todas las superficies eran "ligeramente semitransparentes", me frotaba las manos, y luego el rendimiento era prácticamente el mismo sin transparencia.

Las transparencias no son nada trivial en PSX y en Saturn si no estoy equivocado.

Para los planos está lo que dices, en N64 mejor montar una estrategia de recarga de texturas, las ganancias son enormes, y las capas a poder ser optimizadas, simular planos sin usar toda la pantalla o con huecos en aquellas partes que van a ser tapados.

.

@Conker64

En Saturn estarías añadiendo 4MB de Work RAM

En realidad es RAM "genérica" para lo que te de la gana, situada en un pool por la zona del cartucho de expansión, que está totalmente alejado de la verdadera work-ram de 2MB que se aloja al lado de los SH-2, de los cuales Saturn se reserva 512kb para el sistema.

Se usó siempre para almacenar datos graficos y/o de sonido (samples).

Por ejemplo en X-Men VS Street Fighter se utiliza principalmente para mantener 4 personajes en memoria para poder intercambiarlos en combate, con todos los frames de animación, detalle, etc. Además de también para reducir los tiempos de carga:

[/url]


Que es algo que en PlayStation con su único 1MB de Vram no se pudo conseguir, teniendo que optar por eliminar el modo TAG y conformarse con un "striker", además de verse recortadas muchas animaciones.

Luego en títulos como Cotton 2:




La RAM extra se utiliza para guardar samples y frases habladas que no caben en los 512kb originales disponibles para sonido, ya que al no tener el Yamaha de la Saturn capacidad para comprimir/descomprimir datos, esta memoria rendía muy poco. Hay que decir no obstante que en la scene actual ya hay drivers para hacerlo por software

Por lo demás como ya ha comentado @Misscelan en otras ocasiones el VDP-2 se reserva 512kb para sus fondos (y creo que algo de caché en su interior), mientras que el VDP-1 se reserva 512kb exclusivos para el framebuffer, y otros 512kb para "sprites", todo en bancos de 256kb.

@Señor Ventura atiende a los datos que arroja este hombre sobre el VDP-2 de la Saturn, que es el factor que equilibra la balanza en 2D. Por supuesto son máximos teóricos, pero sirven, junto a los juegos existentes, para hacernos una idea general. Ambos VDPs tienen sus propios buses y memorias, sólo se estorban para las transparencias, y al final toda la imagen la enlaza el VDP-2 a la pantalla juntando los FB sin mayor problema. Los que sí se estorban de verdad son los SH-2 en su acceso a la misma RAM por el mismo bus.

Yo no opino que Saturn sea mejor que N64 para las 2D.

Lo que opino es que la Nintendo 64 tampoco es necesariamente mejor que Saturn, por lo que yo he jugado.

N64 diría que tiene ganada la batalla de las transparencias, que aunque posibles en Saturn, siempre las usará en contextos mucho más limitados, estorbándose fondos con "sprites":



Además que el uso del color combiner dispara las posibilidades en Nintendo 64.

Ahora; ¿En temas de planos de fondo, escalados, rotaciones de sprites, y en general "Traya" en pantalla? Sinceramente ahí tengo serias dudas:



Saturn es mucha Saturn para las 2D, está diseñada por y para éllas de base.

Para las 3D en cambio no hay mucho debate xD

@Sexy MotherFucker Solo hablo en base a percepciones, y ya sabemos que es lo que las percepciones son...

Mi impresión si es esa, que hay contextos y contextos para las 2D. Varios planos en "modo 7" hasta el horizonte con mucho detalle y mucha variedad de "tiles", es algo que tendrías que resolver en n64 con muchos polígonos para que cada uno tenga todas las texturas necesarias, y si encima hay que hacerlo con vario planos... para mi, ahí diría que saturn se queda sola de forma insultante.

Por otro lado, precisamente lo de rotar y escalar, con planos sin perspectiva, muchas animaciones... mucha cpu... no se, n64 me parece superior a todo lo anterior a ella (y ya digo, de dreamcast hacia adelante ya ni merece la pena decir nada).


Pero que ni idea, solo son impresiones de vuestras impresiones xD

@Señor Ventura si el caso es que en este asunto tengo tanta curiosidad cómo tú, con la diferencia de que yo ostento experiencia real con videojuegos 2D de todas las nombradas

Por ejemplo le di como cajón que no cierra a Yoshi's Story, y filtros aparte no vi nada que no pudiese parir una PlayStation...

Con el NBA: Hang Time me dio la sensación de que la N64 iba muy sobrada, que apenas estaba calentando.

El único título 2D que me ha sorprendido técnicamente en Nintendo 64 es Bangaioh! Y sus cientos de partículas con colisión:



Lo que tengo claro es que el BRONCE es de PlayStation, muy honroso eso sí.

Sexy MotherFucker escribió:Ahora; ¿En temas de planos de fondo, escalados, rotaciones de sprites, y en general "Traya" en pantalla? Sinceramente ahí tengo serias dudas:

Para esto si puedo ayudarte..

He buscado el sprite sheet del Mago y le he pasado una herramienta de auto cropping, no ha encontrado un sprite superior a 64x64, además, son de una profundidad de 4bit (16 colores), con lo que caben en la cache de texturas de N64.


Luego he hecho lo mismo con el resto de muñecos y si que he encontrado alguno que supera en ancho/largo 64, pero no por mucho, sería obligatorio usar el truco de más de 2KB para texturas paletizadas, empezar a recurrir a tamaños exóticos, o adaptar esos pocos pixeles de diferencia, usar más de un rectángulo por sprite lo dejaría solo como última opción.

Las batallas parecen de 100 soldados por bando, se pueden mezclar, funciona como un tablero, hay como un número de slots limitado a cada espacio, cuando entra uno, sale otro, así que está todo más o menos controlado, hay 3 slots reservados para el plano más cercano, y son del doble del tamaño original, podrían ser rectángulos escalados aproximados a 128x128.


Hay un tamaño superior al doble, pero suele pintarse solo parte de la cabeza y no estorba a la cámara.

El tamaño original se sitúa más o menos donde la imagen, por el centro de la pantalla, entre la cuarta/quinta fila, así que todo lo que hay detrás son tamaños menores, he estado deslizando vídeos de youtube de horas, para ver que pasa en las batallas y hay tendencia a pelear en el fondo, no en el plano más cercano.

El suelo es un plano abatido, a veces con detalle, a veces patrones repetitivos o previsibles, en el caso de un patrón repetitivo sería tan solo necesaria una superficie gigante configurada con la textura en modo repetir en N64, cuando llevan dibujo ya habría que darle más a la cabeza, se podría seguir pintando un patrón repetitivo y por encima superficies pequeñas como jardines, o combinar superficies grandes con pequeñas con corrección de perspectiva en un suelo más complejo, no tiene porque ser una cuadricula al estilo PSX.

El fondo, es un layer incompleto, normalmente ocupa una pequeña porción en el tope de la pantalla, además hay árboles, columnas y otros detalles por los escenarios, ni el suelo, ni el fondo me preocupan, los mapas que he visto son bastante sencillos.

Se añaden los 2 líderes, la habilidad de poder lanzar magias y otros detalles, que podrían ser perfectamente 50 sprites más de tamaño variable, se suman OSD, vida, marcadores..

Ahora es cuando entran no los números teóricos, los de rendimiento real, la tabla que has visto más arriba.

1) En base al tablero, no pueden llegar a verse los 100 soldados de un mismo equipo de forma simultánea, me salen unos 54 en formación, pero podrán mezclarse con los del equipo rival, aunque entran y salen en una serie de patrones, para que la base permita más enemigos en pantalla hay que alejar la cámara, con la misma disposición, con lo cual cada vez se alivia más el tamaño de los sprites al fondo, se ven más, pero ya se sabe lo que estas maquinas mueven a 16x16, los que me preocupan son los de la 5 fila en adelante, hay que sumarles la sombra.

2) El batallón es formado por el mismo soldado, además muchos coinciden con el mismo sprite, y el set es bastante limitado, la probabilidad de mantener en cache la misma textura es muy elevada, no veo necesidad de Z-buffer en ningún caso, y hasta la forma en la que se mueven podría ser intencionada para mantener a raya el número de recargas en N64.

En mi opinión, podría moverlo a 60fps salvo que fueran 100 soldados diferentes (1 recarga de 64x64 por muñeco) o si aparecieran los 200 en pantalla, junto con magias y efectos, pero por lo que he comprobado no parece el caso.

Si te refieres a otros juegos haciendo buen uso de VDP2 en combinación con VDP1 quizás obtengas cosas impensables en 2D, tal y como comentas es una maquina bien diseñada para ello.

------

@Sexy MotherFucker
He estado mirando el tema de la RAM:

- Cuando me refería al tipo de memoria no excluía lo que podrías usar en Saturn, simplemente me refiero a que vas a añadir memoria de tipo "Work RAM", es importante matizar, porque si comparas directamente con N64 no es el mismo tipo de expansión, en N64 realmente estás duplicando el mismo tipo de memoria, no añades memoria de otro tipo.

- La expansión de memoria es por el puerto del cartucho, por el Bus A (16bit), el bus no delimita o por lo menos no entorpece del todo la velocidad, sino el tipo de memoria usada en la ROM/RAM del cartucho de expansión, según leo los cartuchos AR suelen funcionar a un timing 1/4 de la velocidad de la RAM, con acceso preferible a cada 15 ciclos.

- La memoria RAM principal está separada en 2 pozos, WRAM-H (bus 32bit) es 1MB de memoria rápida, compartida con otros recursos, en principio el SDK oficial reserva unos 512KB de esta memoria para librerías y otros recursos, esto es flexible, podrías liberar lo que creas oportuno, WRAM-L es 1MB de memoria más lenta, pero reservada solo para los SH2, aquí la estrategia es cargar el código / variables en la memoria rápida y el contenido menos crítico en el pozo lento, si lo haces al revés hay penalización de rendimiento.

- Con esto dicho entra en juego la expansión de memoria, no vas a querer usar código de importancia en la RAM de expansión, que irónicamente es lo que se ha mal entendido de mi respuesta, sino justo lo contrario, esa RAM se va a emplear como almacenamiento de gráficos y sonidos, más sprites, más sonidos, cargar el set completo de animaciones de un personaje, disminuir los tiempos de carga..

Tal y como dices:

or ejemplo en X-Men VS Street Fighter se utiliza principalmente para mantener 4 personajes en memoria para poder intercambiarlos en combate, con todos los frames de animación, detalle, etc. Además de también para reducir los tiempos de carga

- Pero vamos a matizar, los VDP no pueden acceder directamente a esa memoria, acceden a su memoria local (VRAM) y en el caso de VDP1, además, a los framebuffer, tienes un diagrama oficial (y ojo que contiene errores, es maravilloso)

en otras ocasiones el VDP-2 se reserva 512kb para sus fondos (y creo que algo de caché en su interior), mientras que el VDP-1 se reserva 512kb exclusivos para el framebuffer, y otros 512kb para "sprites", todo en bancos de 256kb

Realmente no se reserva nada, reservar es tener 4MB de memoria unificada y querer usar 512KB para algo en concreto, aquí tenemos bloques de memoria dedicada.

- VDP1 tiene 512KB para texturas/sprites, y 2 bloques de 256KB para framebuffer
- VDP2 tiene 512KB para tiles

Luego podemos hablar de registros, pequeñas memorias o cache, o el sonido que funciona en un sistema aparte.

- Cuando añades 4MB de memoria extra no estás ampliando esa capacidad de VDP1 o VDP2 para "ver" más gráficos, simplemente le das un medio de almacenamiento mucho más rápido que el propio CD y te permite cosas como los ejemplos que bien has puesto.

- Si quisieras usar la RAM extra en tiempo de ejecución tienes que instruir al SH2 o bien al SCU para transferir datos al pozo de VRAM en cuestión, eso tiene impacto en todo el sistema, eso requiere estrategia, eso requiere duplicar de datos en un lado y otro, tendrás sprites repetidos en Work RAM y en VRAM, y no estarás usando el 100% de la memoria en material único, salvo que crees y destruyas, más movimiento.

- En el caso de N64 es sencillo: funciona diferente, le das 4MB más de lo mismo, no tiene que transportar memoria a ningún lado, solo a la cache de texturas, así que los limites de fillrate que antes tenías, los sigues teniendo, con la diferencia es que vas a poder coger más "de aquí y allá" sin tener que hacer nada, a eso me refería que la maquina te lo dará todo.

* Tienes que poner un nuevo personaje en el combate? Me alegro, ponlo, no tengo un pozo limitado de 512KB, tengo 8MB continuos de memoria, y esto ayuda enormemente en las 2D.

Sé que es sacar punta, pero bueno por ello estamos en un hilo técnico

@Conker64 no sé si tu o @misscelan podríais decir como quedaría PS1 si tuviera que recibir un port de Dragon Force. Siempre han puesto ese juego como ejemplo de manejo de Sprites de Saturn y es cierto que maneja una burrada, pero la mayoría son idénticos como has dicho e igual eso permite alguna adaptación digna en PS1 aunque sea bajando a 80 o 90 Sprites por ejemplo

@SuperPadLand
Son 54 soldados, salvo que alejes la cámara, yo creo que en condiciones ideales, entre los de un bando y el otro igual se te juntan unos 70 en pantalla como mucho, luego suma la sombra 70*2, 140, la sombra es sin salir del proceso de pintado, inviertes y coloreas a negro, suma contadores, magias, escenario y demás, igual te vas a 200, de esos 200 si haces la media hipotética de todos los tamaños igual te sale 36x36, o algo menos, aunque tampoco la cosa se contabiliza así.

Y eso en batallas de 100 soldados por equipo, que te van a durar varios segundos esos 200 en acción, puede que cuando empiecen a juntarse ya sean bastante menos, y luego van cayendo, al final hablamos más sobre si podrían mantener 60fps en todo momento, si solo cayera un par de segundos por batalla tampoco sería un drama.

En N64 ten en cuenta que el máximo teórico empieza a caer a la mínima que haces algo diferente a pintar, si recargas textura es tiempo que el chip gráfico no pinta, no solo textura, también paleta, la música, la CPU y el RSP también pelean por trabajar ahí, al final no puedes dibujar esos 1140 sprites a 60fps de 16x32 en condiciones reales, bajará poco si hay buen desarrollo detrás, mucho, si se hacen mal las cosas.

Pero en este caso en particular, al usar todos el mismo sprite set beneficia a N64.

PSX no pinta tanto en bruto como N64, recargar textura también le duele, pero quizás no tanto, el audio, y otros procesos no entorpecen tanto como en N64, el plano abatido sí, le va a costar más hacerlo, así que es una mezcla de cosas.

En este caso en particular, si N64 va muy justa, PSX rascará en los mismos momentos, no veo indicios de que PSX pueda hacerlo mejor.

Por otro lado si quieres beneficiar a Saturn tienes que usar los 4 planos del VDP2, o irte a dibujar en alta resolución con ese chip, además de exprimir como un limón VDP1, a poder ser con sprites diferentes, un plano abatido (simple) y medio layer de fondo no son suficientes.

Conker64 escribió:@SuperPadLand
Son 54 soldados, salvo que alejes la cámara, yo creo que en condiciones ideales, entre los de un bando y el otro igual se te juntan unos 70 en pantalla como mucho, luego suma la sombra 70*2, 140, la sombra es sin salir del proceso de pintado, inviertes y coloreas a negro, suma contadores, magias, escenario y demás, igual te vas a 200, de esos 200 si haces la media hipotética de todos los tamaños igual te sale 36x36, o algo menos, aunque tampoco la cosa se contabiliza así.

Y eso en batallas de 100 soldados por equipo, que te van a durar varios segundos esos 200 en acción, puede que cuando empiecen a juntarse ya sean bastante menos, y luego van cayendo, al final hablamos más sobre si podrían mantener 60fps en todo momento, si solo cayera un par de segundos por batalla tampoco sería un drama.

En N64 ten en cuenta que el máximo teórico empieza a caer a la mínima que haces algo diferente a pintar, si recargas textura es tiempo que el chip gráfico no pinta, no solo textura, también paleta, la música, la CPU y el RSP también pelean por trabajar ahí, al final no puedes dibujar esos 1140 sprites a 60fps de 16x32 en condiciones reales, bajará poco si hay buen desarrollo detrás, mucho, si se hacen mal las cosas.

Pero en este caso en particular, al usar todos el mismo sprite set beneficia a N64.

PSX no pinta tanto en bruto como N64, recargar textura también le duele, pero quizás no tanto, el audio, y otros procesos no entorpecen tanto como en N64, el plano abatido sí, le va a costar más hacerlo, así que es una mezcla de cosas.

En este caso en particular, si N64 va muy justa, PSX rascará en los mismos momentos, no veo indicios de que PSX pueda hacerlo mejor.

Por otro lado si quieres beneficiar a Saturn tienes que usar los 4 planos del VDP2, o irte a dibujar en alta resolución con ese chip, además de exprimir como un limón VDP1, a poder ser con sprites diferentes, un plano abatido (simple) y medio layer de fondo no son suficientes.

¿Entooooonces?... ¿cual escel veredicto?.

Señor Ventura escribió:¿Entooooonces?... ¿cual escel veredicto?.

N64/Saturn >>> PlayStation >>> Jaguar >>> PC-FX/3DO

2D.

En 3D:

- Model 3 > NAMCO System 23 >>> Konami TOP >>> Taito Top >>> MIDWAY Top >>> Model 2 > Cualquier tarjeta de PC desde la Verite1000 (Septiembre de 1996) ≥>> Nintendo 64 >>> PlayStation >>> Saturn.