¿Seria posible un port de Super Mario 64 en Saturn?

radorn escribió:Quizá alguien sepa responder si en Saturn el rendimiento de dibujado está sujeto a la resolución y hasta qué punto, o le da igual ... @EMaDeLoC ?

La verdad es que no he seguido el hilo y no puedo ir a puntos concretos. Tampoco puedo aclarar información más allá del manual del desarrollador de la Saturn, pero si puedo decir que su rendimiento esta sujeto a como se usen los sprites y que la resolución influye también.
En el caso de los sprites, cualquier dibujado que no sea 1:1 del sprite, es decir, cualquier dibujado que añada alguna transformación como escalado, o deformación por vertices, supone un desperdicio de ciclos de dibujado del VDP1 ya que un mismo pixel de pantalla puede ser pintado varias veces por distintos píxeles del sprite.
En cuanto a la resolución, no ya en Saturn, en cualquier sistema más resolución supone más recursos y tiempo de proceso. La única diferencia entre PS1, N64 y Saturn es cuanto de optimizadas están en su arquitectura y en mi opinión Saturn es la que mejor puede aguantar resoluciones mayores debido a memorias de texturas y frambuffer separadas cada una con su bus independiente al VDP1. Por lo que tiene un cuello de botella menor que tendría PS1 en ese aspecto, aunque la diferencia es muy pequeña.
No me olvido del VDP2, su capacidad de rotar planos esta por las nubes y posiblemente sea la parte del proceso gráfico más fuerte de la consola.
Creo que para la Saturn una mayor resolución no sería su problema principal de rendimiento, lo sería la forma de usar los sprites. Podrá manejar más sprites si estos no se transforman, y podrá manejar más sprites transformados si estos no se usan para un proceso 3D, para lo cual no son nada eficientes. Creo que un juego 2D de sprites sin transformar podría moverse al máximo de framerate al máximo de resolución, y si es cierto ese modo 480p, sería a 60fps.
Pero claro, habría que mirar otros aspectos de la consola como que la cantidad de RAM de texturas para un juego 2D en alta resolución es algo pobre y los sprites serían pequeños y poco variados. Vamos, que el resultado sería quizá menos vistoso, aunque técnicamente aprovechara al máximo la consola.

LINKr2 escribió:Por lo que veo la info sobre el Dinosaur King efectivamente era incorrecta ya que no es un juego de ST-V. En el manual de la placa recreativa ST-V pone claramente que la placa funciona a 15Khz y debe ser usada en un monitor acorde a esta frecuencia. Viendo que este modo de “31Khz” jamás fue usado durante la vida comercial de la Sega Saturn, lo mismo la placa ST-V ni si quiera contaba con la posibilidad.

No, estas equivocado, pero vuelta a lo mismo, no tengo como probarlo, pero el "juego" de las fotos existe, es real, yo llegue a meterle mano, y no llevaba un PC dentro, sino una Sega Titan STV, con monitor de 31khz.

Si conoces algo del tema arcades tendrias que saber que en la jerga se conoce (al menos en el ambiente en el que yo me muevo y en foros gringos principlamente) a estas mini maquinas de Sega como "dinokings" por mas que se hayan fabricado bajo otro nombre para otros juegos, es un caso similar a como se suele llamar a los muebles japoneses "CANDY" cabs cuando en realidad el unico mueble que llevaba ese nombre eran los "NEO CANDY" de SNK, y seria porque en su momento fueron muy populares entre usuarios y aficionados por lo que que se los empezó a llamar asi de forma general para referirse a este tipo de maquinas;

El mueble al que me refiero no es el del juego "dinosaur king" sino que el formato y especificaciones de éste siguen esa linea, pero como respondiste diciendo que "Eso no es posible " "El manual dice lo contrario" " no hay software para ese sistema que es solo para 15khz bla bla bla...." pues pense, yo a este tio no lo conozco personalmente y es probable que sea un ex operador y sepa de lo que habla para negar mis afirmaciones tan rotundamente, y entonces soy yo el que esta equivocado y la memoria me este jugando una mala pasada..... pues para tu información, he ido al deposito de un conocido ex operador a cerciorarme y si que hay varios de estos muebles que llevan de fabrica monitores Bi, tri y mono frecuencia a 31khz.

Y por ultimo, yo jamas he dicho que Saturn soportase modos a 24khz, asi que aqui por mi parte se podria terminar el offtopic, tu cree lo quieras creer, la verdad me da igual.

Pues nada, el manual técnico de la placa estará mal entonces

The applicable frequency for the monitor compatible with the ST-V Board is 15 kHz.

http://arcarc.xmission.com/PDF_Arcade_Manuals_and_Schematics/STV%20Sega%20Titan%20Video%20Manual.pdf

Si la información del manual es errónea, pues ya ahí no hay más que rascar. Gracias por aclararnos que el manual oficial de SEGA está mal y los juegos de ST-V funcionan a 480p 31Khz.

Deberías editar las distintas wikis sobre placas Arcade, ya que tienes información que no existe en internet, en todas especifican que sólo funciona a 15Khz, y como nos has contado, es un error que se debería aclarar.

PD: Ya que veo que tienes acceso a información muy interesante ¿Que juegos de ST-V funcionan a 480p 31Khz? Me interesaría poder echarles un ojo y hacer un listado para documentarlo apropiadamente Gracias por aportar info de primera mano

¿Hay algún juego que en ST-V funcionase a 31Khz 480p y en Saturn tuvieran que re-hacer los sprites para adaptarlos a 15Khz 240p? Sería super interesante comparar las versiones arcade con las domésticas si funcionaban a resoluciones distintas.

Y tratándose de prácticamente el mismo hardware, me pregunto si sería posible algún tipo de conversión de estos juegos 480p 1:1 a Sega Saturn, si una lo movía, la otra también tendría que poder ¿no?

@Señor Ventura Gracias por citarme. Pero intentare hace mi aporte técnico al hilo.

Disclamer: Soy experto principalmente en SS. Pero conozco muy bien la PS1. La N64 menos pero bastante. Dejar claro que la N64 es una maquina muy potente, la que más de la generación. Pero con puntos flacos como cualquier sistema: El rendimiento de la CPU y GPU junto al bus de memoria y la memoria unificada RDRAM generan los problemas. Uno de los problemas era que al usar Z-buffer junto a la corrección de perspectiva le penaliza muchisimo. Aunque se puede desactivar por microcodigos. WDC es uno de ellos, desactiva el Z-buffer y hace el orden de los polígonos como la PS1 y la SS. El otro problema que originaban era en las texturas y su resolución. Por ultiml eato she traducia en los polígonos posibles en pantalla a tasas de frames altas y estables. Todo lo que pasara de 32x32 y 100.000 triángulos en pantalla hacia que todo se fuera abajo. Por eso los juegos con estas texturas y con menos polígonos en juegos equivalentes a PS1. Por esto en PS1 y algo más en SS es más fácil tener texturas a más resolución y menos penalty. Con un polycount similar.

1º Mario 64:
¿Es posible?
Por supuesto, tanto en SS como en PS1.

¿Igual?
Imposible.

¿Con mucha diferencia?
Sin filtrado bilineal, Z-buffer y sin corrección de perspectiva. En este ultimo caso, mucho menos en SS que en PS1. El resto de efectos son posibles en SS y PS1 de forma alternativa pero muy similar como los efectos como: materiales de chromo o reflexión, o de niebla. Con transparencias a menos resolución en el caso de SS usando el truco de Burning Rangers. Posiblemente mejores fondos por el VDP2. Posiblemente mejores texturas con mejor resolución.

¿Cuanto costaría?
En PS1 sera bastante mas directo. De hecho hay un miembro de la comunidad homebrew de ps1 convirtiendo el Zelda de la n64 y se ve muy muy bien. En SS seria mas complejo: Retrabajo de gráficos principalmente para que se vean correctamente en forma de quads y un motor 3D bien optimizado. Pero XL2 hablo del tema una vez en la comunidad y el mismo probo el nivel de castillo en su motor en versiones tempranas y conseguía moverlo sin problemas.

¿Por que se puede hacer?
Primero hablemos de polígonos: Aquí hay que distinguir tres cosas:
1) Los polígonos que se ven en pantalla o dibujados.
2) Los polígonos que se calculan totales = dibujados y no-dibujados.
3) Los polígonos totales en un segundo o dibujados o totales.
Una escena de Mario 64 tiene aproximadamente 3000 triángulos por frame dibujados. 4000 triángulos totales calculados por el sistema. Con Z-buffer junto a la corrección de perspectiva. Que son entre 60.000 y 90.000 triángulos por segundo. Si va el juego en ese momento a 20 o 30 fps.
Los juegos de SS equivalentes(Gouraud, iluminacion, niebla...) están entre: 180.000 y 120.000 triángulos por segundo a 30fps. En el caso de la PS1 prácticamente igual. Lo cual nos da margen para moverlo en ambas maquinas.

2ª Sega Rally
Los poligonos en SS son quads que son dos triangulos asi que "Realmente no son 1800 polígonos solo". Dando cifras equivalentes a las que habláis de WDC serian: 60.000 triángulos por segundo dibujados y 80.000 triangulos por segundo totales calculados. Y ahora si 1800 triángulos en un frame dibujados. EDITO: Más los equivalentes en los fondos o elementos hechos por el vdp2 serían 512 quads. Lo cual incrementaría las cifras a 2800 triángulos en un frame dibujados.
WDC es un juego soberbio. Uno de los últimos del sistema. Realmente no me parece justo compararlos. Pero al cesar lo que es del cesar. Es superior.
Otra cosa ya son los gustos. Personalmente Sega Rally como juego y estéticamente me gusta más.

3º Entrelazado y progresivo.
Estos sistemas los tenia difícil para hacer progresivo a 480 de vertical. Lo normal era hace entrelazado para cualquier cosa que pasara de los 256 verticales, incluso para la PS2. El tema esta en la VRAM total disponible.
SS tenia truco. Su modo 480p es a 30hz. Es decir a la mitad del estándar. Necesita TV especiales o monitores. Ademas que limitaba muchisimo el uso de los VDP, para poder usarlo.

CorvusD escribió:3º Entrelazado y progresivo.
Estos sistemas los tenia difícil para hacer progresivo a 480 de vertical. Lo normal era hace entrelazado para cualquier cosa que pasara de los 256 verticales, incluso para la PS2. El tema esta en la VRAM total disponible.
SS tenia truco. Su modo 480p es a 30hz. Es decir a la mitad del estándar. Necesita TV especiales o monitores. Ademas que limitaba muchisimo el uso de los VDP, para poder usarlo.

Veo que conoces el tema. ¿Que aplicaciones tuvo este extraño modo “480p”?

El usuario @chinitosoccer afirma que los siguientes juegos de ST-V funcionaban a 31khz 480p:

chinitosoccer escribió:Ha y juegos de la placa Sega Titan ST-V, que es una Sega Saturn sin lector de CD-ROM, que sacan video a 480p 31khz, Baku Baku Animal, Critter Crusher, Columns 97, luego alguien dijo que la Saturn puede hacer lo mismo, alguien lo dijo en el foro de Sega-16, por lo que no estoy seguro, no tengo como corroborarlo;

editado: Decathlete y Winter Heat tambien es posible ponerlos a 480p, probado en un monitor arcade Sanwa PFX, el cual soporta señales de 15, 24 y 31khz, se escucha el relay cambiar de resolucion al encender el monitor y el OSD del supergun claramente muestra "640x480 31|khz".

¿Era la Saturn capaz de lo mismo?

@LINKr2 Realmente en SS lo único que se que existe es este juego homebrew https://m.youtube.com/watch?v=cY1G24Qsac4

En juegos stv ni idea. Si se que hay muchos en hires entrelazado.

La SS es capaz y la STV igual. Quizás la STV lo tenga mas fácil al tener las VRAM. En la SS se puede pero con bastantes limitaciones en el vdp2.

LINKr2 escribió:
El usuario @chinitosoccer afirma que los siguientes juegos de ST-V funcionaban a 31khz 480p:

chinitosoccer escribió:Ha y juegos de la placa Sega Titan ST-V, que es una Sega Saturn sin lector de CD-ROM, que sacan video a 480p 31khz, Baku Baku Animal, Critter Crusher, Columns 97, luego alguien dijo que la Saturn puede hacer lo mismo, alguien lo dijo en el foro de Sega-16, por lo que no estoy seguro, no tengo como corroborarlo;

editado: Decathlete y Winter Heat tambien es posible ponerlos a 480p, probado en un monitor arcade Sanwa PFX, el cual soporta señales de 15, 24 y 31khz, se escucha el relay cambiar de resolucion al encender el monitor y el OSD del supergun claramente muestra "640x480 31|khz".

Como le comente a radorn esos juegos pude comprobar que no funcionan a 31khz tampoco en STV , ya que el Extron RGB que utilizo en mi supergun muestra "15khz" en el display, pero luego por algun motivo que desconozco y que supongo sera relacionado a la resolución y sincronia de la placa STV, que en el OSD del monitor Sanwa muestra una resolucion que no es a la que realmente corren estos juegos, y pone "31 khz",

Como dije anteriormente, el unico titulo que si corre a 31khz es el tragamonedas del Photoshoot que lleva una STV dentro, pero de nuevo, no es un videojuego "al uso" sino que se trata de un software de captura de fotos a las que permitia escribir mensajes y pintarrajear chorradas encima.

@EMaDeLoC Ya claro, si el sprite no está perfectamente alineado con la pantalla, se desaprovechan ciclos con sobreescrituras y tal, pero eso pasaría en todas las resoluciones igual ¿no?
O sea, mi razonamiento es que, con la explicación que diste de cómo se dibujan las texturas/sprites en Saturn, sin tener en cuenta otros posibles factores, daría a entender que la resolución de pantalla no afecta al rendimiento de dibujado porque al final, ese rendimiento parece estar atado al tamaño de la textura en si, no al tamaño que tenga en pantalla.
Parecería que una textura de 64x64 tardaría lo mismo en dibujarse en una pantalla de 320x240 que en una de 640x480, porque al final lo que cuenta es el tamaño de la textura, que tiene que ser dibujada pixel a pixel, al contrario que en otros sistemas donde lo que mas importa es el tamaño de la "parcela" de la pantalla que se ha de dibujar.
Insisto, estoy dejando de lado otros posibles factores, que, en general, desconozco.
Que el proceso es poco eficiente lo entiendo, pero, tomando en cuenta solo este aspecto del proceso, parecería que al "pintasprites" del daría un poco igual el tamaño de la pantalla.

Si hay una relación 1:1 perfecta entre pixels de textura y de pantalla, el rendimiento sería óptimo, sin desperdicarse ningún ciclo en sobreescrituras o en pixels que no se van a ver. Eso está claro.
Si hay deformaciones, acaba habiendo sobreescrituras y parte del esfuerzo de dibujado no se ve reflejado en un resultado visual, y lo consideramos desperdicio.
Queda por saber, si la textura está estirada por encima de su tamaño original, si también se incurre en mas ciclos para pintar un pixel de textura en mas de un pixel de pantalla ("pixelacos"), o ahí ya hay "ahorro"

Digo yo que si tomamos de ejemplo una misma escena, habría la mitad de sobreescrituras si se renderiza a 480p que 240p, sin embargo, en ambos casos el pita-sprites igualmente tendría que haber recorrido esa textura pixel a pixel de la misma manera en ambos casos, que es uno de los cuellos de botella de Saturn.

No se. Tu conoces mejor los costes de estos procesos que yo. Dime que te parece.

@radorn A ver, pasé por encima de esa parte y no quedó clara.
La forma más óptima de dibujar un sprite es no aplicarle ninguna transformación, incluyendo escalas, así aprovechas mejor los ciclos de dibujado y de paso aplicas todos los efectos sin problemas (Gouraud, transparencias...).
Tanto el VDP1 como el VDP2 parecen ir sobrados de ancho de banda de memoria para manejar resoluciones altas.
Lo que pasé por encima es que al haber más resolución es necesario dibujar más sprites o más grandes en la pantalla para poder llenarla. Un sprite de 64x64 se verá bien a 320x240, pero a 640x480 se verá a la mitad de tamaño. Es decir, para que un personaje nos ocupe el mismo espacio en el mismo CRT a 320x240 que a 640x480, tendremos que doblar su tamaño de sprite.
¿Es mejor doblar la resolución del sprite que aplicarle un factor 2x de escala? Ahí tengo mis dudas, pero entiendo que el motor del VDP1 esta más vinculado al píxel del sprite que al de la pantalla, es decir, lee un pixel del sprite y lo pinta en el framebuffer. Así que en escala 2x lee un pixel del sprite y rellena 2 del framebuffer (deberian ser 4 por doblar la resolución, pero hablamos de resolución entrelazada y cada framebuffer tiene la mitad de líneas, siendo estas de campos distintos, así que a una zona de 2x2 píxeles solo se le dibuja una línea cada vez. Dejo aparte el 480p por ser un experimento). Aparentemente la perdida de rendimiento del VDP1 aplicando escalas es muy pequeña y como en cierta manera "sobra" dibujado, parece ser una buena opción.
A todo esto, las rotaciones tampoco parecen ser un problema si el VDP1 trabaja los sprites de esta manera, así que podemos aprovechar ambos tipos de transformaciones para dar vistosidad al juego.
Hay que tener en cuenta que seguimos limitados a 512KB de memoria de texturas (sprites) y no podemos meter todos los sprites que nos dé la gana. Según mis cuentas solo caben 128 sprites de 64x64 a 8bits de color (admite también sprites a 16bits, pero en alta resolución la Saturn solo va a 8bits, supongo que por limitación de espacio de los framebuffers), así que habría que hacer algunos trucos para, por ejemplo, dar variedad a un nivel de Shoot 'em up.

radorn escribió:Digo yo que si tomamos de ejemplo una misma escena, habría la mitad de sobreescrituras si se renderiza a 480p que 240p, sin embargo, en ambos casos el pita-sprites igualmente tendría que haber recorrido esa textura pixel a pixel de la misma manera en ambos casos, que es uno de los cuellos de botella de Saturn.

Supongo que lo que querias decir es al reves: la mitad de sobreescrituras a 240p que a 480p.
En esta web de especificaciones de Saturn indican que al menos tenemos 9Mtexels/s para pintar sprites en pantalla (no especifica con o sin transformaciones). A 640x480p nos dan 30fps justos, pintando sprites en toda la pantalla, algo que por supuesto no ocurre nunca. Siendo el fillrate mínimo y en una resolución experimental, no tengo problemas a decir que a 640x480i se debería llegar a 60fps sin problemas.
Creo que el cuello de botella lo encontramos realmente cuando la Saturn trata de pintar un escenario 3D, no solo por los desperdicios de ciclos de pintado en los sprites deformados, también porque las CPU van excesivamente cortas para unos cálculos tan complejos. Recordemos que la PS1 lleva un coprocesador ad-hoc para transformaciones tridimensionales. De todas formas tiene aún cierto margen si se trata de modelos 3D que no son excesivamente complejos.

Aquí un ejemplo de lo que digo del modelo 3D, y de paso un uso excelente del VDP2:


Conclusión: la Saturn es una bestia parda en 2D.

chinitosoccer escribió:Como le comente a radorn esos juegos pude comprobar que no funcionan a 31khz tampoco en STV , ya que el Extron RGB que utilizo en mi supergun muestra "15khz" en el display, pero luego por algun motivo que desconozco y que supongo sera relacionado a la resolución y sincronia de la placa STV, que en el OSD del monitor Sanwa muestra una resolucion que no es a la que realmente corren estos juegos, y pone "31 khz",

Como dije anteriormente, el unico titulo que si corre a 31khz es el tragamonedas del Photoshoot que lleva una STV dentro, pero de nuevo, no es un videojuego "al uso" sino que se trata de un software de captura de fotos a las que permitia escribir mensajes y pintarrajear chorradas encima.

¿Soy al único al que esta conversación le está pareciendo surrealista? Me estás mareando cosa mala amigo

Vale, entonces la gente no está tan equivocada cuando en todo Internet y en el Manual de servicio de SEGA, se dice que ST-V es una placa que funciona a 15Khz.

Ahora según tú, hemos pasado a que hay sólo un único “juego” de ST-V que va 31Khz, nos podrías decir cual es de esta lista:



Gracias

LINKr2 escribió:

chinitosoccer escribió:Como le comente a radorn esos juegos pude comprobar que no funcionan a 31khz tampoco en STV , ya que el Extron RGB que utilizo en mi supergun muestra "15khz" en el display, pero luego por algun motivo que desconozco y que supongo sera relacionado a la resolución y sincronia de la placa STV, que en el OSD del monitor Sanwa muestra una resolucion que no es a la que realmente corren estos juegos, y pone "31 khz",

Como dije anteriormente, el unico titulo que si corre a 31khz es el tragamonedas del Photoshoot que lleva una STV dentro, pero de nuevo, no es un videojuego "al uso" sino que se trata de un software de captura de fotos a las que permitia escribir mensajes y pintarrajear chorradas encima.

¿Soy al único al que esta conversación le está pareciendo surrealista? Me estás mareando cosa mala amigo

Vale, entonces la gente no está tan equivocada cuando en todo Internet y en el Manual de servicio de SEGA, se dice que ST-V es una placa que funciona a 15Khz.

Ahora según tú, hemos pasado a que hay sólo un único “juego” de ST-V que va 31Khz, nos podrías decir cual es de esta lista:



Gracias

Por lo que se dice en el hilo, supongo que será el Print Club 2 (los llamados purikura, que fueron una revolución en la época).



En uno de los Yakuza se pueden probar

@LINKr2 Sinceramente no me parece surrealista. Me da la impresión que se esta confundiendo los distintos refrescos que ocurren en pantalla, mas en la era de los CRT. Yo mismo he pasado por esta confusion durante mi investigacion de la SS.
Hay hasta tres tipos de refrescos que ocurren "a la vez" y no. Pasan en milisegundos y otros en 1 sg.
1) Refresco vertical
2) Refresco horizontal
https://en.wikipedia.org/wiki/Multisync_monitor
PAL, NTSC, CGA: ~15.7 kHz horizontal scan, 50 or 60 Hz vertical scan
EGA: 15.7 kHz or 21.8 kHz horizontal scan, 60 Hz vertical scan
VGA: 31.5 kHz horizontal scan, 60 or 70 Hz vertical scan
Segun tengo entendido en SS el modo soportado es el de 31.5 Khz:
https://i.imgur.com/TRt8Ko8.png
Pero puede que soporte 15.7 Khz que es para monitores mas antiguos y arcades o jammas más antiguas.

3) Vblank y Hblank
https://en.wikipedia.org/wiki/Raster_scan#/media/File:Raster-scan.svg

Bueno aclarado esto. Es posible usar el modo 480p en SS o STV. Si pero de forma muy limitada. Es posible que para necesidades sencillas como esa recreativa o el juego homebrew, usarlo. Pero poco más.
Sobre utilizarlo en juegos Hi-res y que pasen a este modo. No lo se realmente. Quizas en las STV con mas VRAM sea posible. Y juegos como Decathlete y Winter Heat que estaban mega optimizados para la el hi-res y la STV puedan lograrlo.

@radorn @EMaDeLoC Sobre como renderiza o dibuja el VDP1. Realmente no soy un mega experto a estos niveles. Pero cualquier algoritmo o pipeline de pintado, desde los inicios a hasta ahora. Por supuesto para la SS. La resolución y colores son el mayor penalizador. Para saber que pixel dibujar antes tienen que leerlo y después saber que hacer con el. Si este no cambia, sera más rápido. Si cambia, no es lo mismo hacelo mas pequeño que mas grande. Y aunque parezca contradictorio, hacer mas pequeña una textura, reducirla, penaliza mas que aumentarla. En el caso estándar de dibujado se pinta o llena a linea a linea horizontal. En el caso de SS y 3DO se pinta linea a linea del sprite. Ocasionando en el caso de SS el repintado de pixeles en quads muy deformados o llevados al extremo triangulares. SS tenia la ventaja de tener memorias mas rápidas. Pero a la postre usar texturas penaliza siempre.
Tema colores. La SS y la PS1 soportan color de pixel de 4BPP por CLUTS. SS 8bits nativos mínimo. Es decir que se pueden almacenar mas texturas/patrones/sprites en la VRAM.

EDIT 2: @EMaDeLoC

EMaDeLoC escribió: ...Creo que el cuello de botella lo encontramos realmente cuando la Saturn trata de pintar un escenario 3D, no solo por los desperdicios de ciclos de pintado en los sprites deformados, también porque las CPU van excesivamente cortas para unos cálculos tan complejos. Recordemos que la PS1 lleva un coprocesador ad-hoc para transformaciones tridimensionales. De todas formas tiene aún cierto margen si se trata de modelos 3D que no son excesivamente complejos.
....
Conclusión: la Saturn es una bestia parda en 2D.

Lo siento lo acabo de leer. No podía dejar de añadir. La Saturn es una bestia parda 2D. Pero también una bestia 3D. Un SH2 tiene una capacidad de proceso superior al MIPS de la PS1, dos imaginad. Ademas esta el SCU-DSP un procesador de apoyo. El problema era usarlos para hacer 3D. El GTE de PS1 esta hecho para el 3D. Los procesadores de SS son multi-proposito. Capaces de todo: Incluso de descomprimir MPEG o IDC como el MDEC de la PS1.. Y para 3D más que poderosos y validos.
Aquí tenéis un ejemplo de XL2.

Un juego FPS homebrew con: Iluminación dinámica a color con Gouruad, texturas 64x64 a 4BPP CLUT de 16bit de color, transparencias de VDP1 y de VDP2, modo 4 jugadores!! pone cerca de 2000 quads o 4000 triángulos en pantalla con todo estos efectos. Si la SS no es capaz de hacer 3D en condiciones Ya os digo que la PS1 con este juego las pasaría putas. Y por supuesto que también lo moveria. Quizás no se vería igual de bien que en SS. Por la deformación de perspectiva. Y los efectos de planos infinitos para el cielo y el fondo que usa XL2.

CorvusD escribió:EDIT 2: @EMaDeLoC

EMaDeLoC escribió: ...Creo que el cuello de botella lo encontramos realmente cuando la Saturn trata de pintar un escenario 3D, no solo por los desperdicios de ciclos de pintado en los sprites deformados, también porque las CPU van excesivamente cortas para unos cálculos tan complejos. Recordemos que la PS1 lleva un coprocesador ad-hoc para transformaciones tridimensionales. De todas formas tiene aún cierto margen si se trata de modelos 3D que no son excesivamente complejos.
....
Conclusión: la Saturn es una bestia parda en 2D.

Lo siento lo acabo de leer. No podía dejar de añadir. La Saturn es una bestia parda 2D. Pero también una bestia 3D. Un SH2 tiene una capacidad de proceso superior al MIPS de la PS1, dos imaginad. Ademas esta el SCU-DSP un procesador de apoyo. El problema era usarlos para hacer 3D. El GTE de PS1 esta hecho para el 3D. Los procesadores de SS son multi-proposito. Capaces de todo: Incluso de descomprimir MPEG o IDC como el MDEC de la PS1.. Y para 3D más que poderosos y validos.

No, un SH2 no es superior al R3000A de PS1. En cuanto a que dos en conjunto superen, comparten el mismo bus, así que ambos deben alternarse en el uso del bus, lo cual supone un cuello de botella importante, a menos que se programe con precisión ambos procesadores para alternarse en el acceso a la RAM o al SCU. Aún así, usando los dos a la vez con el kit de desarrollo normal su rendimiento es mejor en conjunto que uno solo.
El DSP era un infierno para programar con él y sacarle provecho. Se tenía que programar en ensamblador, lo cual no es tan grave porque con los SH también se hacía. El problema es que con el DSP se llegaba a tener que programar 6 instrucciones por línea, una puñetera locura. Rieté de programar los dos SH en tandem... https://www.youtube.com/watch?v=n8plen8cLro
Aunque la Saturn tiene procesadores multipropósito, están dedicados a tareas concretas. El SH1 sirve para descomprimir vídeo, pero no se puede aprovechar para otra cosa como 3D. Lo mismo se puede decir del 68EC000. Por cierto, para descompresión MPEG hacía falta una tarjeta aparte.

CorvusD escribió:Aquí tenéis un ejemplo de XL2.

Un juego FPS homebrew con: Iluminación dinámica a color con Gouruad, texturas 64x64 a 4BPP CLUT de 16bit de color, transparencias de VDP1 y de VDP2, modo 4 jugadores!! pone cerca de 2000 quads o 4000 triángulos en pantalla con todo estos efectos. Si la SS no es capaz de hacer 3D en condiciones Ya os digo que la PS1 con este juego las pasaría putas. Y por supuesto que también lo moveria. Quizás no se vería igual de bien que en SS. Por la deformación de perspectiva. Y los efectos de planos infinitos para el cielo y el fondo que usa XL2.

Saturn no maneja triángulos, solo quads.
En cuanto a la demo, es impresionante, pero lleva como 3 años en desarrollo, bastante más tiempo del que tuvieron programadores de la consola por entonces. Que lo hace un tío solo y tiene su mérito, pero que "fácil" no ha sido llegar hasta ahí. Esta basado en el motor BSP, el mismo que el Quake, obviamente modificado y pulido algo más, pero el de Quake ya daba buenos resultados: https://www.youtube.com/watch?v=RI0Q0VWOp3E
Las transparencias del agua la verdad que es algo impresionante. Si no he entendido mal, usa un bitmap en el plano de fondo NGB0 y el VDP2 (que es quien puede hacer esta clase de transparencias) lo ajusta a la posición y tamaño del estanque. Eso lo limita a un estanque por sala, o a dos si usa también el NGB1 pero ese lo usa para una capa de nubes en el cielo.
Muy interesante. Parece estar aplicando todos los trucos conocidos de la consola, me gustaría ver más y ver donde llega a ser capaz.
Por cierto, dice el desarrollador que el VDP1 no le da problemas de rendimiento, se los da los SH que ya están al tope. Que es justo lo que comenté.

@EMaDeLoC Siento tener que puntualizar algunas cosas:
1. El MIPS de la ps1 da 30MIPS. Tarda 37 ciclos para dividir y no tiene MAC(suma + resta).
2. El SH2 da 37MIPS. Tarda 32 ciclos en dividir y tiene MAC que hace en dos ciclos.
3. El SCU-DSP hace 1,5 MAC en un ciclo. Con 88MIPS posibles. Es complicado pero no posible. El mismo John Burton destaca su gran potencial. XL2 también ha empezado a usarlo.
4. El SH1 no se usa para mpeg o descompresión. Actualmente solo para ayudar en la lectura y buffer del cd en el bloque de sonido. Es una bestia de 20MIPS.
5. XL2 lleva 3 años programando. En general. Aprendió con la saturn. Programa en C, aunque ha implementado algo en ensamblador pero quiere meter aun más. Esto quiere decir que aun tiene margen de optimización.
6. Su motor es totalmente suyo. Se basa ahora en PVS+portales. Aunque estubo tambien en BSP. Ha implementado un montón de cosas increíbles. Como subdivisión dinámica. Iluminación dinámica a color en todas las entidades. Tiene su propio convertidor de mapas y entidades y animación.
7. El MDEC de ps1 tiene una potencia estimada de 88MIPS. La combinación de procesadores de SS supera esto. De hecho hay vídeos basados en el códec de mpeg, IDC, en el sistema. Sin tarjeta.
8. Cuando hablo de triángulos hablo de la equivalencia.
9. Otro mito. El procesamiento es en paralelo totalmente posible. Así lo usa XL2. Cada sh2 tiene su cache y DMA internos para compartir registros. Incluso con el scu-dsp.
10. Las transparencias se basan en el truco de Burnig Rangers. En mi últimas entras lo explico mas en detalle. Resumidamente lo dibuja el vdp1 se transfiere al vdp2 y este hace la transparencia.

Espero haber arrojado algo claridad al respecto. Gracias por los aportes.

¿Por qué la industria ha seguido apostando por triangulos cuando los quads son ante la lógica un ahorro de recursos?.

4 coordenadas vs 6 coordenadas.

Al final lo que cuenta son los resultados, ahi esta el primer tomb raider de ejemplo, a 30 frames rocosos en PSX y la Saturn con la lengua fuera para moverlo a 15-20 frames.

Señor Ventura escribió:¿Por qué la industria ha seguido apostando por triangulos cuando los quads son ante la lógica un ahorro de recursos?.

4 coordenadas vs 6 coordenadas.

Bueno al final son 4 coordenadas para hacer un quad con dos triángulos o un quad. A nivel matemático se simplifica. El triangulo es mas eficiente ante toda lógica. Lo del quad fue al inicio de las 3D.

SPA escribió:Al final lo que cuenta son los resultados, ahi esta el primer tomb raider de ejemplo, a 30 frames rocosos en PSX y la Saturn con la lengua fuera para moverlo a 15-20 frames.

No es exacto. Tomb raider en Saturn se mueve el 80% del tiempo entre 25 y 30 fps. Baja a 20 a 15 fps en los lugares mas abiertos y con enemigos. Corte design no lo pudo hacer mejor. SS necesitaba mas dedicación. Ellos mismos declararon que salio con bugs conocidos. Como el del sonido. También. Señalar que SS las texturas no se deforman como en ps1. Viéndose mejor. Sin embargo tiene un mipmapping o lod bastante feo en algunas texturas y la ps1 no. La ps1 también tiene bajadas en esas zonas mas petadas, pero rozando los 24fps.

También es cierto que Exhumed y duke nukem 3D van a 30fps donde la ps1 va bastante peor. Con niveles incluso mas detallados en SS y con mas efectos. Y sin las deformación de marras en las texturas.
Aquí es importante señalar que cuando se programa para una consola mucho la otra necesitara que se rehaga bien el código. Si no no rendirá.

@CorvusD
3 Solo llega a los 88MIPS si ejecutas las 6 instrucciones en paralelo. Y es una sobrecomplicación totalmente absurda: indicarle al procesador como tiene que mover sus registros y realizar las operaciones. Lo mismo que hacen las CPUs normales pero de forma interna y transparente al usuario. Por supuesto así se gana control y coordinandolo bien se agiliza mucho cálculo encadenando operaciones, pero es una pesadilla a nivel de programación. No lo digo a malas. Y XL2 dijo que apenas le daba mejora porque los SH2 le cundian bien en la parte de cálculo por sí solos. Lo dijo en este vídeo de hace dos meses: https://www.youtube.com/watch?v=Md8Ve7uB7A4
6 En muchos de sus vídeos dice, literalmente "BSP based engine", cuyos orígenes se remontan a la década de los 60 y juegos como Doom lo aplican. Obviamente habrá adaptado los algoritmos a la forma de trabajar de la Saturn, pero es un trabajo basado en el de otros, no es solo suyo.
7 Yo puedo tener una RTX pero si tengo de CPU un i3 me va a costar mover hasta el Tetris, pero en suma tendré FLOPS saliendome por las orejas. Sumar los MIPS de los procesadores de la Saturn es la misma táctica cutre de marketing de la Atari Jaguar y sus 64bits. Tener tantos procesadores desperdigados así no es una ventaja, es un desperdicio que al final ayuda poco en rendimiento o hace la vida difícil a los programadores. Al final lo que se obtiene es una arquitectura cara, poco eficiente y poco amigable, frente a la de PS1, más barata, mejor en eficiencia y más sencilla de programar. Y yo soy de la N64, no tiro flores a la PS1 porque sí. Es mi opinión.
9 No he dicho que no sea posible, digo que es complicado porque hay que alternar el uso del bus entre uno y otro y procurar no solaparse. En el Z-Treme se usa un SH para T&L y el otro para todo lo demás, y supongo que XL2 los habrá coordinado adecuadamente para que no se peleen por el acceso al bus.

@Señor Ventura Con triángulos puedes formar cualquier figura geométrica posible.
Los dos vértices que ahorras no te compensan los chanchullos geométricos que tienes que hacer si quieres pintar un triángulo con un quad. Y si a la hora de almacenar encadenas bien los triángulos, puedes usar el último vertice de uno como el primero de otro, por lo que en vez de 6 coordenadas se quedan en 5. Pero en la época del despegue del CD había espacio de sobra como para preocuparse por un vertice.

SPA escribió:Al final lo que cuenta son los resultados, ahi esta el primer tomb raider de ejemplo, a 30 frames rocosos en PSX y la Saturn con la lengua fuera para moverlo a 15-20 frames.

Peor framerate, peores gráficos y peor sonido. Solo hace falta ver la comparativa de DF.

Pero es lo de siempre, los programadores no saben. Pero eh, la PSX estaba aprovechada al máximo.

EMaDeLoC escribió:@CorvusD
3 Solo llega a los 88MIPS si ejecutas las 6 instrucciones en paralelo. Y es una sobrecomplicación totalmente absurda: indicarle al procesador como tiene que mover sus registros y realizar las operaciones. Lo mismo que hacen las CPUs normales pero de forma interna y transparente al usuario. Por supuesto así se gana control y coordinandolo bien se agiliza mucho cálculo encadenando operaciones, pero es una pesadilla a nivel de programación. No lo digo a malas. Y XL2 dijo que apenas le daba mejora porque los SH2 le cundian bien en la parte de cálculo por sí solos. Lo dijo en este vídeo de hace dos meses: https://www.youtube.com/watch?v=Md8Ve7uB7A4
6 En muchos de sus vídeos dice, literalmente "BSP based engine", cuyos orígenes se remontan a la década de los 60 y juegos como Doom lo aplican. Obviamente habrá adaptado los algoritmos a la forma de trabajar de la Saturn, pero es un trabajo basado en el de otros, no es solo suyo.
7 Yo puedo tener una RTX pero si tengo de CPU un i3 me va a costar mover hasta el Tetris, pero en suma tendré FLOPS saliendome por las orejas. Sumar los MIPS de los procesadores de la Saturn es la misma táctica cutre de marketing de la Atari Jaguar y sus 64bits. Tener tantos procesadores desperdigados así no es una ventaja, es un desperdicio que al final ayuda poco en rendimiento o hace la vida difícil a los programadores. Al final lo que se obtiene es una arquitectura cara, poco eficiente y poco amigable, frente a la de PS1, más barata, mejor en eficiencia y más sencilla de programar. Y yo soy de la N64, no tiro flores a la PS1 porque sí. Es mi opinión.
9 No he dicho que no sea posible, digo que es complicado porque hay que alternar el uso del bus entre uno y otro y procurar no solaparse. En el Z-Treme se usa un SH para T&L y el otro para todo lo demás, y supongo que XL2 los habrá coordinado adecuadamente para que no se peleen por el acceso al bus.

Tranquilo, no me lo tomo a malas. Solo es por aportar.
XL2 hace ya meses que paso a otro modo. BSP era demasiado pesado. Hablamos con el casi cada día en discord. La T&L la hace en el esclavo. Y ahora con el SCU-DSP hace parte de las transformaciones de las entidades.
La SS es como es. Tanto en su complejidad o diseño. Pero a la vez tiene sus fortalezas. John burton usa el SCU-DSP de forma muy eficiente junto a los sh2 mira su vídeo donde lo explica. Y es uno de los juegos que mas geometría procesa junto a iluminación y niebla en el sistema. Además de hacer otras virgerias en sonic R. El si no llega a los 88MIPS del scu-dsp se queda cerca y además suma a los dos SH2 con sus MIPS. Y lo programo en menos de un año. Ha 30fps como una roca. El mismo John me confirmo la potencia del mismo scu-dsp por twitter. Un buen programador usa lo que tiene. Mas cuando se puede dedicar a un sistema.

Commodore escribió:

SPA escribió:Al final lo que cuenta son los resultados, ahi esta el primer tomb raider de ejemplo, a 30 frames rocosos en PSX y la Saturn con la lengua fuera para moverlo a 15-20 frames.

Peor framerate, peores gráficos y peor sonido. Solo hace falta ver la comparativa de DF.

Pero es lo de siempre, los programadores no saben. Pero eh, la PSX estaba aprovechada al máximo.

Mira la comparativa de exhumed y duke nukem 3D también de DF.
Y es como dices la ps1 se aprovechaba bien. Era mas sencillo. Es así. Un gran maquina. Como la SS y la N64.

Commodore escribió:

SPA escribió:Al final lo que cuenta son los resultados, ahi esta el primer tomb raider de ejemplo, a 30 frames rocosos en PSX y la Saturn con la lengua fuera para moverlo a 15-20 frames.

Peor framerate, peores gráficos y peor sonido. Solo hace falta ver la comparativa de DF.

Pero es lo de siempre, los programadores no saben. Pero eh, la PSX estaba aprovechada al máximo.

Estos temas siempre acaban igual, lo unico cierto es que en su dia la inmensa mayoria de multis que ambas compartian iban y se veian mejor en PSX que en Saturn.

@panzeroust según este archivo, todas las versiones de Print Club 2 (entre 1997 y 1999), funcionan a:

Type raster, resolution 352×224@59,764802 Hz, CRT 15kHz, gameplay box (0,0)÷(352,224), display box 427×263, pixel clock @ 6.711647 MHz

http://adb.arcadeitalia.net/dettaglio_mame.php?game_name=pclub2&search_id=1

Y por las capturas, parece que efectivamente funcionan a esa resolución.

Así que seguimos sin saber cual es ese único juego a 480p 31Khz que señala @chinitosoccer de ST-V.

Con todo el respeto del mundo, empiezo a pensar que la información que hay en internet es correcta, y ST-V funciona solamente a 15Khz.

A ver si @chinitosoccer nos lo puede aclarar, pero parece que Print Club 2 y sus variantes (hello kitty, pokémon, etc) son el juego de fotos de ST-V.

@LINKr2

Corvus ya te respondió, y por la respuesta creo que te puedes hacer una idea sobre lo que te inquieta:

CorvusD escribió:@LINKr2 Sinceramente no me parece surrealista. Me da la impresión que se esta confundiendo los distintos refrescos que ocurren en pantalla, mas en la era de los CRT. Yo mismo he pasado por esta confusion durante mi investigacion de la SS.
Hay hasta tres tipos de refrescos que ocurren "a la vez" y no. Pasan en milisegundos y otros en 1 sg.
1) Refresco vertical
2) Refresco horizontal
https://en.wikipedia.org/wiki/Multisync_monitor
PAL, NTSC, CGA: ~15.7 kHz horizontal scan, 50 or 60 Hz vertical scan
EGA: 15.7 kHz or 21.8 kHz horizontal scan, 60 Hz vertical scan
VGA: 31.5 kHz horizontal scan, 60 or 70 Hz vertical scan
Segun tengo entendido en SS el modo soportado es el de 31.5 Khz:
https://i.imgur.com/TRt8Ko8.png
Pero puede que soporte 15.7 Khz que es para monitores mas antiguos y arcades o jammas más antiguas.

3) Vblank y Hblank
https://en.wikipedia.org/wiki/Raster_scan#/media/File:Raster-scan.svg

@chinitosoccer se puede haber confundido, y ya. Tampoco pasa nada.

EMaDeLoC escribió:
Conclusión: la Saturn es una bestia parda en 2D.

Sin embargo en juegos con falso 3D, como lo son Doom y Hexen Saturn rinde como el culo, le cuesta un huevo mover ese motor 2D que simula 3D, tan bestia parda se ve que no es.

chinitosoccer escribió:

EMaDeLoC escribió:
Conclusión: la Saturn es una bestia parda en 2D.

Sin embargo en juegos con falso 3D, como lo son Doom y Hexen Saturn rinde como el culo, le cuesta un huevo mover ese motor 2D que simula 3D, tan bestia parda se ve que no es.

No es 2D. Como dices es pseudo 3D.

Doom es un port infame. Port de un port de otro port...

Hexen en SS es una buena versión. De hecho va mas suave en SS. Y a nivel de contenido considerada también muy buena. Si es cierto que las texturas tienen menos resolución. Por lo demás no es mal port.

chinitosoccer escribió:

EMaDeLoC escribió:
Conclusión: la Saturn es una bestia parda en 2D.

Sin embargo en juegos con falso 3D, como lo son Doom y Hexen Saturn rinde como el culo, le cuesta un huevo mover ese motor 2D que simula 3D, tan bestia parda se ve que no es.

Doom es puro software y no aprovecha el VDP1 para el dibujado. Al parecer a John Carmack le mostraron una prueba usando sprites para las paredes y no le convenció la distorsión por falta de corrección de perspectiva y dijo que se hiciera a golpe de CPU. Luego se arrepintió de esa decisión.
Vistos los ports en otras consolas inferiores, además no se hizo un buen trabajo aprovechando las CPUs.
No sé si en Hexen ocurrió lo mismo.