SEGASaturno - Saturn, SEGA y Videojuegos

Yo creo que para determinados tipos de juegos 3d saturn es muy potente.
Si puedes usar planos del VDP2 para los escenarios y el suelo o lo que sea te ahorras un monton de poligonos que se pueden usar para otras cosas y estos poligonos pueden tener mejores texturas al tener que dibujar menos el VDP1 y el resultado de usar planos del VP2 suele ser mejor que con poligonos incluso de psx eso se puede ver en juegos que estan en psx y saturn como el grandia lo que saturn hace con el vdp2 psx tiene que hacerlo con poligonos y suele estar peor, sobretodo las texturas. Ademas si se usa para el suelo no existe el efecto de dibujado en el horizonte, al menos en el suelo y así se puede esconder mejor el poping.
los efectos que hace el VDP2 son muy buenos. Ejemplos los suelos y agua con VDP2 de los panzer dragoon o los escenarios del last bronx. De hecho el fill rate de saturn es superior al de psx si sumamos el vdp1+vdp2 pero inferior si miramos solo el vdp1.


Vamos que para segun que juegos saturn sería incluso mejor que psx en 3d. Ahora si, si todo tienen que ser triangulos como en Gran Turismo por ejemplo en eso si que gana psx pero para juegos en los que saturn pueda usar el VDP2 de forma intensiva y coherente como los panzer dragoon yo creo que el resultado es mejor en saturn y sigue siendo 3d a fin de cuentas un plano del VP2 tambien es un poligono y se puede mover en todas las dimensiones.

Y sobre lo de la dificultad para programar para 2 cpus, eso lo compro a medias, hay montones de recreativas de sega y no de sega que usan doble cpu y no veo que Yu Suzuki se haya quejado solo de la ST-V. Vamos que saturn no fue ni de lejos la primera maquina de juegos con doble cpu. Es evidente que es mejor una cpu unica si esta tiene la misma potencia que la suma de las otras dos pero no es el caso los dos SH2 en conjunto son mas potentes que la cpu de psx. La ventaja en 3d de psx esta en el "geometry engine" no en la cpu.

Una pregunta ¿Alguien sabe si el DSP de saturn se puede usar para calculos de geometria? ¿Algún juego lo ha usado? Porque en el Atari Falcon si se puede y la mejora es enorme.

LIV escribió: [Ver mensaje]

Una pregunta ¿Alguien sabe si el DSP de saturn se puede usar para calculos de geometria? ¿Algún juego lo ha usado?

Sí que se puede usar para operaciones matriciales, y según segaretro su rendimiento en MIPS es superior al de los dos Hitachi SH-2 juntos:

Citar:

SCU DSP

- SCU math coprocessor: Geometry DSP @ 14.31818 MHz, 32‑bit fixed‑point instructions. Parallel units: 32/48-bit ALU (arithmetic logic unit), 48/64‑bit Multiplier, 32-bit instruction decoder.

- Instructions: 6 parallel instructions/cycle (one instruction per unit/bus), 85.90908 MIPS (6 MIPS/MHz).

- Capabilities: Matrix and vector calculations, 3D point transformations, lighting calculations, fixed-point calculations, faster than SH-2, can use DMA to directly fetch and store vertex data, floating-point operations, geometry transformations, voxel rendering acceleration, fast coordinate transformations, lighting computations, transparency calculations.

https://segaretro.org/Sega_Saturn/Technical_specifications

Recomiendo la lectura del artículo a los interesados en el hardware de la Saturn. Resulta que la potencia de cálculo combinada de los dos SH-2 es de 74.454536 MIPS (37.227268 MIPS cada uno). Teniendo en cuenta que para el cálculo de geometría en el mejor de los casos ni siquiera van a utilizartoda la potencia de un solo procesador, las más de 80 MIPS potenciales del DSP se antojan como un caramelito muy a tomar en cuenta.

La pregunta del millón es; ¿si su capacidad del cálculo era tan potente, porqué no se utilizó más a menudo?

Y yo me respondo con lo único que he encontrado, de nuevo en Segaretro:

Citar:

Notas: Solo se puede programar con lenguaje ensamblador, más difícil de programar que SH-2

Sólo admite que le metan mano mediante ensamblador, el cual tiene un "dialecto" todavía más jodido que el del Hitachi SH-2. Recordemos que ni siquiera el mismísimo Yu Suzuki se atrevía a meterse totalmente a pelo con el ASM de los SH-2, programando gran parte del código en C, no me quiero ni imaginar lo que será intentar lidiar con este DSP face to face.

Respondiendo a tu otra pregunta decirte que supuestamente Grandia utiliza el DSP para apoyarse, aunque no sabría concretarte en para qué, pero vamos, polígonos hay y muy sólidos para lo que se estilaba en esa generación:



Lo comentó Wesker hace muchos años en este hilo, aunque parece confundirlo con el Yamaha, ahora mismo me hace dudar:

http://www.segasaturno.com/portal/v...&t=4388&start=9

Y si preguntas hoy día en SEGA-16 mucha gente dirá lo mismo. Quizás los emuladores puedan ayudarnos a concretar más al respecto.

Sobre el resto de tu comentario bueno... No quisiera convertir este hilo en el enésimo y tóxico "Saturn VS PlayStation". Sólo decirte que efectivamente en la consola de SEGA hay que hacer distinción entre usar a saco el VDP1 para la geometría de todo el entorno (contexto en el que queda en inferioridad frente a PS), y emplear sabiamente el combo VDP1 + VDP2 para generar la escena completa, que es cuando el potencial de Saturn florece en todo su esplendor.

Porque un entorno "3D" no sólo tiene porqué estar compuesto al 100% con formas poligonales:



En esta imagen los únicos polígonos/quads que hay son los de los luchadores. El resto son bitmaps 2D con efecto de volumen generados por el VDP2 los cuales va escalando y/o rotando, incluído los pseudo vectores 3D del suelo, y lo cierto es que quedan de puta madre.

En cambio en Tekken 3 si bien vemos personajes mejor modelados, animados, y sombreados, con algún que otro efecto de transparencia en los golpes, los escenarios son postales 2D pegadas al fondo, lo cual provoca una impresión bastante cutre a día de hoy:



Son formas distintas de componer la escena tridimensional.

Si sólo usas polígonos PlayStation normalmente dará mejores resultados por defecto.

En cambio si combeas ambos Vdps con tino, Saturn no sólo se pone a la par en términos visuales, sino que hasta puede ofrecer resultados más atractivos en determinados contextos.

Yo no se mucho de cosas tecnicas pero me ha agradado mucho ver este post, es bueno aprender todos los pormenores tecnicos de Saturn.

Ahora bien me quedo con este comentario de Jasvy.

Jasvy escribió: [Ver mensaje]

En su día los equipos de desarrollo no tenían mucha información ni herramientas. Pero lo que menos tenían era tiempo. Dale tiempo a un equipo de desarrollo y te sobrepasará el techo técnico de cualquier cosa lanzado en el ciclo de vida comercial de una consola. Precisamente el problema de Saturn era que sacar buenos resultados requería mucho más tiempo y esfuerzo que hacerlo en PSX. Pero con tiempo... se podrían hacer cosas muy buenas, claro que sí. Tiempo para pasar a ASM cualquier código, para optimizar al máximo el uso de los buses, para estudiar de cero y sin presiones temporales cómo utilizar de la mejor manera los dos chips gráficos y los dos procesadores.

Pero aún así hay que tener en cuenta que la infernal arquitectura de Saturn siempre será un obstáculo.

Un ejemplo claro de esto lo hizo el Sonic Team en su vida con Sega Saturn, quizas por ser el equipo de los mayores hits comerciales de Megadrive es que tuvieron mayor margen de trabajo, para que hasta pudieran no pensar en Sonic por un par de años.

Consideremos por ejemplo la creacion de Nights tomo un poco mas de un año, cuando la mayoria de estudios no tenian tanto tiempo de desarrollo, ni digamos del Desarrollo de Burning Rangers que si bien ahi el equipo se dividio en dos ya que se inicio a trabajar en Sonic Adventure tambien primero para Saturn y luego que pasarlo a Dreamcast, pero hablamos de un desarrollo que duro casi dos años, ni decir el de Sonic que duro mas tiempo con todo y su mudanza de plataforma.

Siendo que Sega ahi peco un poco de falta de paciencia, si tenian que vender su consola, y hacer juegos pero para eso estaba tener una mejor relacion comercial con las Thirds sin decir de cosas ya dichas como la publicidad entre otras cosas, la verdad ver todos esos factores deja mucho que pensar.

Hace poco descubrí un dato interesante; resulta que a mí siempre me extrañó que conversiones desde placas supuestamente inferiores como la SEGA Y-Board funcionasen a 30 fps en Saturn, mientras que los originales corren a 60 gloriosos frames.

Son los casos de Power Drift:




Y Galaxy Force 2:




El cual además también sufre ralentizaciones extra. Ambos ARCADES de 1988.

Al principio pensé que todo esto era debido a que estas conversiones no las hizo Rutubo Games, los cracks encargados de conversionar Out Run, Space Harrier, y After Bunner 2 para la Saturn con excelentes resultados. Pero cuando me puse a investigar un poco me di cuenta de que no era ese el problema, sino el VDP2 de la consola:



Resulta que a pesar de sus numerosas virtudes, el segundo procesador de vídeo en la Saturn sufre bastante intentando subir por encima de los 30 fps a la hora de mover, escalar, y rotar 2 planos de fondo con efecto tridimensional:

Citar:

El VDP2 dibuja planos infinitos en 3D de hasta 4096 × 4096 píxeles a 30 FPS.

https://segaretro.org/Sega_Saturn

Esto no significa que la Saturn sea débil, sino que la placa SEGA-Y era un MONSTRUO del scaling y la rotación para 1988:

Citar:

* Main CPU: 3× MC68000 @ 12.5 MHz (16-bit & 32-bit instructions @ 6.563 MIPS).

Planos gráficos; tres capas de sprites:

- Capa B-sprite (plano frontal): Prioridad en la parte superior, basada en el sistema de sprites System 16B (buffer de línea)

- Capa Y-sprite (plano posterior): se conecta a una rotación de pantalla completa, relleno grande , framebuffers de doble buffer (basados ​​en X Board) que pueden rotar completamente
Capa de gradiente de cielo (fondo): plano de mapa de bits

- Capa de degradado de cielo (fondo): plano de mapa de bits.

Capacidades de sprite / texturas, lista de sprites, sombras y resaltados, desvanecimiento de paleta, rotaciones de color, diferentes niveles de luminosidad, zoom y escalado de sprites completos en ambos planos de sprites, rotación completa de framebuffer sprite en plano Y, doble buffer , doble buffer de línea de almacenamiento intermedio en el plano B (512 píxeles), buffer de marco de doble buffer en el plano Y.

Capacidad por plano:

- Sprites Y: 2048 sprites / texturas, 64 KB de RAM de atributo (32 KB bank por framebuffer), 16 bytes por entrada.

- B sprites: 256 sprites/texturas, 4 KB de RAM de atributo, 16 bytes por entrada.

- Sprites / texturas por segundo: 2176 (1 FPS) a 130,560 (60 FPS).

https://segaretro.org/Sega_Y_Board

Estamos hablando de un bicharraco que tiene tres Motorola 68000 a 12,5 MHz dedicados sabe Dios a qué, y que al igual que la Neo Geo sólo utiliza sprites a saco, ni planos de scroll ni hostias, puro fill rate de figuras.

No obstante a pesar de todo yo le doy cierto margen de beneficio de duda a la Saturn, después de todo el Out Run, otro "scaling racer" es capaz de correrlo a 60 fps, el doble que el original.

En el futuro tengo planeado mirar todos estos detalles con los emuladores, para precisar más acerca de como construye la Saturn el entorno escalable/rotable en las diferentes conversiones.

Nota: Dada la naturaleza "Wikia" de segaretro recomiendo su lectura con precaución, y contrastando en la medida de lo posible la información allí vertida.

Interesante, como siempre.

Esperamos más!

Yo también era de los que pensaban que el tema era por no tener al desarrollador adecuado. Sin ir más lejos, la versión Sega Ages de Galaxy Force II para Sega Saturn no es ni siquiera de desarrollo japonés, sino que la hicieron los húngaros de Appalosa Interactive (creadores de Ecco the Dolphin, entre otros).

De todas formas, con Rutubo Games detrás como fue en el caso de los otros Sega Ages igual se hubiera podido obrar el milagro.

Muy interesante la información que aportas Cyclops y veo que poco a poco vas moderando un poco tu mala percepción inicial respecto a las capacidades gráficas 3D de Saturn, en comparación con PSX.

Desde mi humilde opinión solo tengo una cosa clara, nunca sabremos cual es el techo de esta consola ....
No creo que ningún pequeño estudio sea capaz de sacar el máximo rendimiento a esta maquina con un bajo presupuesto, salvo que la misma Sega se animara a hacer algo ... igual que van a empezar a hacer mandos inalambricos.

Cyclops escribió: [Ver mensaje]

No obstante a pesar de todo yo le doy cierto margen de beneficio de duda a la Saturn; después de todo el After Bunner 2 rula a 60 fps en la consola:

Bien es cierto que en este caso el entorno es mucho menos complejo, pero de cualquier manera imagino que la Saturn compondrá la escena de la misma forma: Vdp1 para el plano de sprites, y Vdp2 para planos de fondo y marcadores.

Sin olvidarnos del Out Run, el cual en versión Saturn ofrece la posibilidad de jugarlo al doble de velocidad que la placa original (60 fps).

esas dos conversiones puedo dar fe que me impresionaron sus resultados, After Burner 2 en Saturn
es solidisimo y frenetico! lo de Power Drift me parecio una sorpresa, esperaba una conversion asi de potente.

Ciertamente la bestia consolera era un toro dificil de domar, es el ciclo natural de muchas consolas en general
donde las primeras entradas demuestran un potencial simple vs sus ultimos juegos ya cambiaron/superaron
con creces. Se me viene a la cabeza los relevos de memoria adicional que usaron y me hacen recordar
los trabajos de joyeria que se manda la PC Engine Duo con un hardware aun mas limitado y antiguo.

Nekketsu escribió: [Ver mensaje]

lo de Power Drift me parecio una sorpresa, esperaba una conversion asi de potente.

Ojo, que Power Drift en Saturn sigue siendo una delicia visual y un juegazo increíblemente divertido, simplemente sucede que la placa SEGA-Y es un MONSTRUO del scaling y la rotación, algo así como la versión 2D de la Model 3, y para igualar sus resultados habrá que hilar muy fino programando en la consola de SEGA.

Al final yo creo que se trata de con el equilibrio y acierto con el que combines ambos VDP, después de todo aún dando por bueno el hecho de que a la Saturn le cueste manipular varios fondos a 60 fps, Rutubo Games mejoró el rendimiento de la placa del Out Run en la versión para Saturn:


YouTube Link


Y vale que en este ARCADE el plano de la carretera no rota/vira de posición a vertical/diagonal en ningún momento, ni el hardware es tan potente como la Y-Board, pero acelerar el scaling de sprites hasta 60 fps no es moco de pavo, y el After Bunner 2 sí que gira el fondo y rula a 60 fps en Saturn:



Lo cual me lleva a preguntarme si en Rutubo Games usaban A SACO el VDP1 para casi todo fundiendo tasa de relleno y marginando al VDP2, viceversa, o bien eran unos magos combinando los dos procesadores gráficos; ¡Ah qué putada no tener Pc ahora para poder emularlos y ver cómo trabaja la Saturn!

Por otro lado está el Galaxy Force II, y aunque este sí que huele a conversión chapucera, sigue siendo sospechoso que las dos únicas conversiones desde la SEGA-Y adolezcan del mismo problema...

¿O es que acaso Out Run y After Bunner 2 en Saturn rulan un plano a 60 fps y otro a 30?

En cualquier caso yo le doy el beneficio de la duda a la 32 bits de SEGA para marcarse una conversión de Power Drift a 60 fps totales.

Hendrix Saturn escribió: [Ver mensaje]

Desde mi humilde opinión solo tengo una cosa clara, nunca sabremos cual es el techo de esta consola ....

Quizás en materia poligonal no, pero en cuanto a las posibilidades 2D de Saturn afortunadamente estas son Sota, Caballo, y Rey; simplemente tenemos que ordenar el puzzle y ver qué juegos fueron programados con el culo y cúales no. Los emuladores son una excelente herramienta para estos menesteres.

Nota: Reitero que toda la información que leáis en Segaretro la cojáis con «pinzas» y la contrastéis en la medida de lo posible, últimamente estoy viendo ediciones muy fanboys y sesgadas manipulando datos, cuando no inventándoselos, mezclando verdades con mentiras. Mucho ojo.

El Galaxy Force II de Saturn tambien es jodidamente espectacular a 60Hz.

Cyclops escribió: [Ver mensaje]

Nota: Reitero que toda la información que leáis en Segaretro la cojáis con «pinzas» y la contrastéis en la medida de lo posible, últimamente estoy viendo ediciones muy fanboys y sesgadas manipulando datos, cuando no inventándoselos, mezclando verdades con mentiras. Mucho ojo.

vamos Cyclops, quiero ver tu analisis de Fighters History Dynamite y de Groove on Fight, conversiones
bien poco populares pero muy bien trabajadas ese review me tienta observar con ese nivel detalle y cuidado
que le das.

Hace poco salió el último reportaje de Digital Foundry Retro dedicado a una franquicia de SEGA, en este caso hablamos de Panzer Dragoon, centrándose en sus dos primeras entregas, todos los ports y formas de poder jugarlos incluída la emulación:

https://www.youtube.com/watch?v=4GQ..._toocbU9cND7U-A

Dentro de su habitual línea de "autopsia" tecnólogica, me gustaría destacar como muestran el modo en que se empleó inteligentemente el hardware de la Saturn en estos juegos, repartiendo armónicamente la carga gráfica entre los dos procesadores de vídeo en la consola.

En Panzer Dragoon el VDP2 de la máquina (planos de fondo, outpout final, etc) se encarga de generar las superficies bajas tales como el agua, la línea de horizonte, y el plano del cielo:


(Chulísimo el efecto del oleaje únicamente a base de manipular el tilemap).

Esto que a muchos podrá parecerles una tontería es un ahorra-recursos de la hostia para la Saturn, ya que no gasta ni una pizca de la potencia del VDP1 para cálculos poligonales, ahorrándose este último toda su tasa de relleno para dibujar la geometría. En PlayStation hacer lo mismo gastaría mucho fill rate de su procesador gráfico, ya que la consola de Sony dibuja la escena ENTERA a base de triángulos indiferentemente de si está generando un entorno poligonal o bidimensional, además de tener que calcular todos los efectos de oleja/rotación/escalado con un mismo chip mientras que en Saturn lo hacen entre 2, por lo que un port de PD a PS se antoja muy difícil ya que las cosas que Saturn hace por separado la Play las tendría que hacer a golpe de fundir tasa de relleno de su chip gráfico, la cual es superior a las del VDP1 y VDP2 por separado ojo, pero cuando se combinan con inteligencia la cosa se equilibra bastante.

En cambio a la consola de SEGA lo único que le cuesta es un background de fondo que ocupa apenas unos kb en la memoria de vídeo, y un plano infinito que el VDP2 escala o rota a placer sin despeinarse:


(Haters gonna hate!!!).

Y con esta "tontería" ya tiene la mitad de la escena dibujada con su rendimiento geométrico INTACTO

Por su parte el VDP1 libre de esas otras tareas se concentra exclusivamente en dibujar los polígonos, texturizarlos, y generar sprites/patrones de marcadores/texturas sueltas:


(Muy curioso el modo en que emplean texturas deformadas para simular el reflejo distorsionado en el agua).

Lamentablemente a pesar del buen juicio y creatividad con los que los diseñadores utilizaron los dos procesadores gráficos, se nota que Panzer Dragoon es un juego de primera hornada para la Saturn, ya que comparte el mismo defecto que otros contemporáneos suyos dentro del sistema como puedan ser Daytona U.S.A, o Tomb Raider; un frame-rate muy bajo que en raras ocasiones sobrepasa los 20 fps:


(Por suerte para controlar a un dragón de movimiento lento y "orgánico" 20 fotogramas por segundo son más suficientes para una buena experiencia).

Se notaba que todavía no le tenían cogido el punto cara a organizar los Hitachi SH-2 trabajando juntos en las fases de aplicación y transformación; recordemos que hasta el mismísimo Yu Suzuki tardó en cogerles el "tranquillo", ya que sus dos primeros trabajos al sistema resultaron ser conversiones muy mediocres en lo técnico, mientras que en Virtua Fighter 2 ya demostró estar más ducho sacándole jugo al sistema. Imagino que también tendría que ver el hecho de no disponer aún del nuevo sistema operativo que llegaría un año más tarde.

Sin embargo Panzer Dragoon Zwei es un ejemplo de lo contrario; título de segunda hornada que al igual que otros juegos de 1996 como Daytona U.S.A Championship Circuit Edition, mostraron un rendimiento muy superior a sus predecesores, demostrando que la Saturn todavía una consola a explotar. Concretamente PDZ subió la tasa de fotogramas hasta 30 fps en juego, y nada menos que a 60 fps en las cut-scenes generadas por el motor del juego. Pero lejos de quedarse ahí, lo más impresionante de todo es que partiendo de un uso similar de los VDPs al de su primera parte, Panzer Dragoon Zwei también ponía en pantalla mayor número de polígonos que la anterior entrega:


(Cielo, horizonte, y suelo desaparecen porque desactivan a propósito el VDP2, no es ningún bug).

Es que me parece exagerado que aun habiendo aumentado la velocidad del juego hasta 30/60 fps dependiendo del contexto, todavía les sobrase capacidad de proceso para incrementar también la geometría, es que no me jodas, o pulieron muchísimo el código, o bien... ¿emplearían el misterioso DSP para algunos cálculos?. Miedo me da averiguar que lograron en el Panzer Dragoon Saga.

Cuando tenga tiempo me hago unos GIF del uso salvaje que le dieron al VDP2 en Panzer Dragoon Zwei; festival de escalados, rotaciones, y efectos flipantes.

Nekketsu escribió: [Ver mensaje]

Cyclops escribió: [Ver mensaje]

Nota: Reitero que toda la información que leáis en Segaretro la cojáis con «pinzas» y la contrastéis en la medida de lo posible, últimamente estoy viendo ediciones muy fanboys y sesgadas manipulando datos, cuando no inventándoselos, mezclando verdades con mentiras. Mucho ojo.

vamos Cyclops, quiero ver tu analisis de Fighters History Dynamite y de Groove on Fight, conversiones
bien poco populares pero muy bien trabajadas ese review me tienta observar con ese nivel detalle y cuidado
que le das.

Mientras tanto aquí te dejo el gameplay @60Hz


YouTube Link

Cyclops escribió: [Ver mensaje]

Nekketsu escribió: [Ver mensaje]

lo de Power Drift me parecio una sorpresa, esperaba una conversion asi de potente.

Ojo, que Power Drift en Saturn sigue siendo una delicia visual y un juegazo increíblemente divertido, simplemente sucede que la placa SEGA-Y es un MONSTRUO del scaling y la rotación, algo así como la versión 2D de la Model 3, y para igualar sus resultados habrá que hilar muy fino programando en la consola de SEGA.

Al final yo creo que se trata de con el equilibrio y acierto con el que combines ambos VDP, después de todo aún dando por bueno el hecho de que a la Saturn le cueste manipular varios fondos a 60 fps, Rutubo Games mejoró el rendimiento de la placa del Out Run en la versión para Saturn:


YouTube Link


Y vale que en este ARCADE el plano de la carretera no rota/vira de posición a vertical/diagonal en ningún momento, ni el hardware es tan potente como la Y-Board, pero acelerar el scaling de sprites hasta 60 fps no es moco de pavo, y el After Bunner 2 sí que gira el fondo y rula a 60 fps en Saturn:

Spoiler: [ Mostrar ]

Spoiler: [ Ocultar ]

Lo cual me lleva a preguntarme si en Rutubo Games usaban A SACO el VDP1 para casi todo fundiendo tasa de relleno y marginando al VDP2, viceversa, o bien eran unos magos combinando los dos procesadores gráficos; ¡Ah qué putada no tener Pc ahora para poder emularlos y ver cómo trabaja la Saturn!

Por otro lado está el Galaxy Force II, y aunque este sí que huele a conversión chapucera, sigue siendo sospechoso que las dos únicas conversiones desde la SEGA-Y adolezcan del mismo problema...

¿O es que acaso Out Run y After Bunner 2 en Saturn rulan un plano a 60 fps y otro a 30?

En cualquier caso yo le doy el beneficio de la duda a la 32 bits de SEGA para marcarse una conversión de Power Drift a 60 fps totales.

Hendrix Saturn escribió: [Ver mensaje]

Desde mi humilde opinión solo tengo una cosa clara, nunca sabremos cual es el techo de esta consola ....

Quizás en materia poligonal no, pero en cuanto a las posibilidades 2D de Saturn afortunadamente estas son Sota, Caballo, y Rey; simplemente tenemos que ordenar el puzzle y ver qué juegos fueron programados con el culo y cúales no. Los emuladores son una excelente herramienta para estos menesteres.

Nota: Reitero que toda la información que leáis en Segaretro la cojáis con «pinzas» y la contrastéis en la medida de lo posible, últimamente estoy viendo ediciones muy fanboys y sesgadas manipulando datos, cuando no inventándoselos, mezclando verdades con mentiras. Mucho ojo.

Muy buena e interesante info. Sea como sea son juegos que a 60Hz dan una sensación increíble de velocidad, sobretodo el OutRun:


YouTube Link



En cuanto a los Panzer Dragoon, son un buen ejemplo de la evolución del rendimiento. Del 1 al Zwei se nota toda esa mejoría de rendimiento gráfico y jugable:


YouTube Link



YouTube Link


Y ya empezaron a entrar a otro nuevo nivel de rendimiento... con morphings espectaculares, si hubiera tenido 2 años más de optimización las librerías y kits de desarrollo de SEGA se hubieran visto cosas muy tochas:


YouTube Link

Edit Se puede borrar

No soy moderador, y tampoco quiero sonar descortés, pero en adelante te agradecería que en este hilo no dobleposteases tan seguido en un mismo día después de que alguien se haya currado un aporte largo como he hecho yo esta misma mañana, debido a que se pierde el visonado enseguida innecesariamente. El gameplay de los Panzer Dragon podrías haberlo metido en el otro post simplemente editando.

Gracias, muy interesantes tus vídeos como siempre.

Ups, perdona. Lo he leído ahora mismo. Edito este último y que lo borren. Lo siento.

Edit Se puede borrar

Cyclops escribió: [Ver mensaje]

Es que me parece exagerado que aun habiendo aumentado la velocidad del juego hasta 30/60 fps dependiendo del contexto, todavía les sobrase capacidad de proceso para incrementar también la geometría,

Me acabo de quedar loco. ¿Que aun sobraba potencia? Estoy deseando ver el Saga. Realmente se le podría haber sacado mucho más jugo a la Saturn, no son sueños de fanboy XD

Me encanta este hilo!

Hay un salto de calidad brutal del primero al segundo. Al igual que otros videojuegos de Saturn.

Cyclops escribió: [Ver mensaje]

¿emplearían el misterioso DSP para algunos cálculos?. Miedo me da averiguar que lograron en el Panzer Dragoon Saga.

El misterioso DSP no lo es tanto, en el link que pasaste en posts anteriores de Sega Retro te dicen básicamente para que se debería usar:

Capabilities: Matrix and vector calculations, 3D point transformations, lighting calculations, fixed-point calculations,[49] faster than SH-2,[52] can use DMA to directly fetch and store vertex data, floating-point operations, geometry transformations, voxel rendering acceleration, fast coordinate transformations, lighting computations,[53] transparency calculations[54]
Notes: Can only be programmed with assembly language, more difficult to program than SH-2[49]

Y digo "debería usar" pues lo más probable es que casi ningún estudio externo a Sega lo utilizase, dadas las dificultades para programar en él. Ya lo he pasado antes, pero recomiendo encarecidamente la lectura de siguiente blog para entender en que condiciones se programaba para la arquitectura paralela de Saturn: "The target machine is the Sega Saturn, which has two SH2 Risc microprocessors and one 68000. Currently we only use the Master SH2, the slave SH2 will be used when we get around to figuring out how" que en español viene a significar “La máquina de destino es Sega Saturn, que tiene dos microprocesadores SH2 Risc y un 68000. Actualmente solo usamos el Master SH2, el esclavo SH2 se usará cuando descubramos cómo“ (http://cowboyprogramming.com/2010/0...he-sega-saturn/).

El problema de Saturn no fue su potencia y si me apuráis, tampoco lo fue su arquitectura, su verdadero problema fue el hecho de que Sony (con Namco y Psygnosis como actores principales) se esforzaron para reventar a Sega el modelo de generación que tenían previsto para Saturn.

hace relativamente poco, Ben Heck sacó un video en youtube, donde desarma una Saturn y hace un conteo de todos los procesadores y... memoria que tiene disponible la consola... Resulta que la Saturn, señores, tiene 4,2 megabytes de ram, superando incluso a la Nintendo 64 en ese apartado...


sin embargo están horriblemente distribuidos en fragmentos que dejan pocas puertas abiertas a cualquier tipo de optimización. Una lástima... y sobre todo, un desperdicio de recursos

Stratoslava escribió: [Ver mensaje]

hace relativamente poco, Ben Heck sacó un video en youtube, donde desarma una Saturn y hace un conteo de todos los procesadores y... memoria que tiene disponible la consola... Resulta que la Saturn, señores, tiene 4,2 megabytes de ram, superando incluso a la Nintendo 64 en ese apartado...


sin embargo están horriblemente distribuidos en fragmentos que dejan pocas puertas abiertas a cualquier tipo de optimización. Una lástima... y sobre todo, un desperdicio de recursos

Yo justo lo que no me creo es eso que comentas y que tantas veces hemos hablado por aquí. No creo que el hardware de Saturn no pudiese ser optimizado. Creo que a la consola la faltó tiempo de desarrollo (aprendizaje del modelo RISC + arquitectura paralela) y herramientas de desarrollo mejores (SGL+ y que estuviese disponible para Third Partys), pero no tengo ninguna duda de que en una hipotética Saturn con 6 años de vida (en vez de 2/3) y con unas ventas totales similares a las de Mega Drive los resultados tanto en 2D como en 3D no fuesen mucho mejores de lo que vimos (ojo, que ya fue bastante).

Nextmare escribió: [Ver mensaje]

Stratoslava escribió: [Ver mensaje]

hace relativamente poco, Ben Heck sacó un video en youtube, donde desarma una Saturn y hace un conteo de todos los procesadores y... memoria que tiene disponible la consola... Resulta que la Saturn, señores, tiene 4,2 megabytes de ram, superando incluso a la Nintendo 64 en ese apartado...


sin embargo están horriblemente distribuidos en fragmentos que dejan pocas puertas abiertas a cualquier tipo de optimización. Una lástima... y sobre todo, un desperdicio de recursos

Yo justo lo que no me creo es eso que comentas y que tantas veces hemos hablado por aquí. No creo que el hardware de Saturn no pudiese ser optimizado. Creo que a la consola la faltó tiempo de desarrollo (aprendizaje del modelo RISC + arquitectura paralela) y herramientas de desarrollo mejores (SGL+ y que estuviese disponible para Third Partys), pero no tengo ninguna duda de que en una hipotética Saturn con 6 años de vida (en vez de 2/3) y con unas ventas totales similares a las de Mega Drive los resultados tanto en 2D como en 3D no fuesen mucho mejores de lo que vimos (ojo, que ya fue bastante).

Dicho mal y pronto:

Supongamos que transitamos en una autopista que se hizo con muchas luces, señalizaciones, autoservicios, puestos de comidas rápidas... pero como el mandato se acababa en poco tiempo, el presidente de turno dijo "muchachos, sale como sale" y la bellísima autopista, llena de cosas muy útiles... acabó teniendo un solo carril... encima de todo, muy angosto.

Con nuestro coche gama média, en los años '90, la pista siempre parece está super congestionada y avanzamos a una velocidad promedio de 60km/h.


Año 2020: la autopista sigue siendo la misma, pero le buscaron la vuelta para intentar mejorar la circulación... pero la estructura sigue siendo la misma. Los autos son más veloces y seguros... pero como la autopista sigue teniendo un solo carril, sigue teniendo los mismos problemas que hacía 30 años atras, sólo que ahora los autos marchan a 75km/h

Analogías... ¡cómo no amarlas!

Finalmente me he decidido a traducir la información más interesante de la url que pasé anteriormente (http://cowboyprogramming.com/2010/0...he-sega-saturn/) del blog de Mick West (desarrollador de Skeleton Warriors en la compañia Neversoft) y después comentaré mis impresiones al respecto.

Cowboy Programming escribió: 

1995 Programación en Sega Saturn por Mick West

Este es un documento que escribí en 1995, mientras trabajaba en el primer juego de Neversoft: Skeleton Warriors. Fue el primer juego en el que trabajé y no utilicé el juego de instrucciones de Motorola 68K.
La foto me muestra en el trabajo alrededor de ese momento. El kit de desarrollo de Saturn (la "Caja pequeña" y el ICE) está a la derecha.

El hardware de desarrollo
La máquina de destino es Sega Saturn, que tiene dos microprocesadores SH2 Risc y un 68000. Actualmente solo usamos el Master SH2, el esclavo SH2 se usará cuando descubramos cómo hacerlo. El 68000 se usa para controlar el chip de sonido, no deberíamos escribir ningún código ya que utilizaremos la biblioteca de sonido suministrada por Sega.

El programa está escrito casi en su totalidad en C. Usamos el compilador GNU SH2 para producir la salida del conjunto SH2. Hay algunos módulos SH2, la mayoría limitados a datos puros. Aún no he escrito nada significativo en SH2.

El sistema de desarrollo que usamos es PsyQ. Este no es el sistema de desarrollo estándar de Sega, sin embargo, se considera que es el mejor para todos los que lo han probado. El sistema alternativo es SNASM, por Cross Products, que es propiedad de Sega. La mayor parte del código de muestra proporcionado por Sega está destinado a ejecutarse en el sistema de desarrollo SNASM, sin embargo, es fácilmente convertible a PsyQ.

El sistema PsyQ consiste en una placa de interfaz SCSI que instalas en el PC, un cartucho que se conecta a la Saturn, y un cable para conectar a los dos. El código fuente se compila en el PC y se descarga a Saturn donde se ejecuta. El código se puede depurar desde el PC.

El enlace está controlado por un programa TSR (PSYBIOS) que maneja las comunicaciones entre las máquinas. También permite que Saturn cargue archivos desde el PC de la misma forma que los cargaría desde el CD. Usamos esta característica para cargar los archivos para cada nivel.

Mick también tiene un par de cajas grandes y ruidosas en su habitación. Él también tiene dos PC. El más pequeño de los dos es un E7000PC, que es un Emulador de Circuito Inicial SH2, útil para indicar dónde ha fallado el programa si el depurador PsyQ no lo detiene. También es útil para ver las escrituras de memoria, pero todavía no lo he usado.

La segunda de las cajas ruidosas es lo que se conoce como "caja pequeña" (la "caja grande" original era aproximadamente del mismo tamaño que una nevera pequeña). Esto es esencialmente una Saturn, con interfaces adicionales para el E7000 y para el emulador de CD. También tiene interruptores en la parte delantera para cambiar la identificación del país y para cambiar entre PAL y NTSC.

El emulador de CD es lo que la otra computadora tiene dentro. Un tablero grande que utiliza el disco duro de la computadora para pretender ser una unidad de CD. Puedes construir una imagen de CD en esto y emular en modo de tiempo real para ver cómo se verá el juego cuando llegue al CD. Esto parece funcionar casi en cierta medida, aunque hay algunos problemas con los que estoy trabajando con Sega para tratar de resolverlos.

Me resulta especialmente interesante este relato de Mick West, por tratarse de un programador occidental trabajando en 1995, en el texto habla del día a día en el desarrollo para Saturn y, como podréis comprobar a continuación, programar era casi una odisea.



Lo primero que quiero resaltar es que Skeleton Warriors es un juego de Acción en 2D, que probablemente sería ostensiblemente mas sencillo de programar que los juegos 3D que podrían llevar al límite técnico al sistema (que son los que queremos tratar en este hilo). La fecha de lanzamiento de Skeleton Warriors según Sega Retro fue abril de 1996 en USA y septiembre de 1996 en Europa, el juego no fue lanzado en Japón. Nótese que el juego salió a la venta ya bien avanzado el periodo de vida de la consola.

El desarrollador pone de manifiesto la dificultad para adaptarse a trabajar con SH2 (arquitectura RISC), cuando anteriormente siempre había estado trabajando con Motorola 68K (arquitectura CISC) (Mega Drive llevaba uno de estos, entre muchos otros sistemas). Si la adaptación de 68K a SH2 no tiene que ser sencilla, no me quiero ni imaginar lo que sería para los programadores pasar a trabajar con dos SH2 en paralelo, al menos durante los primeros años.

Básicamente viene a decir que el juego está siendo desarrollado completamente en C y que únicamente está utilizando uno de los procesadores SH2. Y aquí quiero incidir, no está utilizando el SH2 esclavo porque ¡¡¡no sabe cómo hacerlo!!!, es decir, no habla de un problema de arquitectura del sistema, ni de un problema de rendimiento, si de problemas de sincronización de los SH2, si de falta de capacidad de los buses de datos, todo es mucho más básico, tenía problemas para hacer funcionar el código en paralelo, probablemente porque en la documentación de desarrollo de la que disponía no venia bien detallado.

Otro de los aspectos que se tratan en el texto es la información al respecto de los equipos de desarrollo. Este suele ser un tema bastante desconocido para los aficionados, a nivel personal, tengo la suerte de tener un amigo que trabajó de betatester para Sega América y me ha explicado más menos cual fue la situación con Saturn, lo que me permite entrar un poco en detalle sobre lo que habla Mick West en el texto:

Cuando Mick West habla de “small box” se refiere al dev kit Saturn Sophia:



Comenta dos cosas negativas que ya me había dicho mi amigo tester:

1º - Se trataba de un sistema bastante ruidoso (mucho) que hacia que trabajar con él fuese un suplicio.
2º - El sistema producía “crashes” con cierta frecuencia.

Añado un tercer punto que no lo comenta Mick West pero que sí me comentó mi amigo:

3º - Saturn Sophia era un sistema bastante caro de adquirir para realizar el trabajo, sin entrar en cifras, costaba tres veces más que el devkit necesario para programa/testear en PSX.

Este kit de desarrollo se tuvo que utilizar hasta mediados de 1995, que salió el segundo kit de desarrollo oficial de Saturn: Saturn CartDev (https://segaretro.org/Saturn_CartDev). Nótese que en Sega Retro comentan que incluso la primera versión de este segundo kit de desarrollo no era muy confiable, sin embargo, es con este kit de desarrollo donde los estudios comienzan a sacar todo el potencial de la arquitectura paralela de Saturn.



Sí, lo habéis adivinado, los que tenían Saturn Sophia y querían actualizarse al Saturn CartDev tenían que pasar por caja y pagar un coste bastante alto del sistema. Lo que nos lleva al siguiente Dev Kit: Sega Saturn PSY-Q dev kit, que es el que utilizaba Mick y el que utilizó Psygnosis para realizar sus ports a Saturn (http://www.psygnosis.org/history/SATURNPSYQ/), luego los resultados eran los que eran.

NOTA: Si no me equivoco, este es el kit de desarrollo que me enseñó nuestro admin, Ryo Suzuki, en una de las primeras ediciones de Retro Barcelona.

También habla el artículo del Hitachi E7000P, y por lo que comenta Mick, se trata de un accesorio que se podía conectar al Sophia y al PSY-Q.



EN CONCLUSIÓN: El articulo nos muestra que el panorama para un desarrollador externo a Sega en Saturn era absolutamente complicado, así salieron los ports que salieron, que daban la sensación de que Saturn era mucho menos capaz que Playstation y creo toda esta situación debemos tenerla en cuenta a la hora de analizar el “Potencial Teórico VS Realidad”, porque la visión sencilla es la de pensar que la arquitectura hardware de Saturn está mal diseñada, pero eso no está nada claro, de hecho, mi percepción personal como alguien que está cursando la ingeniería informática, es que el diseño de la arquitectura de Saturn es bastante bueno y que los principales problemas de Saturn fueron otros.

Muy, pero que muy buen aporte Nextmare. Voy a estar unos días sin poder postear mucho, así que no puedo ahora mismo explayarme a gusto.

No estoy de acuerdo en una cosa que ya debatiremos, pero de hecho en tu propio post se está ejemplificando que la Saturn tiene un serio problema de diseño en un punto concreto, al margen de que también influyesen otros factores para que a los programadores ajenos a SEGA les costase pillarle el tranquillo.

Cuando pueda entro en detalles

El diseño de Saturn tiene el problema del acceso a bus. Punto. Las arquitecturas multi core de hoy en día hacen auténticas virguerías para evitar este tipo de problemas.

Yo soy ingeniero informático y profesionalmente estoy especializado en temas de monitorización de sistemas (entre otras cosas que no vienen al caso). Me peleo a diario con sistemas enormes multi-CPU. En grandes empresas no es raro ver sistemas de 32 CPUs, por ejemplo. Los sistemas multi-CPU tienen muchísimas ventajas, es evidente, pero hay algunas normas que aplican y que muchas veces llevan a problemas. Por ejemplo, aún hoy en día, el código de un único ejecutable se diseña normalmente para ejecutar en una única CPU. Eso significa que puedes tener un problema de rendimiento en un proceso que haga que una CPU se ponga al 100% y el proceso no responda o lo haga muy lentamente, y sin embargo el sistema como tal puede estar, como se dice, tocándose los pies. El resto de CPUs pueden estar prácticamente ociosas. Para evitar este tipo de problemas se dividen los procesos en distintos hilos de ejecución (multi-thread) o directamente en procesos diferenciados que tengan distintas funciones y luego interactúen entre sí de distintas maneras. De hecho, a veces se piden varias CPUs no por un tema de rendimiento, sino para garantizar que en caso de problemas de rendimiento el proceso se coma una CPU y no tire el sistema al completo. Este tipo de división en varios hilos a día de hoy NO la hace el sistema operativo. Es algo que se hace al programar, a nivel de diseño del proceso. Y ya os digo que muchas veces no se hace. Estamos hablando de 2018, cuando llevamos décadas con arquitecturas multi-CPU y las herramientas están más que pulidas. Os sorprendería la cantidad de aplicaciones profesionales que valen un dineral que NO están preparadas para multi-thread. Y eso que hoy en día los buses no son un problema (al menos en sistemas profesionales) y la memoria... tampoco a poco que la empresa quiera tener las cosas en condiciones.

Así que puedo imaginarme que, en 1995, sin apenas documentación, sin experiencia en sistemas con varias CPUs, programar para la arquitectura de Saturn de forma eficiente debía ser extremadamente difícil. Es fácil echarle la culpa a los kits de desarrollo de Sega, pero muy probablemente la propia Sega no tenía ni idea de cómo sacar provecho a sus dos CPUs, sobre todo teniendo en cuenta que ambos procesadores no podían acceder a memoria a la vez por su evidente problema de acceso a los buses. Claro que los programadores hubieran deseado tener documentación detallada sobre cómo sacar el potencial a la consola... pero es que dudo que nadie, ni en la propia Sega, supiera cómo hacerlo. Ya os digo que a día de hoy muchas de las aplicaciones profesionales se siguen realizando con un único hilo, y sólo aprovechan varias CPUs porque realmente suelen componerse de varios procesos funcionando a la vez (y el SO reparte los procesos por las CPUs como considera oportuno). Y eso que en los sistemas actuales cada CPU tiene su propio acceso a memoria...

No coincido contigo en muchas de las cosas que comentas Jasvi y no veo relevante comparar una arquitectura paralela como la de Saturn, la cual requiere ser optimizada al máximo, pues todo el software que se desarrolle va a funcionar sobre unas características hardware cerradas, con aplicaciones para servidores multiprocesador empresariales, las cuales no requieren ser optimizadas para una máquina concreta, deben funcionar lo mejor posible en diferentes arquitecturas multiprocesador y además, en muchas ocasiones, son ejecutadas en esas máquinas junto a otras aplicaciones que también consumen recursos.

Ojo, que tampoco estoy de acuerdo con Jroca en algunas de las cosas que comenta en su blog, como que los procesadores SH2 no puedan trabajar en paralelo “El mayor handicap del doble Hitachi SH2 es que compartían bus directo hacía el SCU/DMA y por lo tanto no podían trabajar en paralelo, por lo que cuando los datos no se encontraban en la cache por lo que un procesador acababa por limitar al otro a la hora de procesar.“ o con lo que comenta de la conversión de código de triángulos a cuadrados “Esta particularidad no era muy bien vista por los desarrolladores que veían como todo el motor 3D que tenían desarrollado para otras consolas tenía que ser re-pensado en el caso de Saturn, así como los modelados de personajes en 3D y demás.” ¿Qué hubiera pasado si Saturn hubiera vendido más que PSX de inicio y las conversiones hubieran tenido que ser de quads a triángulos? Hoy vemos los polígonos triangulares como un estándar, pero en 1994 ese estándar estaba por definir.

Pero, sobre todo, pongo en duda vuestras afirmaciones sobre el bus que conecta RAM como ambos SH2 por cosas como esta que comenta Yu Suzuki, que yo no soy capaz de poner en duda: “En AM2 usamos C para las primeras etapas, y ensamblador después de eso. Conseguimos mantener las CPUs gemelas corriendo a una velocidad 1.8 veces mayor que la velocidad en un sólo chip, eso habría sido imposible usando sólo C.”. Y que serían IMPOSIBLES con limitaciones como las que comentáis. Hagan ustedes la cuenta, si una CPU SH2 corre a 28.6MHz, entonces 28.6 X 1.8 = 51.48MHz, eso o Yu Sukuzi miente…

Pero ya os digo, que no se trata de tener o no razón, simplemente pongo en duda cosas que no veo claras y os animo a seguir buscando información, videos de uso del HW en emuladores o referencias bibliográficas de gente contrastada para seguir enriqueciendo este hilo, que me encanta lo que trata.

Pues fíjate, yo estoy de acuerdo con todo lo que dices y también mantengo todo lo escrito en mi correo... No veo que me contradigas en nada realmente.

Claro que Saturn (1994) no es comparable en global con un servidor corporativo de 2018. Por muchísimos motivos. Lo que estoy diciendo es que en 1994 las arquitectura multi-cpu eran algo bastante novedoso. Es una época en la que los sistemas operativos multiproceso eran la novedad (aunque los Mac los tenían hacía mucho). El avance desde entonces es enorme en ese sentido. Tanto a nivel de hardware como de software. No veas qué virguerías de pipelines multithreads que llevan los sistemas actuales... Saturn sin embargo no da ningún tipo de facilidades ni a nivel de hardware ni a nivel de software. Y lo que decía es que aún hoy, con las arquitecturas ultra-evolucionadas y varias décadas de experiencia sigue sin sacarse todo el partido teórico de las arquitecturas multi-cpu. Hoy en día no importa porque las máquinas tienen potencia para derrochar, y no importa tanto extraer toda la capacidad teórica, pero en 1994, en un sistema cerrado, sí. Pero era mucho más difícil sacar ese potencial que en una arquitectura mono-procesador. Ojo, el segundo procesador SIEMPRE es una ventaja. A las malas no se utiliza, pero su potencial siempre estará ahí. El problema de Saturn fue que la falta de experiencia de los desarrolladores y la completa falta de herramientas y documentación hizo que en muchos de los casos el segundo procesador no se utilizara, por lo que Saturn quedaba reducida de hecho a un sistema monoprocesador menos potente que la competencia. De ahí la gran diferencia entre los first party y la gran mayoría de los multis

Sí que digo es que el bus compartido era un enorme cuello de botella. Lo que dice Suzuki no es incompatible con que el bus sea compartido (que lo es). Fíjate que dice que la potencia teórica que él estima se de 180% respecto a usar un único SH2. Usando emsamblador y pensando muy bien el código. En teoría, en un sistema en el que ambos procesadores pudieran acceder a memoria en paralelo, ese rendimiento teórico sería más o menos de un 200%. Suzuki ya te está eliminando un 20% de ese rendimiento teórico , y eso que no era precisamente manco.

Ojo, si Saturn hubiera vendido como PSX se habría aprovechado al máximo, se habrían desarrollado tanto las herramientas como el conocimiento necesario para ello. Desde luego que tenían más potencial que el mostrado. Aunque tengo dudas de que lo que no llegó a mostrarse fuera una diferencia enorme, está claro que Saturn mantuvo un 20% por ciento inexplorado como mínimo.

Es que la diferencia entre potencial teórico y realidad puede ser grande. Mirad el caso de PS3. En teoría, sobre el papel, el Cell se iba a comer el mundo. En la realidad sólo le sacaron auténtico provecho los estudios internos de Sony y no al principio de la generación, precisamente. Es un caso bastante similar.

Me encanta este hilo. Un placer leeros!!

Como siempre me asombro de vuestros conocimientos...oleee!!!