Saturn era más potente que psx?

Dudeman Guymanington escribió:¿Alguien conoce algún sitio en el que se recoja el número de polígonos en distintos juegos de PS1? Estoy en el móvil, pero la última vez que lo busqué no encontré nada.

Lo busqué bastantes veces, pero no encontré nada. Encuentras pequeñas reviews de algún juego concreto suelto y ya.

De hecho intenté localizar en youtube un análisis de Silent Hill que mostraba los pol/frame y framerate, etc. Y ya no lo encontré.


Edit: Por cierto, por una vez estoy de acuerdo con @Bullrun no veo porque Medievil no podría ser llevado a Saturn con un resultado final bueno, adaptado a sus características claro (tramas para trasparencias, mejores fondos 2D que podría incluso ser animados, etc).

@SuperPadLand
En el hilo de curiosidades de N64, @Conker64, pone capturas del polycount de varios juegos de PSX, Silent Hill me suena que ponía ~4.000 polígonos por frame, en la cutscene de la cafetería, eso sí, no a 30Fps.

Salud.

@dirtymagic sí, me suena que andaba en 4000-5000 por frame, pero oscilando entre 18 y 25fps en PAL que imagino serán 20-30 en NTSC. Lo que me gustaría es que alguien analizase la zona del parque de atracciones porque es donde el juego asfixia por completo y creo que se mueve a 10-15, pero es una escena que no veo el motivo de esas bajadas porque es la zona donde menos se ve y lo poco que renderiza nunca me pareció más cargado que las calles de la ciudad.

@SuperPadLand
Utiliza iluminación por vértice con la linterna, tal vez meta más geometría de lo que parece, para que la iluminación sea más suave y realista.

Salud.

@dirtymagic sí, eso lo sé; pero la iluminación por vértice está presente tanto en el parque de atracciones como en otros lugares del juego.

La zona es esta:


Es de las más vacías y sencillas del juego o al menos es la sensación que da.

SuperPadLand escribió:@dirtymagic sí, me suena que andaba en 4000-5000 por frame, pero oscilando entre 18 y 25fps en PAL que imagino serán 20-30 en NTSC. Lo que me gustaría es que alguien analizase la zona del parque de atracciones porque es donde el juego asfixia por completo y creo que se mueve a 10-15, pero es una escena que no veo el motivo de esas bajadas porque es la zona donde menos se ve y lo poco que renderiza nunca me pareció más cargado que las calles de la ciudad.

Va como la mierda esa zona, sobre todo donde está el tio vivo.

Con Silent Hill se les fue de las manos la carga grafica muchas veces, ahora saldra alguno diciendo que en saturn sin problemas el Silent Hill.

naxeras escribió:

SuperPadLand escribió:@dirtymagic sí, me suena que andaba en 4000-5000 por frame, pero oscilando entre 18 y 25fps en PAL que imagino serán 20-30 en NTSC. Lo que me gustaría es que alguien analizase la zona del parque de atracciones porque es donde el juego asfixia por completo y creo que se mueve a 10-15, pero es una escena que no veo el motivo de esas bajadas porque es la zona donde menos se ve y lo poco que renderiza nunca me pareció más cargado que las calles de la ciudad.

Va como la mierda esa zona, sobre todo donde está el tio vivo.

Con Silent Hill se les fue de las manos la carga grafica muchas veces, ahora saldra alguno diciendo que en saturn sin problemas el Silent Hill.

Sí, pero es que no tiene sentido porque en el pueblo tienes más distancia de dibujado, ves los edificios y aceras e incluso pone dos enemigos en pantalla y aunque se ralentiza también, no lo hace tanto como ahí.

@SuperPadLand
En el video me da la sensación por cómo se ilumina, que tiene muchos vértices y el tiovivo también, en la ciudad me suena que hay niebla, pero no iluminación dinámica con la linterna, ni idea como funciona en PSX, pero en Nintendo64, la niebla,es un efecto que funciona por pixel y es suave, la iluminación por vértices, necesita mucho vértices juntos para que no sea un cambio brusco.

Salud.

SuperPadLand escribió:

naxeras escribió:

SuperPadLand escribió:@dirtymagic sí, me suena que andaba en 4000-5000 por frame, pero oscilando entre 18 y 25fps en PAL que imagino serán 20-30 en NTSC. Lo que me gustaría es que alguien analizase la zona del parque de atracciones porque es donde el juego asfixia por completo y creo que se mueve a 10-15, pero es una escena que no veo el motivo de esas bajadas porque es la zona donde menos se ve y lo poco que renderiza nunca me pareció más cargado que las calles de la ciudad.

Va como la mierda esa zona, sobre todo donde está el tio vivo.

Con Silent Hill se les fue de las manos la carga grafica muchas veces, ahora saldra alguno diciendo que en saturn sin problemas el Silent Hill.

Sí, pero es que no tiene sentido porque en el pueblo tienes más distancia de dibujado, ves los edificios y aceras e incluso pone dos enemigos en pantalla y aunque se ralentiza también, no lo hace tanto como ahí.

Yo creo que es el tiovivo que al no haber zbuffer y luego hay que animarlo esta cargado en todo momento en el escenario, son un montón de poligonos, animaciones y demás el tiovivo ese.

Es horrible como va esa zona, recuerdo meter overclock a saco en la CPU y ni con esas.

¿Dices esta zona?

https://www.youtube.com/watch?v=jS98m3haoWc

Solo añadir un pequeño comentario sobre el polycount de Silent Hill porque lo mayoría de la cantidad de polígonos que te muestra el emulador no se transmiten a la geometría y esto se debe a la niebla.

En PSX puedes hacer niebla de 3 maneras:
-1) Para polígonos sin textura, simplemente cambias el color del vértice.

-2) Para polígonos con textura hay 3 maneras:
---- 2a) Usas CLUT Fog,
En las texturas se pueden almacenar el color a pelo, o el “Contenido/patrón” por un lado haciendo referencia a unos colores (normalmente muy limitados) que se almacenan en otro sitio “CLUT (Color Look Up Table)”. La idea de CLUT Fog es crear diferentes CLUTs que van desde el color normal de la textura hasta el color deseado de la niebla, eso se puede ver por ejemplo en MegaMan Legends or las demos de XL2 que usa niebla. EL problema de esta niebla es que su transición no es lineal y se va a ver a saltos.

----2b) Usas un polígono por debajo sin textura
Con una transición de colores de gris a negro, por ejemplo, y luego renderizas encima otro polígono son transparencia sustractiva. Este tipo de niebla es algo que Saturn no puede hacer y que por lo poco que entiendo de N64, le sale por mucho menos coste. El problema en PSX es que tienes que renderizar los polígonos dos veces (Si usaís el VRAM viewer de NO$CASH podéis ver como Silent Hill o Soul River tienen que renderizar bastantes polígonos dos veces) esto al final para la CPU supone poca carga, porque está usando información del polígono anterior, la traca se la lleva la GPU.

----2c) “Destrozar” el Gouraud original
Este sería el caso de juegos como Ape Escape que lo que hacen es “cargarse” la información de Gouraud original para los polígonos que estén lejos y cambiarlos por esa transición de negro a gris, y cambiar el polígono de opaco a semi transparente con sustracción, con este método te ahorras el doble pase, pero se puede apreciar como los polígonos del fondo se van haciendo más oscuros antes de hacerse transparentes.


-3) Niebla Negra (este puede ser, con, o sin textura)
Esta generalmente no necesita de doble renderizado ya que simplemente te puedes cargar el patrón de la textura si pintas todos los vértices de negro.

P.D. Sobre la caída de FPS en Silent Hill, no tengo ni idea, pero viendo que la zona parece estar más despoblada que otras, puede ser justo una encrucijada de carga y que los programadores ya sabían que tenían que aflojar la carga poligonal ahí.

Misscelan escribió:Solo añadir un pequeño comentario sobre el polycount de Silent Hill porque lo mayoría de la cantidad de polígonos que te muestra el emulador no se transmiten a la geometría y esto se debe a la niebla.

En PSX puedes hacer niebla de 3 maneras:
-1) Para polígonos sin textura, simplemente cambias el color del vértice.

-2) Para polígonos con textura hay 3 maneras:
---- 2a) Usas CLUT Fog,
En las texturas se pueden almacenar el color a pelo, o el “Contenido/patrón” por un lado haciendo referencia a unos colores (normalmente muy limitados) que se almacenan en otro sitio “CLUT (Color Look Up Table)”. La idea de CLUT Fog es crear diferentes CLUTs que van desde el color normal de la textura hasta el color deseado de la niebla, eso se puede ver por ejemplo en MegaMan Legends or las demos de XL2 que usa niebla. EL problema de esta niebla es que su transición no es lineal y se va a ver a saltos.

----2b) Usas un polígono por debajo sin textura
Con una transición de colores de gris a negro, por ejemplo, y luego renderizas encima otro polígono son transparencia sustractiva. Este tipo de niebla es algo que Saturn no puede hacer y que por lo poco que entiendo de N64, le sale gratis. El problema en PSX es que tienes que renderizar los polígonos dos veces (Si usaís el VRAM viewer de NO$CASH podéis ver como Silent Hill o Soul River tienen que renderizar bastantes polígonos dos veces) esto al final para la CPU supone poca carga, porque está usando información del polígono anterior, la traca se la lleva la GPU.

----2c) “Destrozar” el Gouraud original
Este sería el caso de juegos como Ape Escape que lo que hacen es “cargarse” la información de Gouraud original para los polígonos que estén lejos y cambiarlos por esa transición de negro a gris, y cambiar el polígono de opaco a semi transparente con sustracción, con este método te ahorras el doble pase, pero se puede apreciar como los polígonos del fondo se van haciendo más oscuros antes de hacerse transparentes.


-3) Niebla Negra (este puede ser, con, o sin textura)
Esta generalmente no necesita de doble renderizado ya que simplemente te puedes cargar el patrón de la textura si pintas todos los vértices de negro.

P.D. Sobre la caída de FPS en Silent Hill, no tengo ni idea, pero viendo que la zona parece estar más despoblada que otras, puede ser justo una encrucijada de carga y que los programadores ya sabían que tenían que aflojar la carga poligonal ahí.

Buenas, muy interesante la explicación .

Entiendo que lo de renderizar el poligono doble ¿solo es en los poligonos que bordean en la niebla no? ¿luego quitan el poligono duplicado que tenia la transparencia sustractiva?

naxeras escribió:
Buenas, muy interesante la explicación .

Entiendo que lo de renderizar el poligono doble ¿solo es en los poligonos que bordean en la niebla no? ¿luego quitan el poligono duplicado que tenia la transparencia sustractiva?

En principio sí, y entiendo que así deberían proceder todos los juegos que quieran usar ese tipo de niebla, el problema de Silent Hill es que la niebla llega hasta la cámara, así que geométricamente la escena está casi al 100% duplicada.

Curioso lo de Silent Hill. En DuckStation se ve el número de triángulos renderizados por frame y el juego ya empieza a rascar de lo lindo antes de llegar a 1.000.

dirtymagic escribió:@SuperPadLand
En el video me da la sensación por cómo se ilumina, que tiene muchos vértices y el tiovivo también, en la ciudad me suena que hay niebla, pero no iluminación dinámica con la linterna, ni idea como funciona en PSX, pero en Nintendo64, la niebla,es un efecto que funciona por pixel y es suave, la iluminación por vértices, necesita mucho vértices juntos para que no sea un cambio brusco.

Salud.

Creo, que tú puedes encender la linterna a tu antojo en cualquier momento. Pero ahora que lo dices es posible que en esa zona metieran más polígonos para reducir el cambio brusco de iluminación ya que está todo tan oscuro que sólo ves lo que la linterna permite. En otra zonas la linterna aclara la zona, pero puedes ver todavía más allá aunque sea más oscuro.

Al final he probado unos cuantos juegos en DuckStation para comprobar la poligonización (me he limitado a las primeras pantallas):

Crash 1: hasta 1200.
Spyro 3: 1700 sin bajar ni un frame y con ese sistema de LOD tan estupendo que tiene.
Ridge Racer Type 4: hasta 1300-1400 en el primer circuito, con el espejo retrovisor y un par de coches a tu alrededor, pero me ha costado sacar tantos.
MediEvil 2: en el interior del museo suele rondar los 800, y en el jardín, que es zona abierta (mete niebla) y con cuatro enemigos pululando, cuesta tocar los 1200.

Interpreten ustedes estos números como deseen. A mí me ha sorprendido ver números tan bajos, especialmente en RR4. Al final no es solo mover polígonos, sino la calidad de las texturas, los efectos, la iluminación, etc.

El silent hil no es precisamente un portento grafico.
El personaje se mueve ortopedicamente, todos sabemos el truco de la niebla, eso no resta que sea un juegazo.

El spyro 3 para mi es uno de los juegos que gráficamente y jugablemente que se ve en la gris, no suele rascar mucho eso no quita que los gráficos de spyro sean muy poligonal como en n64 el Mario.

Dudeman Guymanington escribió:Al final he probado unos cuantos juegos en DuckStation para comprobar la poligonización (me he limitado a las primeras pantallas):

Crash 1: hasta 1200.
Spyro 3: 1700 sin bajar ni un frame y con ese sistema de LOD tan estupendo que tiene.
Ridge Racer Type 4: hasta 1300-1400 en el primer circuito, con el espejo retrovisor y un par de coches a tu alrededor, pero me ha costado sacar tantos.
MediEvil 2: en el interior del museo suele rondar los 800, y en el jardín, que es zona abierta (mete niebla) y con cuatro enemigos pululando, cuesta tocar los 1200.

Interpreten ustedes estos números como deseen. A mí me ha sorprendido ver números tan bajos, especialmente en RR4. Al final no es solo mover polígonos, sino la calidad de las texturas, los efectos, la iluminación, etc.

Es lo que he dicho varias veces ya, en SS para alcanzar los mil pol fluídos hay que sacrificar cosas, en PS1 tienes cifras superiores a los mil polis con montones de efectos gráficos activados.

Karaculo escribió:El silent hil no es precisamente un portento grafico.
El personaje se mueve ortopedicamente, todos sabemos el truco de la niebla, eso no resta que sea un juegazo.

El spyro 3 para mi es uno de los juegos que gráficamente y jugablemente que se ve en la gris, no suele rascar mucho eso no quita que los gráficos de spyro sean muy poligonal como en n64 el Mario.

Discrepo, la distancia de dibujado es pequeña eso sí, pero todo lo que muestra tiene una calidad y detalle inaudita para esta gen y como ha dicho el compañero para iluminar eso por vértice sin notar golpes hay que recurrir a poner muchos más polígonos pequeños. Y es que al final la iluminación conseguida en este juego es su mayor logro técnico a mi parecer.

Dudeman Guymanington escribió:Al final he probado unos cuantos juegos en DuckStation para comprobar la poligonización (me he limitado a las primeras pantallas):

Crash 1: hasta 1200.
Spyro 3: 1700 sin bajar ni un frame y con ese sistema de LOD tan estupendo que tiene.
Ridge Racer Type 4: hasta 1300-1400 en el primer circuito, con el espejo retrovisor y un par de coches a tu alrededor, pero me ha costado sacar tantos.
MediEvil 2: en el interior del museo suele rondar los 800, y en el jardín, que es zona abierta (mete niebla) y con cuatro enemigos pululando, cuesta tocar los 1200.

Interpreten ustedes estos números como deseen. A mí me ha sorprendido ver números tan bajos, especialmente en RR4. Al final no es solo mover polígonos, sino la calidad de las texturas, los efectos, la iluminación, etc.

Ahi tenemos otra prueba más que saturn mueve más poligonos por segundo que psx, gracias por el aporte compañero!

Bullrun escribió:

Dudeman Guymanington escribió:Al final he probado unos cuantos juegos en DuckStation para comprobar la poligonización (me he limitado a las primeras pantallas):

Crash 1: hasta 1200.
Spyro 3: 1700 sin bajar ni un frame y con ese sistema de LOD tan estupendo que tiene.
Ridge Racer Type 4: hasta 1300-1400 en el primer circuito, con el espejo retrovisor y un par de coches a tu alrededor, pero me ha costado sacar tantos.
MediEvil 2: en el interior del museo suele rondar los 800, y en el jardín, que es zona abierta (mete niebla) y con cuatro enemigos pululando, cuesta tocar los 1200.

Interpreten ustedes estos números como deseen. A mí me ha sorprendido ver números tan bajos, especialmente en RR4. Al final no es solo mover polígonos, sino la calidad de las texturas, los efectos, la iluminación, etc.

Ahi tenemos otra prueba más que saturn mueve más poligonos por segundo que psx, gracias por el aporte compañero!

En realidad no, esas cifras están por encima de SS y con más efectos, si le pones la misma calidad 3D de SS todavía suben más.

En SS 4x4 Hardcore mueve 1400 por frame que es lo más alto de lo que se tienen datos y además tiene exactamente toda la carga gráfica como en PS1 (mira los enlaces) pero lo hace a 15fps, es decir 21k por segundo, en PS1 esa misma calidad es a 30fps, el doble. Y es un ejemplo perfecto porque ambos juegos activan la misma calidad gráfica.

TR le pasa lo mismo, pero en este al menos ya cambia cosas por cosas 2D y no se arrastra tanto.

Los juegos buenos y con framerate aceptable de Saturn andan en 800 poligonos por frame y 20-30fps (Quake, Exhumed, BR, etc). O 600 y 60fps (VF2).

SuperPadLand escribió:Los juegos buenos y con framerate aceptable de Saturn andan en 800 poligonos por frame y 20-30fps (Quake, Exhumed, BR, etc). O 600 y 60fps (VF2).

Lo que nunca entendí es el tema de las cifras declaradas.

Creo que tanto Saturn y PSX declaraban 500.000 poligonos. Nintendo 64 declaraba menos...

Pero al final, en general las cifras con efectos, filtros y demás... Se alejan mucho de esas cifras...

¿Reclamo comercial?

@CarrieFernandez marketing como lo de decir que eres de 64bits por usar dos de 32. Y leyendo este hilo puedes ver que cuajó entre algunos.

SS da sus cifras sumando todos los polígonos planos que cada CPU por separado puede procesar, ignorando que eso no puede suceder al mismo tiempo.

PS1 no sé si dió polígonos planos o número de vértices, el caso es que era una cifra enorme.

N64 ni idea, pero si dio una cifra más modesta era porque decía rendimiento con efectos gráficos activados y en su caso no sólo tiene los mismos que las anteriores sino que tiene más y mejores así que con menos polys tiene mucha más calidad.


En SS incluso suponiendo que el poly planos sea superior, sirve de poco si luego tienes que sacrificar mucha de esa capacidad en texturizar, iluminar, etc. Y la competencia no.

Virtua fighter 2 saturn version.
100000 polígonos por segundo
60 fps
100k/60= 1666 polígonos por frame.
Por encima de la mayoría del catálogo de psx.

@Bullrun VF2 usa 600x60 con todo 2D menos los luchadores, sin goraud, profundidad de color reducida, etc.

Las cifras que das tú no es que superen a PS1 es que ponen a SS a la misma altura que la Model 1.

Bullrun escribió:Virtua fighter 2 saturn version.
100000 polígonos por segundo
60 fps
100k/60= 1666 polígonos por frame.
Por encima de la mayoría del catálogo de psx.

https://imgur.com/Uc4DBpo

hasta un triste mortal kombat 4 pone mas geometria

@titorino ahí se ve bien lo que ahorra en poligonos la SS tirando de planos 2D, que oye para ese género es todo un acierto, pero para otros géneros como que no. Incluso cosas como los Bushidos Blade o el Digimon clon de Smash Bros no puedes.

@SuperPadLand y cosas como un soul edge ,impensables y menos metiéndole lo que mete ese juego en efectos .

titorino escribió:@SuperPadLand y cosas como un soul edge ,impensables y menos metiéndole lo que mete ese juego en efectos .

Y menos no, solo por los efectos (que no es poco). Soul Edge mueve 900-1300 polígonos por frame, que es una cifra normalita teniendo en cuenta que lo hace a 30 fps. Last Bronx en Saturn mueve unos 600 quads (que pueden ser el equivalente a 600-1200 triángulos, dependiendo de lo que requieran los modelos) al doble de fps y no necesita más porque el suelo y el techo le salen gratis; si te pones a igualar la resolución y framerate de Soul Edge, no creo que tengas problemas para sacar los mismos polígonos por segundo. Eso sí, pelados, como es marca de la casa.

@Dudeman Guymanington yo sigo sin entender porque se considera un quad el doble de triángulos. Hasta donde entiendo se renderiza un quad primero y luego de procesa para unir dos vértices y así tener un triángulo (lo cual tiene costo de por si) si realmente un quad cumple la misma función que dos polígonos vale, pero no es así sino los juegos en SS tendrían que verse mucho mejor.

No se puede decir que una consola fuera más potente que la otra simplemente en términos generales. Ambos, Sega Saturn y Sony PlayStation, tenían diferentes fortalezas y debilidades en términos de hardware y software.

En términos de hardware, Sega Saturn tenía un hardware más complejo y difícil de programar que el de PlayStation, lo que significaba que los desarrolladores a veces encontraban dificultades para sacarle el máximo partido a la consola. Sin embargo, también tenía una capacidad de renderizado y efectos especiales más avanzados que PlayStation.

Por otro lado, PlayStation tenía un hardware más sencillo y fácil de programar, lo que significaba que los desarrolladores podían crear juegos con una mayor calidad gráfica y un rendimiento más fluido. También tenía una amplia gama de juegos disponibles, incluyendo títulos de acción, aventura, juegos de rol y deportes, lo que la hacía atractiva para una amplia gama de jugadores.

En resumen, ambas consolas tenían sus fortalezas y debilidades, y no se puede decir que una fuera mejor o más potente que la otra de manera definitiva.

SuperPadLand escribió:@Dudeman Guymanington yo sigo sin entender porque se considera un quad el doble de triángulos. Hasta donde entiendo se renderiza un quad primero y luego de procesa para unir dos vértices y así tener un triángulo (lo cual tiene costo de por si) si realmente un quad cumple la misma función que dos polígonos vale, pero no es así sino los juegos en SS tendrían que verse mucho mejor.

Eso se hace cuando quieres algo triangular, digamos los pinchos de la cabeza de Sonic, pero normalmente los quads tenían sus cuatro vértices. En el vídeo que todos hemos visto de Tomb Raider se ve como la mayor parte de polígonos son cuadriláteros, no triángulos:



En otros... pues depende. En Wipeout 2097 se ve que en muchos momentos hay triángulos a cascoporro, desaprovechando rendimiento. Unas veces es inevitable y otras ocurría al importar mapas de PS1 y querer que tuvieran el mismo aspecto, supongo:



Estaría bien que alguien activara el wireframe en WipeOut 2097 con algún emulador de PS1 para ver cómo lo hace (sé que en ePSXe se puede, pero no me funciona), y también comparar el número de triángulos y quads. Curiosamente, a ese juego le pasa lo mismo que a Tomb Raider, que en Saturn van peor pero tienen mayor distancia de dibujado. Ejemplo:



Fíjate en que en PS1 la nave está a punto de llegar al booster del suelo y en el horizonte se ve en negro que aún no se ha cargado parte del escenario. En Saturn esa parte se muestra no ya en el momento de llegar al booster, sino incluso estando más atrás, y así en todos los circuitos. Incomprensible.

P. D. Ya que estoy con lo del wireframe, dejo unos gifs para que se vea cómo se exprimió la PS1 con tres juegos de la misma saga como ejemplo.

Ace Combat, donde el horizonte y gran parte del suelo parecen de SNES:



Ace Combat 2, con muchísima más poligonización y teselación que ocurre mucho más cerca del suelo:



Ace Combat 3:

SuperPadLand escribió:@Dudeman Guymanington yo sigo sin entender porque se considera un quad el doble de triángulos. Hasta donde entiendo se renderiza un quad primero y luego de procesa para unir dos vértices y así tener un triángulo (lo cual tiene costo de por si) si realmente un quad cumple la misma función que dos polígonos vale, pero no es así sino los juegos en SS tendrían que verse mucho mejor.

No es que sea el doble, es que depende de como hagas el modelo 3D puede ser totalmente distinto. Según lo que quieras representar. Un muro plano o un coche como los de Daytona USa más cuadrados, en Saturn siendo cuadriláteros y en PSX triángulos si puede ser es el doble, en cambio otros modelos no. Juegos como Doom con paredes cuadradas aprovechan mejor los quads de Saturn. Menos quads para hacer lo mismo.

En el caso de los multis pasó a modelarse en triángulos y usar dos vértices el mismo desaprovechando las cualidades de Saturn. No volvian a hacer los modelos para quads.

No es sólo cuestión de comparar número de polígonos (quads vs triángulos) como si fuera verdad absoluta. no es tan sencillo de comparara lo que se pude hacer con uno y con otro con el mismo número.

Las 3D en aquellos años estaban verdes y mejoraban mucho de un año para otro. No hace falta ver que entre Virtua Racing, Daytona USA y Sega Rally de recreativa hay sobre un año entre cada uno.

Los desarrolladores descubrían como hacer los modelos mejor, como usar las texturas mejor, optimizar motores gráficos o mejores efectos de un juego al siguiente que hacían. No hace falta decir mucho comparando los primeros juegos de Saturn con los últimos.

Tampoco estaban familiarizados con usar más de una CPU, VDP1, VDP1, DSP, etc.

Saturn tuvo poco más de 4 años de desarrollo de los programadores de Sega 1994 al 1998 que salió Dreamcast. Creo que aún daba más de si. Como la diferencia entre los 3 sonic de megadrive. Con los juegos de Saturn haciendo un "simil" nos quedamos en Sonic 2 y no vimos mejoras como un Sonic 3 de megadrive. Compara los primeros juegos de megadrive o SNES con los últimos.

Quizás hubiera sido Shenmue, pero lo acabaron haciendo en Dreamcast.

Como apuntó alguien más arriba, la estética y saturación de colores de los juegos 3D de Saturn serían un filón para usarla en juegos indies que intentaran replicar aquellos engines:


El año pasada la programadora Erysdren anunció un "remake/port" del engine del Quake 1 de Sega Saturn para Pc.

Algunos estarán preguntándose el por qué de jugar a ésta versión en vez de la nueva "remakeada" oficialmente por Bethesda. La respuesta es bien sencilla: el Quake de Saturn tenía una paleta de colores más saturada, unos efectos de sombras y luces que le iban como anillo al dedo al juego de Carmack.

Si bien es cierto que petardeaba en cuestión de I.A. enemiga y simplificación de geometría en los escenarios, el juego en si mismo era una obra maestra.

Dos cosas valoro de SS, una la saturación cromática y el aspecto de robustez que tenía tanto en algunos títulos como en su hardware.

Yo sigo diciendo lo mismo, que Sega debió encontrar un equilibrio que le diese unos títulos 2.5D bien trabajados que la hubiesen diferenciado de psx, una apuesta más sencilla pero más ambiciosa en cuanto a títulos.

Yo veo los clockwork knight y se me cae el alma a los pies porque son títulos que no aprovechan el potencial de la máquina para esas tareas, al contrario, incluso en lo jugable son mediocres.

Sería interesante dejar de lado los paupérrimos 3d que tuvo en multis y centrarnos en lo que realmente es buena y aprovechar eso para que esta consola encontrase su sitio con dignidad.

Un juego como Tenka que era del montón en PSX, en Saturn parece que sería el summum de la creación técnica y no es así.

Quizás no estaríamos hablando de cuál era mejor sino de quién tenía el mejor catálogo.

Porque esa es la clave, el catálogo y por desgracia ni siquiera sega lanzó títulos 2d ó 2.5d memorables.

Otro punto a favor de PSX fue la etiqueta Platinum, eso sí que fue un golpe maestro, mientras que en SS los juegos baratos era porque ya ni se vendían consolas y había que quitar el catálogo de encima.

Pues viendo esos números tampoco andaba tan alejada la saturn en polycount respecto a psx, no era tampoco una diferencia "generacional" como se solía decir o que fuera tal que era imposible portar ciertos juegos.

Lo mas sangrante eran las transparencias, si hubieran solucionado esto de alguna manera los juegos no hubieran tenido ese aspecto tan tosco o primitivo.


@Dudeman Guymanington

Esto de la distancia de dibujado es algo que me intriga, la consola fue famosa en sus inicios por tener distancias de dibujado absolutamente pauperrimas, pero a medida que fue pasando el tiempo esto se fue solucionando hasta el extremo de llegar a tener mayores distancias de dibujado que psx en juegos comunes como este Wipeout o el Courier Crisis de 1998, juegos que por otra parte no usaban el VDP2 para pintar el suelo.

La generación imperfecta, Saturn con quads, Playstation sin corrección de perspectiva y Nintendo 64 en cartucho.

una pregunta para los más duchos.

Recuerdo en un Game40 que hablaban (cuando lo hacían) sobre los kits de desarrollo de la saturn.

Concretamente de los compiladores de alto nivel, que solucionaron en gran parte los problemas de programación de la consola, no se si se referían a que ya se podían compilar en Visual o en C pero creo recordar que lo hacían todo a lo bruto por software.

Hasta qué punto creéis si esto es cierto y si realmente de haber salido estos sdks a tiempo, habrían solucionado gran parte de los problemas.

Lo recuerdo en una entrevista a alguien de Sega, creo que la parte de software es que obviaban la segunda CPU porque el compilador no estaba preparado para multiprocesos, que la consola rendía menos (evidentemente), pero que facilitaba enormemente el trabajo.

eknives escribió:La generación imperfecta, Saturn con quads, Playstation sin corrección de perspectiva y Nintendo 64 en cartucho.

Y aun así tuvimos: Zelda, Panzer Dragoon y Metal Gear Solid

gordon81 escribió:una pregunta para los más duchos.

Recuerdo en un Game40 que hablaban (cuando lo hacían) sobre los kits de desarrollo de la saturn.

Concretamente de los compiladores de alto nivel, que solucionaron en gran parte los problemas de programación de la consola, no se si se referían a que ya se podían compilar en Visual o en C pero creo recordar que lo hacían todo a lo bruto por software.

Hasta qué punto creéis si esto es cierto y si realmente de haber salido estos sdks a tiempo, habrían solucionado gran parte de los problemas.

Lo recuerdo en una entrevista a alguien de Sega, creo que la parte de software es que obviaban la segunda CPU porque el compilador no estaba preparado para multiprocesos, que la consola rendía menos (evidentemente), pero que facilitaba enormemente el trabajo.

Que mejoraron los SDK es una realidad confirmada y juegos que usaron la segunda CPU los hubo a patadas, la gente se ha quedado con que muchos de los peores juegos de SS no lo usaron y lo han extrapolado a todo el catálogo. El VDP2 tampoco hace milagros poligonales, ya has visto en este hilo para que sirve y en que géneros se le puede sacar partido, te imaginas un Wipeout o un plataformas 3D usando un plano 2D para renderizar los suelos? No es una simple cuestión de tener un segundo procesador, sino de que puede hacer ese procesador.

eknives escribió:La generación imperfecta, Saturn con quads y sin correción de perspectiva, Playstation sin corrección de perspectiva y Nintendo 64 en cartucho.

Fixed.

Para los polígonos, la GPU de Ps1 siempre renderiza triángulos (excepto para el tipo de paquete SPRITE), aunque tú le pases Quads, pero muchos de los emuladores muestran el wireframe de lo que hace la GPU y NO de los paquetes enviados (el verdadero polycount).
Y se suele cometer el error de que a lo mejor el emulador te muestra 1500 polígonos (refiriéndose a los paquetes enviados) y como el wireframe se ve en triángulos se piensa “pues eso equivale a unos 750 quads” y muy probablemente no sea el caso.

A la CPU de PS1 siempre le conviene que se envíen Quads, porque se procesan más rápido, se subdividen más rápido y necesitas un paquete en vez de dos, lo que ocupa menos memoria. Habrá juegos que usan dos triángulos para representar un Quad por oscuras razones (o quizás desconocimiento en los primeros juegos) pero no debería ser la norma.

Yo he llegado a contar unos 1900 polígonos en Spyro (30fps a 512x240), usando el VRAM viewer de No$Cash, uno, a uno (sí un coñazo) pero estaba estudiando como hacía la subdivisión y los LODs y también quería ver que era factible en términos de polycount. En eso 1900 polis, se usaban Quads cuando se podían usar Quads, y triángulos cuando no había más remedio, así que la Saturn tendría que renderizar sus 1900 Quads (algunos deformados para crear triángulos) si quisiese renderizar los mismos modelos para este caso.

docobo escribió:No se puede decir que una consola fuera más potente que la otra simplemente en términos generales. Ambos, Sega Saturn y Sony PlayStation, tenían diferentes fortalezas y debilidades en términos de hardware y software.

En términos de hardware, Sega Saturn tenía un hardware más complejo y difícil de programar que el de PlayStation, lo que significaba que los desarrolladores a veces encontraban dificultades para sacarle el máximo partido a la consola. Sin embargo, también tenía una capacidad de renderizado y efectos especiales más avanzados que PlayStation.

Por otro lado, PlayStation tenía un hardware más sencillo y fácil de programar, lo que significaba que los desarrolladores podían crear juegos con una mayor calidad gráfica y un rendimiento más fluido. También tenía una amplia gama de juegos disponibles, incluyendo títulos de acción, aventura, juegos de rol y deportes, lo que la hacía atractiva para una amplia gama de jugadores.

En resumen, ambas consolas tenían sus fortalezas y debilidades, y no se puede decir que una fuera mejor o más potente que la otra de manera definitiva.

No sólo fue hardware. Sony se preocupó de entregar mejores herramientas de desarrollo y un SDK más amigable. SEGA estaba más acostumbrada a programar a bajo nivel y no le dio la importancia necesaria para que terceros lo tuvieran más fácil.

gordon81 escribió:una pregunta para los más duchos.

Recuerdo en un Game40 que hablaban (cuando lo hacían) sobre los kits de desarrollo de la saturn.

Concretamente de los compiladores de alto nivel, que solucionaron en gran parte los problemas de programación de la consola, no se si se referían a que ya se podían compilar en Visual o en C pero creo recordar que lo hacían todo a lo bruto por software.

Hasta qué punto creéis si esto es cierto y si realmente de haber salido estos sdks a tiempo, habrían solucionado gran parte de los problemas.

Lo recuerdo en una entrevista a alguien de Sega, creo que la parte de software es que obviaban la segunda CPU porque el compilador no estaba preparado para multiprocesos, que la consola rendía menos (evidentemente), pero que facilitaba enormemente el trabajo.

Si lo vemos desde el lado económico.

Sony: Saca kits de desarrollo en C de inicio, presta ayuda a las third sin poner pegas, bajos costes para vender tu juego. Juegos con triángulos. Consola más barata de inicio.
Sega: Saca kits de desarrollo en ASM, lo de prestar ayuda a las third ya si eso, altos costes estilo Nintendo-yo-soy-el-rey. Juegos con quads. Consola más cara de inicio.

Con este panorama, si eres una third, tiras por el lado de Sony y conviertes como puedes a la Saturn.

Posteriormente Sega vió el percal y sacó una librería para poder ayudar a los devs. Pero claro, si tu empresa ya tiene todo el tinglado orientado a la consola de Sony, esa va a ser tu consola principal, porque es con la que ganas más dinero (te cuesta MENOS coste desarrollar para ella).
Por supuesto, las librerías que sacó Sega posteriormente ayudan, pero aún así los costes son mayores, porque todo tu negocio está orientado a la de Sony.

Sin ir más lejos, los modelos 3D los has desarrollado con triángulos. Pasar todo a quads, sólo eso, independientemente de que el engine del juego tiene que ser diferente, ya son horas y horas de dedicación. Es decir, DINERO. Haz luego otro engine. Pues no, demasiado caro.

Y ya lo tenemos.

Me gustaría saber si algún kit de desarrollo de PSX tenía soporte para programar en ASM .

Imagino que el dinosario de la demo técnica podría ser uno de los casos.

¿qué opináis?

Es decir, existe algún juego programado en ASM para PSX?

danibus escribió:

gordon81 escribió:una pregunta para los más duchos.

Recuerdo en un Game40 que hablaban (cuando lo hacían) sobre los kits de desarrollo de la saturn.

Concretamente de los compiladores de alto nivel, que solucionaron en gran parte los problemas de programación de la consola, no se si se referían a que ya se podían compilar en Visual o en C pero creo recordar que lo hacían todo a lo bruto por software.

Hasta qué punto creéis si esto es cierto y si realmente de haber salido estos sdks a tiempo, habrían solucionado gran parte de los problemas.

Lo recuerdo en una entrevista a alguien de Sega, creo que la parte de software es que obviaban la segunda CPU porque el compilador no estaba preparado para multiprocesos, que la consola rendía menos (evidentemente), pero que facilitaba enormemente el trabajo.

Si lo vemos desde el lado económico.

Sony: Saca kits de desarrollo en C de inicio, presta ayuda a las third sin poner pegas, bajos costes para vender tu juego. Juegos con triángulos. Consola más barata de inicio.
Sega: Saca kits de desarrollo en ASM, lo de prestar ayuda a las third ya si eso, altos costes estilo Nintendo-yo-soy-el-rey. Juegos con quads. Consola más cara de inicio.

Con este panorama, si eres una third, tiras por el lado de Sony y conviertes como puedes a la Saturn.

Posteriormente Sega vió el percal y sacó una librería para poder ayudar a los devs. Pero claro, si tu empresa ya tiene todo el tinglado orientado a la consola de Sony, esa va a ser tu consola principal, porque es con la que ganas más dinero (te cuesta MENOS coste desarrollar para ella).
Por supuesto, las librerías que sacó Sega posteriormente ayudan, pero aún así los costes son mayores, porque todo tu negocio está orientado a la de Sony.

Sin ir más lejos, los modelos 3D los has desarrollado con triángulos. Pasar todo a quads, sólo eso, independientemente de que el engine del juego tiene que ser diferente, ya son horas y horas de dedicación. Es decir, DINERO. Haz luego otro engine. Pues no, demasiado caro.

Y ya lo tenemos.

Y todo para que al terminar las ventas de la versión de Saturn sean malas y no recuperar la inversión.

Rai_Seiyuu escribió:

danibus escribió:

gordon81 escribió:una pregunta para los más duchos.

Recuerdo en un Game40 que hablaban (cuando lo hacían) sobre los kits de desarrollo de la saturn.

Concretamente de los compiladores de alto nivel, que solucionaron en gran parte los problemas de programación de la consola, no se si se referían a que ya se podían compilar en Visual o en C pero creo recordar que lo hacían todo a lo bruto por software.

Hasta qué punto creéis si esto es cierto y si realmente de haber salido estos sdks a tiempo, habrían solucionado gran parte de los problemas.

Lo recuerdo en una entrevista a alguien de Sega, creo que la parte de software es que obviaban la segunda CPU porque el compilador no estaba preparado para multiprocesos, que la consola rendía menos (evidentemente), pero que facilitaba enormemente el trabajo.

Si lo vemos desde el lado económico.

Sony: Saca kits de desarrollo en C de inicio, presta ayuda a las third sin poner pegas, bajos costes para vender tu juego. Juegos con triángulos. Consola más barata de inicio.
Sega: Saca kits de desarrollo en ASM, lo de prestar ayuda a las third ya si eso, altos costes estilo Nintendo-yo-soy-el-rey. Juegos con quads. Consola más cara de inicio.

Con este panorama, si eres una third, tiras por el lado de Sony y conviertes como puedes a la Saturn.

Posteriormente Sega vió el percal y sacó una librería para poder ayudar a los devs. Pero claro, si tu empresa ya tiene todo el tinglado orientado a la consola de Sony, esa va a ser tu consola principal, porque es con la que ganas más dinero (te cuesta MENOS coste desarrollar para ella).
Por supuesto, las librerías que sacó Sega posteriormente ayudan, pero aún así los costes son mayores, porque todo tu negocio está orientado a la de Sony.

Sin ir más lejos, los modelos 3D los has desarrollado con triángulos. Pasar todo a quads, sólo eso, independientemente de que el engine del juego tiene que ser diferente, ya son horas y horas de dedicación. Es decir, DINERO. Haz luego otro engine. Pues no, demasiado caro.

Y ya lo tenemos.

Y todo para que al terminar las ventas de la versión de Saturn sean malas y no recuperar la inversión.

Es que es eso. La gente se marea mucho con los quads, el doble procesador,etc,etc.
Al final si un producto vende, sigue vivo y evoluciona. Da igual que sea caro si se gana dinero. Mira a Apple.
Pero si no haces dinero, es más, pierdes con cada venta, ya dependes de vender muchos juegos. Creo que con Dreamcast eran 6-7 para no perder dinero con la venta de la consola, y de media vendieron ¿4? (hablo de memoria de lo que se dijo en el documental A Dream Cast).
Imaginad con la Saturn.

Fue un panorama sombrío que visto con la perspectiva que da el tiempo es casi un milagro que pudiéramos ver pepinos como el Sega Rally, Nights, Panzer, Quake o Exhumed.

danibus escribió:Es que es eso. La gente se marea mucho con los quads, el doble procesador,etc,etc.
Al final si un producto vende, sigue vivo y evoluciona. Da igual que sea caro si se gana dinero. Mira a Apple.
Pero si no haces dinero, es más, pierdes con cada venta, ya dependes de vender muchos juegos. Creo que con Dreamcast eran 6-7 para no perder dinero con la venta de la consola, y de media vendieron ¿4? (hablo de memoria de lo que se dijo en el documental A Dream Cast).
Imaginad con la Saturn.

Dicen las malas lenguas que la venta de software de Dreamcast no era muy buena quitando dos o tres juegos y tras la salida del CD Utopia, las ventas de los juegos fueron a peor.

Misscelan escribió:Para los polígonos, la GPU de Ps1 siempre renderiza triángulos (excepto para el tipo de paquete SPRITE), aunque tú le pases Quads, pero muchos de los emuladores muestran el wireframe de lo que hace la GPU y NO de los paquetes enviados (el verdadero polycount).
Y se suele cometer el error de que a lo mejor el emulador te muestra 1500 polígonos (refiriéndose a los paquetes enviados) y como el wireframe se ve en triángulos se piensa “pues eso equivale a unos 750 quads” y muy probablemente no sea el caso.

A la CPU de PS1 siempre le conviene que se envíen Quads, porque se procesan más rápido, se subdividen más rápido y necesitas un paquete en vez de dos, lo que ocupa menos memoria. Habrá juegos que usan dos triángulos para representar un Quad por oscuras razones (o quizás desconocimiento en los primeros juegos) pero no debería ser la norma.

Yo he llegado a contar unos 1900 polígonos en Spyro (30fps a 512x240), usando el VRAM viewer de No$Cash, uno, a uno (sí un coñazo) pero estaba estudiando como hacía la subdivisión y los LODs y también quería ver que era factible en términos de polycount. En eso 1900 polis, se usaban Quads cuando se podían usar Quads, y triángulos cuando no había más remedio, así que la Saturn tendría que renderizar sus 1900 Quads (algunos deformados para crear triángulos) si quisiese renderizar los mismos modelos para este caso.

Esto es bastante interesante, gracias.

SuperPadLand escribió:El VDP2 tampoco hace milagros poligonales, ya has visto en este hilo para que sirve y en que géneros se le puede sacar partido, te imaginas un Wipeout o un plataformas 3D usando un plano 2D para renderizar los suelos? No es una simple cuestión de tener un segundo procesador, sino de que puede hacer ese procesador.

Claro, pero volvemos a lo de siempre: si haces un juego pensado para la arquitectura de otra plataforma, te vas a encontrar problemas. En cambio, coge Sonic R o Sonic Jam y verás lo bien que se usó el VDP2 para suelos inmensos.

Dudeman Guymanington escribió:

SuperPadLand escribió:El VDP2 tampoco hace milagros poligonales, ya has visto en este hilo para que sirve y en que géneros se le puede sacar partido, te imaginas un Wipeout o un plataformas 3D usando un plano 2D para renderizar los suelos? No es una simple cuestión de tener un segundo procesador, sino de que puede hacer ese procesador.

Claro, pero volvemos a lo de siempre: si haces un juego pensado para la arquitectura de otra plataforma, te vas a encontrar problemas. En cambio, coge Sonic R o Sonic Jam y verás lo bien que se usó el VDP2 para suelos inmensos.

Porque a partir de ciertas fechas los juegos se hacían pensando en PSX con transparencias o luces que lastraban mucho en Saturn y no aprovechaban planos o memoria ROM.
Si ya has hecho el juego en PSX y te encargabas del port a Saturn, ¿para que molestarse en añadir algo que mejorará el juego?
Se podía usar para mejorar la IA de enemigos, para hacer efectos extra, etc.. No les merecía la pena muchas veces

varios escribió:

Dudeman Guymanington escribió:

SuperPadLand escribió:El VDP2 tampoco hace milagros poligonales, ya has visto en este hilo para que sirve y en que géneros se le puede sacar partido, te imaginas un Wipeout o un plataformas 3D usando un plano 2D para renderizar los suelos? No es una simple cuestión de tener un segundo procesador, sino de que puede hacer ese procesador.

Claro, pero volvemos a lo de siempre: si haces un juego pensado para la arquitectura de otra plataforma, te vas a encontrar problemas. En cambio, coge Sonic R o Sonic Jam y verás lo bien que se usó el VDP2 para suelos inmensos.

Porque a partir de ciertas fechas los juegos se hacían pensando en PSX con transparencias o luces que lastraban mucho en Saturn y no aprovechaban planos o memoria ROM.
Si ya has hecho el juego en PSX y te encargabas del port a Saturn, ¿para que molestarse en añadir algo que mejorará el juego?
Se podía usar para mejorar la IA de enemigos, para hacer efectos extra, etc.. No les merecía la pena muchas veces

Hombre, eso es un poco pillado con pinzas. Da la sensación de que se metía buena iluminación o trasparencias por joder y no porque realmente los juegos 3D lo necesiten para lucir mejor (algo que sigue pasando hoy en día). Otra cosa sería que la SS fuese la consola de moda y lastrase a PS1 y N64 porque los ports pasasen de esas mejoras (algo que sí pasó con PS2 vs Xbox por ejemplo).

Y lo de los otros usos que dices que "podría" vamos a comprar que efectivamente las thirds pasaron del tema, pero tienes juegos de SEGA que usan correctamente ambos VDP y su uso no va por ahí sino por adaptar sus capacidades 2D para simular malamente efectos 3D.

Dudeman Guymanington escribió:

SuperPadLand escribió:El VDP2 tampoco hace milagros poligonales, ya has visto en este hilo para que sirve y en que géneros se le puede sacar partido, te imaginas un Wipeout o un plataformas 3D usando un plano 2D para renderizar los suelos? No es una simple cuestión de tener un segundo procesador, sino de que puede hacer ese procesador.

Claro, pero volvemos a lo de siempre: si haces un juego pensado para la arquitectura de otra plataforma, te vas a encontrar problemas. En cambio, coge Sonic R o Sonic Jam y verás lo bien que se usó el VDP2 para suelos inmensos.

Pues tendría que mirar esos juegos porqué no sé si usa el VDP2 para suelos ¿Tienes alguna review técnica a mano por ahí?