¿Podría una SNES o MD con lo mejor de la AES?

jordigahan escribió:por cierto ralph, yo tengo ese juego, que tiene de especial?

Que no lo conocía, y está curradete


...ahora mismo estoy un poco ocupado con algo que me está llevando todo el tiempo, pero en cuento termine, y me apañe un poco con mis historias, sacaré tiempo para investigar unas cosillas... entre otras, fabricarme una caja y el manual del demo's crest, que está imposible de conseguir completo (ni creo que compense).

...no se me olvida lo del audio del AOF2, que no se como va la historia, y me da que va a ser complicado de narices.

DevilKenMasters escribió:

chinitosoccer escribió:

DevilKenMasters escribió:

Esto mismo fue lo que hicieron Eurocom/Gametek con el Super Street Fighter 2 Turbo de PC DOS y quedo bastante bien.

Que no, leñe, que lo que hicieron Eurocom/Gametek fue usar sprites cuya resolución original era 384x224 en la de PC a 320x200. NO 320x240 ni mucho menos 320x224. 200

Y esos 40 píxeles de diferencia son bastante notables para que el ratio de los personajes sea correcto.

El que va a 320x240 es el SSF2 sin Turbo, cuyos sprites son los de SNES y por ello el ratio también es correcto. Infórmate si no te lo crees.

+1, por eso los personajes se veian descomunales, curiosamente esta practica se usa mucho en los Mugen, donde directamente cogen los chars sin pensar que estan ideados en su resolucion nativa para estirarse a 4:3 (la resolucion de una placa de cps2 tira mas a lo panoramico que a lo 4:3) y por eso siempre se acaban viendo los personajes achatados.

De cachondeo tiraba en el 486 Sx de mi primo ^^ xD! y que cdda, dios xD!

Vaya.. se acabó lo bueno.. hace tiempo que ya nadie comenta en este hilo...

La cuestión es que hace cinco minutos me vino a la cabeza lo de la resolución de la snes y... he caído en una cosa...

Antiguamente no nos importaban (tanto) las resoluciones.. prácticamente todos usábamos cables de baja calidad (cable de antena) para conectar nuestras consolas por lo que los "defectos" los encontramos ahora que las conectamos por RGB o por VGA...

De acuerdo, la Snes tendría que usar la resolución baja.. vale... pero es que sería AHORA cuando nos daríamos cuenta de los pixels.

Supongo que si hubieran hecho un juego con muuuchos megas y que fuera prácticamente como el de AES, sería ahora cuando lo jugásemos a través de un emulador (por ejemplo) cuando tendríamos la sensación de que el juego ha envejecido mal.. vamos.. que no lo veo tampoco tan mal.

PD: Incluso a día de hoy, al jugarlo en la TFT por cable de antena no la veríamos tan mal (como se comentó en otros post más abajo).

Y pa reflotar un poco el hilo... quería haceros alguna pregunta. De acuerdo, snes no podría tener una versión 1:1 del juego AES. Eso está claro. Pero también está claro que se lo podrían haber currado un poco más y "modificar" algunas fases con lo mejor de la supernes.. quiero decir añadirle transparencias, modo7 en alguna fase, etc.. y mi pregunta es si megadrive podría haber hecho algo propio.. vamos.. alguna característica que no pueda hacer la AES.

LA verdad es que yo he seguido investigando este tema en el foro de NesDev, para comentar con gente que domina mucho de la SNES sobre los límites a los que se puede llevar ésta...
Sí que está clara la conclusión de que un port 1:1 no es posible, pero sí conseguir algo que visualmente sea igual (vamos, que si no eres mujer creo que no distinguirás el color de un pixel del fondo azul de uno "azul petróleo"... ) y con la misma fluidez... Eso el algo que ahora mismo centra mi atención, puesto que en resolución y colores ya sabemos que estamos limitados... quizá con una ROM muy grande se pueden meter los personajes de AoF con más frames de animación o con más tamaño para el zoom... o bien hacer que los personajes sean un BG cuando están alejados y cargar los sprites cuando están cerca y cosas así (se necesitarían quizá menos frames de animación cuando están lejos porque no pueden recibir físicamente ciertos golpes)...

Pero una limitación enorme que me he encontrado es que la CPU de la SNES se para cuando se hace un DMA (yo pensaba que si se hacía desde RAM a VRAM se podía mientras transferir de ROM a RAM, o como mínimo, acceder a ROM, pero no es así) con lo que si todo está "desmenuzado" en la ROM, quizá se puedan hacer ciertas cosas porque la CPU interviene menos...

Y en cuanto a tu pregunta, lo cierto es que la arquitectura de la Megadrive no era una virguería de la técnica y no sé si podría hacer por sí misma grandes cosas...

magno escribió:LA verdad es que yo he seguido investigando este tema en el foro de NesDev, para comentar con gente que domina mucho de la SNES sobre los límites a los que se puede llevar ésta...
Sí que está clara la conclusión de que un port 1:1 no es posible, pero sí conseguir algo que visualmente sea igual (vamos, que si no eres mujer creo que no distinguirás el color de un pixel del fondo azul de uno "azul petróleo"... ) y con la misma fluidez... Eso el algo que ahora mismo centra mi atención, puesto que en resolución y colores ya sabemos que estamos limitados... quizá con una ROM muy grande se pueden meter los personajes de AoF con más frames de animación o con más tamaño para el zoom... o bien hacer que los personajes sean un BG cuando están alejados y cargar los sprites cuando están cerca y cosas así (se necesitarían quizá menos frames de animación cuando están lejos porque no pueden recibir físicamente ciertos golpes)...

Pero una limitación enorme que me he encontrado es que la CPU de la SNES se para cuando se hace un DMA (yo pensaba que si se hacía desde RAM a VRAM se podía mientras transferir de ROM a RAM, o como mínimo, acceder a ROM, pero no es así) con lo que si todo está "desmenuzado" en la ROM, quizá se puedan hacer ciertas cosas porque la CPU interviene menos...

Y en cuanto a tu pregunta, lo cierto es que la arquitectura de la Megadrive no era una virguería de la técnica y no sé si podría hacer por sí misma grandes cosas...

Pensé que los DMA servían para descargar a la CPU de esta tarea. ¿porqué se para exáctamente?

sgonzalez escribió:

magno escribió:LA verdad es que yo he seguido investigando este tema en el foro de NesDev, para comentar con gente que domina mucho de la SNES sobre los límites a los que se puede llevar ésta...
Sí que está clara la conclusión de que un port 1:1 no es posible, pero sí conseguir algo que visualmente sea igual (vamos, que si no eres mujer creo que no distinguirás el color de un pixel del fondo azul de uno "azul petróleo"... ) y con la misma fluidez... Eso el algo que ahora mismo centra mi atención, puesto que en resolución y colores ya sabemos que estamos limitados... quizá con una ROM muy grande se pueden meter los personajes de AoF con más frames de animación o con más tamaño para el zoom... o bien hacer que los personajes sean un BG cuando están alejados y cargar los sprites cuando están cerca y cosas así (se necesitarían quizá menos frames de animación cuando están lejos porque no pueden recibir físicamente ciertos golpes)...

Pero una limitación enorme que me he encontrado es que la CPU de la SNES se para cuando se hace un DMA (yo pensaba que si se hacía desde RAM a VRAM se podía mientras transferir de ROM a RAM, o como mínimo, acceder a ROM, pero no es así) con lo que si todo está "desmenuzado" en la ROM, quizá se puedan hacer ciertas cosas porque la CPU interviene menos...

Y en cuanto a tu pregunta, lo cierto es que la arquitectura de la Megadrive no era una virguería de la técnica y no sé si podría hacer por sí misma grandes cosas...

Pensé que los DMA servían para descargar a la CPU de esta tarea. ¿porqué se para exáctamente?

http://es.wikipedia.org/wiki/DMA

Quizás tenga que ver con esto:

"Cabe destacar que aunque no se necesite a la CPU para la transacción de datos, sí que se necesita el bus del sistema (tanto bus de datos como bus de direcciones), por lo que existen diferentes estrategias para regular su uso, permitiendo así que no quede totalmente acaparado por el controlador DMA."

El bus de Snes ya es justo/lento, y quizás al usar DMA se acapare todo su ancho de banda, sin dejar nada para el procesador, y quizás por tanto se optó por pararlo.

Hola, yo dejo otro dato más sobre el mentado cartucho del SF ALPHA 2. El otro día le eché un vistazo al cartucho y veo que tiene un buen puñado de pines más que un cartucho normal, supongo que estará relacionado con el tema del chip descompresor de gráficos.

the_imp escribió:Hola, yo dejo otro dato más sobre el mentado cartucho del SF ALPHA 2. El otro día le eché un vistazo al cartucho y veo que tiene un buen puñado de pines más que un cartucho normal, supongo que estará relacionado con el tema del chip descompresor de gráficos.

¿Te refieres a que es más "ancha" la placa y con más pines, como los juegos con chip Super-FX?

caren103 escribió:
http://es.wikipedia.org/wiki/DMA

Quizás tenga que ver con esto:

"Cabe destacar que aunque no se necesite a la CPU para la transacción de datos, sí que se necesita el bus del sistema (tanto bus de datos como bus de direcciones), por lo que existen diferentes estrategias para regular su uso, permitiendo así que no quede totalmente acaparado por el controlador DMA."

El bus de Snes ya es justo/lento, y quizás al usar DMA se acapare todo su ancho de banda, sin dejar nada para el procesador, y quizás por tanto se optó por pararlo.

Pero como bien pone én el artículo de wikipedia hay diferentes maneras de utilizar la DMA con el bus de datos. Es un poco extraño eso que cuentas aunque supongo que tendrá alguna razón de ser. Pregunta en el foro a ver si alguien sabe algo.

caren103 escribió:

the_imp escribió:Hola, yo dejo otro dato más sobre el mentado cartucho del SF ALPHA 2. El otro día le eché un vistazo al cartucho y veo que tiene un buen puñado de pines más que un cartucho normal, supongo que estará relacionado con el tema del chip descompresor de gráficos.

¿Te refieres a que es más "ancha" la placa y con más pines, como los juegos con chip Super-FX?

Respecto a esto segundo si SF2A usa el patillaje extra del cartucho, como los SuperFX puede que se deba a que el chip descompresor famoso utilice el bus para acceder directamente a la VRAM ¿?¿?

Saludetes.

sgonzalez escribió:

caren103 escribió:
http://es.wikipedia.org/wiki/DMA

Quizás tenga que ver con esto:

"Cabe destacar que aunque no se necesite a la CPU para la transacción de datos, sí que se necesita el bus del sistema (tanto bus de datos como bus de direcciones), por lo que existen diferentes estrategias para regular su uso, permitiendo así que no quede totalmente acaparado por el controlador DMA."

El bus de Snes ya es justo/lento, y quizás al usar DMA se acapare todo su ancho de banda, sin dejar nada para el procesador, y quizás por tanto se optó por pararlo.

Pero como bien pone én el artículo de wikipedia hay diferentes maneras de utilizar la DMA con el bus de datos. Es un poco extraño eso que cuentas aunque supongo que tendrá alguna razón de ser. Pregunta en el foro a ver si alguien sabe algo.

El extracto está sacado del enlace que pongo de la Wikipedia.

Yo no lo sé, pero supongo que si la arquitectura de la Snes está diseñada para trabajar así, pues sería una hipótesis a por qué se para el procesador cuando se usa la DMA.

Tengo el Exhaust Heat 2 de Super Famicom y tambien tiene la plaqueta mas larga y con mas pines, sera que todos los cartuchos de SNES con chips especiales son asi, el EH2 tiene el ST010.

Pinout de los cartuchos de SNES (sacado de aquí):

Vemos que parte de esos pines extras (PA0-PA7,/PARD,/PAWR) son para el Bus de direcciones B. Consultando la Wikipedia:

The 24-bit "Bus A" is used for general accesses, while the 8-bit "Bus B" is used for support chip registers (mainly the video and audio processors). Normally only one bus is used at a time, however the built in direct memory access (DMA) unit places a read signal on one bus and a write signal on the other to achieve block transfer speeds of up to 2.68 MB/s

El Bus B se usa para los registros de los chips especiales.

Imagen de un juego con chip SDD-1 (sacado de aquí, que además tiene información sobre los pinout de los chips especiales de SNES y tutoriales en inglés para cambiar las roms de los cartuchos )

Sobre la pregunta original, alguien me puede decir que juegos se consideran "lo mejore de AES"? tanto gráficamente como en cálculos. ¿El MOTW, por ejemplo?

Eteream.... llegas varios días tarde al hilo, y por lo que veo, no da la impresión de haber leído mucho de él.

Pues voy a decir la mía, basado sólo en lo que ven mis ojos (o sea, que puedo errar cual escopeta de feria): uno sería el Prehistoric Isle 2 (MVS).

caren103 escribió:Eteream.... llegas varios días tarde al hilo, y por lo que veo, no da la impresión de haber leído mucho de él.

Pues voy a decir la mía, basado sólo en lo que ven mis ojos (o sea, que puedo errar cual escopeta de feria): uno sería el Prehistoric Isle 2 (MVS).

La verdad, no lo he leido todo, pero lo suficiente como para comprender que tengo que meditar las respuestas pq hay muchas cosas (como mínimo) discutibles y no es cuestión de "ir haciendo amigos". Por ejemplo tenia esta bala en la recamara:

Hasta la llegada de la PS2, el dma y la cpu comparten canales, por lo tanto si uno lo usa puntualmente el otro no puede usarlo.

¿Y cual es el problema con que la dma pare la cpu? Creo que (en este tipo de programas) es lo ideal, sinó aparace la pregunta ¿y ahora que hacemos?, la dma perderia velocidad, sistemas de sincronización, etc... En cambio de esta manera siempre puedes seleccionar el tamaño a copiar, y conocer a priori exactamente el tiempo que tardará. No le veo el problema. Por pedir, siempre se puede pedir, pero el dma ya es una mejora significativa respecto a mover datos por cpu, como mínimo del 300% (incremetar 2 registros-punteros + 1 carga), dependiendo de la cpu puede que bastante más.

A ver, lo del DMA de la SNES es porque la transferencia se hace sobre el bus A de la SNES hacia el B (normalmente, aunque se puede hacer al revés), es decir, desde el bus principal hacia el bus de la VRAM. Así que la SNES no puede en eso momento ni acceder a RAM ni a ROM, así que mejor pararse. Eso la convierte en lenta de cojones, puesto que toda la porción del tiempo del NMI se tiene que quedar sin hacer nada, y en los HDMA, durante 18 ciclos EN CADA LÍNEA DE PANTALLA, se ha de parar también.

Esto se enlaza con lo que dice eteream y contesta a su pregunta: si no se parase porque los buses fueran independientes podrías usar la memoria de la SNES para hacer como un "doble buffer" básico: en el NMI transfieres de RAM a VRAM el frame y de ROM a RAM el siguiente (tiles para sprites o lo que sea necesario), a parte de poder seguir usando el tiempo de proceso durante el DMA para lo que necesitaras: ejecutar rutinas de control, hacer cálculos, lo que sea... Creo que por eso siempre se ha dicho que el cuello de botella era la CPU en la SNES, porque se pasa mucho tiempo parada si la imagen es demasiado compleja (muchas transferencias a VRAM).

En cuanto a lo de los pines, se necesitan para CASI todos los chips especiales, puesto que esos pines llevan el reloj maestro (el de 21 MHz, no es el que usa la CPU para correr) hacia el chip y el bus B del sistema. Así, cuando el SDD-1 (el del Star Ocean o de SFA2) tiene que descomprimir algunos gráficos, el programa que está ejecutando la SNES escribe en la dirección del bus B $4800, acción que no desencadena nada en el sistema, pero sí en el SDD-1 que ha estado monitorizando la aparición de esa dirección en el bus. En ese momento se pone a descomprimir y enviar datos al vuelo por DMA a la VRAM o RAM, dependiendo de los que se configure en los registros $480X; ahí se habrá escrito antes de empezar la transferencia la dirección origen de los datos en ROM y el destino. Por supuesto que esto para la SNES y no se puede hacer "multitarea", cosa que sí hace el SuperFX y el SA-1.

El Street Fighter 2 Turbo de SNES copia los sprites de los personajes de la ROM a la VRAM a gran velocidad sin ningún problema, mientras se van usando.

Luego no sé qué limitaciones veis a que los sprites fueran más grandes y con más animaciones.

DevilKenMasters escribió:El Street Fighter 2 Turbo de SNES copia los sprites de los personajes de la ROM a la VRAM a gran velocidad sin ningún problema, mientras se van usando.

Luego no sé qué limitaciones veis a que los sprites fueran más grandes y con más animaciones.

Casi todos los juegos hacen eso... raramente se pasan primero a RAM a menos de que haya que hacer algo con ellos (que no suele ser el caso, ya que los sprites suelen venir dibujados en todos sus frames de animación en ROM).

La limitación a eso que comentas es la cantidad de sprites en pantalla, pero en principio no tiene que ver con el DMA...

No conozco el hardware de snes, pero por otras consolas/máquinas parecidas:

magno escribió:A ver, lo del DMA de la SNES es porque la transferencia se hace sobre el bus A de la SNES hacia el B (normalmente, aunque se puede hacer al revés), es decir, desde el bus principal hacia el bus de la VRAM. Así que la SNES no puede en eso momento ni acceder a RAM ni a ROM, así que mejor pararse.

Esa es una posible solución, barata y sencilla. Pero por ejemplo no es válida para un SO. Tampoco entiendo, entonces, que pasa si viene una interrupción.

magno escribió:Eso la convierte en lenta de cojones, puesto que toda la porción del tiempo del NMI se tiene que quedar sin hacer nada, y en los HDMA, durante 18 ciclos EN CADA LÍNEA DE PANTALLA, se ha de parar también.

Traduzco para mi mismo:
HDMA - hbank
NMI - vbank

Si "se tiene que quedar sin hacer nada" significa que la cpu no hace, literalmente, nada no creo que sea verdad. Lo que si pasa en algunos casos es que mientras el dispositivo gráfico accede a la memoria de video nadie más puede acceder sin que ocurran accidentes, pero la cpu puede estar trabajando con otras memoria o usando la dma mientras no se toque la memoria de video.

Por ejemplo, algo que se suele hacer es preparar la configuración de los sprites (que no su contenido) en la ram durante el pintado de pantalla y luego en el vbank mediante dma cambiar el contenido rápidamente.

Para cambiar el contenido de los titles completamente (que también pueden ser sprites), lo que se suele hacer es apagar el chip gráfico para poder acceder a la memoria de video sin temor. De ahí el tiempo de espera entre fases con la pantalla en negro, por ejemplo del Castlevania 4.

magno escribió:Esto se enlaza con lo que dice eteream y contesta a su pregunta: si no se parase porque los buses fueran independientes podrías usar la memoria de la SNES para hacer como un "doble buffer" básico: en el NMI transfieres de RAM a VRAM el frame y de ROM a RAM el siguiente (tiles para sprites o lo que sea necesario), a parte de poder seguir usando el tiempo de proceso durante el DMA para lo que necesitaras: ejecutar rutinas de control, hacer cálculos, lo que sea... Creo que por eso siempre se ha dicho que el cuello de botella era la CPU en la SNES, porque se pasa mucho tiempo parada si la imagen es demasiado compleja (muchas transferencias a VRAM).

Normalmente no veo necesario hacer ningún doble buffer, no veo que se gane nada. No se pq otros dirán que la cpu de la snes es mala, pero yo lo digo por:
- Tiene pocos mhz
- Es una cpu de 8bits vitaminada a 16bits
- Su conjunto de instrucciones es penoso para la época que salió.

Entiendo que detrás de esta decisión está lo siguiente:
- Para hacer juegos 2d normales no es necesario más cpu, mejor invertir en el chip gráfico.
- Es parecida a la cpu de la nes, así los programadores no tienen que aprender nada nuevo (a alguien no le extrañó que los primeros juegos de snes fueran globalmente los mejores?, aquí está la respuesta)

Eteream, no era mi intención molestar a nadie, aunque tal y como lo he escrito (con prisas y rápido) pues ha salido lo que ha salido... lo decía por la pregunta del Mark of the Wolves, pues el juego fue mentado varias veces durante el hilo.

Bueno, digamos que Nintendo quiso racanear en la CPU, y a partir de ahí en otros aspectos de la arquitectura por "culpa" de la CPU, y de ahí el cuello de botella y el hecho que tenga que parar la CPU cuando se usa DMA, ¿no?

Eteream escribió:Esa es una posible solución, barata y sencilla. Pero por ejemplo no es válida para un SO. Tampoco entiendo, entonces, que pasa si viene una interrupción.

No puede venir una interrupción porque los DMA sólo se ejecutan durante el NMI = Non Maskarable Interrupt, así que mientras esta interrupción está activa, se deshabilita la IRQ (que es la otra señal de activación). Durante el H-DMA (DMA horizontal que ocurre en los primeros 18 ciclos maestros tras el sincronismo horizontal) no puede saltar la NMI porque está en una línea de video activo, así que tampoco hay interrupción. Si la IRQ salta en este momento, lo mismo, queda inhibida hasta que la CPU salga del estado STALL.

Eteream escribió:Si "se tiene que quedar sin hacer nada" significa que la cpu no hace, literalmente, nada no creo que sea verdad. Lo que si pasa en algunos casos es que mientras el dispositivo gráfico accede a la memoria de video nadie más puede acceder sin que ocurran accidentes, pero la cpu puede estar trabajando con otras memoria o usando la dma mientras no se toque la memoria de video.
Por ejemplo, algo que se suele hacer es preparar la configuración de los sprites (que no su contenido) en la ram durante el pintado de pantalla y luego en el vbank mediante dma cambiar el contenido rápidamente.

Pues sí, sí es verdad lo que he dicho, puedes consultarlo en cualquier documentación actualizada de la SNES. La CPU no puede trabajar con la memoria porque INSISTO que el bus A se usa para la DMA: las transferencias son desde el bus A (que conecta RAM con CPU) y el bus B (que conecta la VRAM con CPU), así que al estar ocupados, no se puede hacer nada de nada. Así que lo de la preparación de los sprites, que podría ser una opción, no ocurre.

Eteream escribió:Para cambiar el contenido de los titles completamente (que también pueden ser sprites), lo que se suele hacer es apagar el chip gráfico para poder acceder a la memoria de video sin temor. De ahí el tiempo de espera entre fases con la pantalla en negro, por ejemplo del Castlevania 4.

En absoluto, eso es totalmente imposible. Si "apagaras" el chip gráfico, la TV perdería el sincronismo de línea y la imagen temblaría. Lo que pasa es que la memoria de video se puede escribir SOLO mientras no se está leyendo, y eso ocurre cuando el chip gráfico está haciendo el barrido vertical. La VRAM no es de doble puerto: si lees, no escribes, y viceversa.

Eteream escribió:Normalmente no veo necesario hacer ningún doble buffer, no veo que se gane nada. No se pq otros dirán que la cpu de la snes es mala, pero yo lo digo por:
- Tiene pocos mhz
- Es una cpu de 8bits vitaminada a 16bits
- Su conjunto de instrucciones es penoso para la época que salió.

El doble buffer es una técnica que se usa en todas las tarjetas gráficas, así que alguna mejora traerá. Si se pudiera hacer como decía yo antes, en la hipótesis que dije con otra arquitectura diferente, se gana EL DOBLE DE TIEMPO, ya que mientras se transfiere de RAM a VRAM se hace simultáneamente de ROM a RAM.

En cuanto a las afirmaciones sobre la CPU son totalmente erróneas... en absoluto es una arquitectura de 8 bits vitaminada a nada... es una arquitectura completa de 16 bits pero compatible hacia atrás. Te recuerdo que ese micro se usa en el Apple II GS. Y su conjunto de instrucciones es exactamente como cualquiera de su época (¡¡¡¡1986!!!!!) un RISC como los de toda la vida.


Hay que informarse un poquillo más antes de afirmar tantas cosas ligeramente, ¿eh?

caren103 escribió:Eteream, no era mi intención molestar a nadie, aunque tal y como lo he escrito (con prisas y rápido) pues ha salido lo que ha salido... lo decía por la pregunta del Mark of the Wolves, pues el juego fue mentado varias veces durante el hilo.

Bueno, digamos que Nintendo quiso racanear en la CPU, y a partir de ahí en otros aspectos de la arquitectura por "culpa" de la CPU, y de ahí el cuello de botella y el hecho que tenga que parar la CPU cuando se usa DMA, ¿no?

No pasa nada! Tu preguntas y yo te contesto.

magno escribió:...

Uno de los dos (o bién tú o bién yo) tiene un lio de conceptos bastante importante y necesita de más base teórica. Te intentaré ir respondiendo cosa a cosa, pero has abierto tantos temas de golpe que necesitaré tiempo.

Ok, siempre está bien estas conversaciones para aclarar conceptos que uno puede tener equivocados, siempre que alguien te conteste con datos objetivos y no con cosas como "me lo dijo mi primo" o "es así porque se ve en la TV mejor"

Espero tu respuestas porque después de 9 años programando para SNES pensaba que tenía más o menos claro casi todo el subsistema de video pero en estos días pasados, y gracias a este tema, en el foro de NesDev he aprendido un montón de detalles técnicos que no sabía. Puedes contrastar casi todo lo que he dicho con la documentación de Nevitski (incluso con sus esquemáticos, que son liosos pero ayudan) o con la información que hay en ese foro que te comentaba.

Por cierto, ¿tú qué piensas sobre el tema central, eteream? ¿Crees que se podría o que no? Anda, mójate

Eteream escribió:- Es parecida a la cpu de la nes, así los programadores no tienen que aprender nada nuevo (a alguien no le extrañó que los primeros juegos de snes fueran globalmente los mejores?, aquí está la respuesta)

pues no, no me extraño. es obio que serian mejores que los de cualquier de 8 bits y si supero a MD era por que salio con 2 años de ventaja y como practicamente no tenian competencia se lo tomaron con calma.

El Mark of the Wolves es la prueba viviente de que un juego es mejor considerado técnicamente por tener un puñado de megas más que el resto, cuando realmente empuja mucho más el hardware un Art of Fighting 1, con muchísimos menos megas.

El Mark of the Wolves es un juego de lucha con 2 personajes, un fondo y muchos frames de animación almacenados en sus megas. Por eso no tuvo versión Neo Geo CD, no porque ésta no tuviera potencia suficiente, sino que no podía cargar todos los frames en la ram. Y por eso mismo no tuvo versión PSX ni Saturn, aunque en esta última podría haberla tenido seguramente con un cartucho de ROM o RAM. Y por qué no, si en el tiempo hubiesen coincidido, hasta Mega CD o PC Engine CD, pero también tenía el problema de Neo Geo CD de la RAM.

Claramente en Mega y SNES habrían recortado animaciones a muerte... para ahorrar en megas, porque ni siquiera los luchadores son de lo más grande en Neo Geo.

La verdad es que el Mark of the Wolves rezuma carisma por todos sus poros, con unos diseños de fondos y personajes fantásticos.

Y es que la dirección artística es importantísima, más allá de limitaciones técnicas (y que una buena dirección artística sabe incluso aprovechar en su favor).

magno escribió:Y su conjunto de instrucciones es exactamente como cualquiera de su época (¡¡¡¡1986!!!!!) un RISC como los de toda la vida.

Bueno, tiene rasgos RISC como por ejemplo instrucciones simples, como CISC, por ejemplo el tamaño de instrucción no es fijo y soporta varios modos de direccionamiento.

Lo he visto catalogado tanto como CISC como RISC, no diría que es ni CISC ni RISC, solo coge lo que le interesa de cada filosofía.

wah_wah_69 escribió:

magno escribió:Y su conjunto de instrucciones es exactamente como cualquiera de su época (¡¡¡¡1986!!!!!) un RISC como los de toda la vida.

Bueno, tiene rasgos RISC como por ejemplo instrucciones simples, como CISC, por ejemplo el tamaño de instrucción no es fijo y soporta varios modos de direccionamiento.

Lo he visto catalogado tanto como CISC como RISC, no diría que es ni CISC ni RISC, solo coge lo que le interesa de cada filosofía.

Pues sí, tienes razón, realmente se parece más a un CISC quizá...

magno escribió:

wah_wah_69 escribió:

magno escribió:Y su conjunto de instrucciones es exactamente como cualquiera de su época (¡¡¡¡1986!!!!!) un RISC como los de toda la vida.

Bueno, tiene rasgos RISC como por ejemplo instrucciones simples, como CISC, por ejemplo el tamaño de instrucción no es fijo y soporta varios modos de direccionamiento.

Lo he visto catalogado tanto como CISC como RISC, no diría que es ni CISC ni RISC, solo coge lo que le interesa de cada filosofía.

Pues sí, tienes razón, realmente se parece más a un CISC quizá...

Los procesadores CISC no existen. Hace largo tiempo existieron cpu capaces de hacer en una instrucci'on lo que ahora consideramos todo un bucle.

Lo de CISC/RISC, m'as que algo tangible, es un medida para medir la complejidad de las instrucciones. No voy a hablar m'as de este tema pq esto suele llevar adiscusiones totalmente surrealistas y que no llevan a ninguna parte.

No sé si sn y md podrian hacer un 1:1 de esos bichos, pero, y mega cd?
En un hilo de sega 16 hablaban del samurai shodown cd, y comentaban que, finalmente, decidieron no incluir a Earthquake porque probablemente el juego sería injugable (muy lento, o con mucho flickering) cuando se enfrentasen entre ellos.

Vamos, que, en este caso, la memoria no era un problema.

Aún así, podrían haber optado por hacer un sprite no tan grande (tipo big bear, del ffs) para que diese la impresión de ser de mayor tamaño que el resto.

Las versiones del ss y ffs de mega cd, graficamente, son muy parecidas a las originales de neo geo. Eso si, hay mucho recorte en los escenarios.





Vistas así, parece que los luchadores sean más grandes en mcd, pero si guardáis las fotos y las ponéis a pantalla completa, veréis como son exactamente del mismo tamaño (milimetro más, milimetro menos).

Esto, respecto al mega cd. Si miramos las versiones mega drive de estos juegos, podremos observar como los sprites son ligeramente más pequeños (tanto con fatal fury 2, como con samurai shodown), y tienen un marco por la parte superior e inferior.

Por cantidad de sprites en pantalla, y viendo el bestial flickering que hay en el keio flying squadron, se me hace dificil pensar en un metal slug, o en un blazing star para esta plataforma.

En el Samurai Showdown de MegaCD también "recortaron" al árbitro, mientras que en el de Megadrive sí aparece.

the_imp escribió:En el Samurai Showdown de MegaCD también "recortaron" al árbitro, mientras que en el de Megadrive sí aparece.

Del samurai showdown, en mega cd el problema es la memoria ram, y en megadrive, el tamaño del cartucho (earthquake aparte, nunca sabremos si se podría o no).

En Mega CD los sprites son del mismo tamaño en el Fatal Fury Special que en Neo Geo CD.

Y mueve perfectamente a Big Bear.

La RAM es la limitación ahí.

John Torrijas escribió:No sé si sn y md podrian hacer un 1:1 de esos bichos, pero, y mega cd?
En un hilo de sega 16 hablaban del samurai shodown cd, y comentaban que, finalmente, decidieron no incluir a Earthquake porque probablemente el juego sería injugable (muy lento, o con mucho flickering) cuando se enfrentasen entre ellos.

Vamos, que, en este caso, la memoria no era un problema.

Aún así, podrían haber optado por hacer un sprite no tan grande (tipo big bear, del ffs) para que diese la impresión de ser de mayor tamaño que el resto.

Las versiones del ss y ffs de mega cd, graficamente, son muy parecidas a las originales de neo geo. Eso si, hay mucho recorte en los escenarios.





Vistas así, parece que los luchadores sean más grandes en mcd, pero si guardáis las fotos y las ponéis a pantalla completa, veréis como son exactamente del mismo tamaño (milimetro más, milimetro menos).

Esto, respecto al mega cd. Si miramos las versiones mega drive de estos juegos, podremos observar como los sprites son ligeramente más pequeños (tanto con fatal fury 2, como con samurai shodown), y tienen un marco por la parte superior e inferior.

Por cantidad de sprites en pantalla, y viendo el bestial flickering que hay en el keio flying squadron, se me hace dificil pensar en un metal slug, o en un blazing star para esta plataforma.

Si estamos hablando de un port 1:1 tenemos que ser mucho más detallistas, y en esas dos imágenes hay muchas cositas que no son iguales.

El Gran Talón de Aquiles de la MD (y por tanto del MCD, ya que comparten dispositivo gráfico (creo)) es que sólo tiene 4 paletas de 16 colores; además el color transparente para los sprites gasta un color.

No se como deben estar distribuidas, pero por decir algo:
1 paleta para el fondo
1 paleta para cada enemigo (2)
1 paleta para todo lo demás (caras, barras, letras)

Así que el fondo sólo debe tener 16 colores, si nos fijamos bien, 4 colores rojos se repiten en el volcán, en el suelo, en el camión, en el 4x4, etc En la versión de neogeo cada uno de estos elementos tiene sus propios colores. Ahora que lo he comentado seguro que saltará a la vista.
Los personajes si parecen usar los mismos colores y ser casi los mismos sprites. PERO tiene las mismas animaciones que en neogeo? (no lo se, sólo pregunto)

Después si te fijas la versión neogeo tiene 3 tipos de fuente de letras (inportante: IN GAME), la de MD sólo una. También se puede ver ahorro de memoria ROM (tb sprites?) en otros detalles.

La MD puede desplegar 80x32x32 pixels en sprites, o sea: 81920. Calculando POR ENCIMA en la imagen de neogeo, me sale que un personje ocupa unos 37000. Así que le va justo para los dos personajes y barras, caras, etc...



(a ver si modifico un emu para que muestre los cuadrados en los sprites, seria interesante...)

Después me he fijado que los juegos de lucha para snes/md no suelen tener casi scrolls. ¿Pasa lo mismo en neogeo? Fijaros que el Ristar tiene hasta 7 (o 12, según se mire) planos de scroll (algunos hardware, otros software). Las animaciones de los todos personajes deben ocupar tanto en la ROM que no hay espacio para mucho más, aunque el sistema podría dar más de si.

Como curiosidad, la versión neogeo es como más cartoon y en cambio la de Genesis es mucho más radical-gamberra. Una manera de contentar el público destino y ahorrarte unos colores.

En resumen, mejorar esto en MD va a ser muy laborioso, en cambio me parece que en neogeo no seria demasiado problema (hay juegos mejores, ¿no?).

Eteream escribió:

John Torrijas escribió:No sé si sn y md podrian hacer un 1:1 de esos bichos, pero, y mega cd?
En un hilo de sega 16 hablaban del samurai shodown cd, y comentaban que, finalmente, decidieron no incluir a Earthquake porque probablemente el juego sería injugable (muy lento, o con mucho flickering) cuando se enfrentasen entre ellos.

Vamos, que, en este caso, la memoria no era un problema.

Aún así, podrían haber optado por hacer un sprite no tan grande (tipo big bear, del ffs) para que diese la impresión de ser de mayor tamaño que el resto.

Las versiones del ss y ffs de mega cd, graficamente, son muy parecidas a las originales de neo geo. Eso si, hay mucho recorte en los escenarios.





Vistas así, parece que los luchadores sean más grandes en mcd, pero si guardáis las fotos y las ponéis a pantalla completa, veréis como son exactamente del mismo tamaño (milimetro más, milimetro menos).

Esto, respecto al mega cd. Si miramos las versiones mega drive de estos juegos, podremos observar como los sprites son ligeramente más pequeños (tanto con fatal fury 2, como con samurai shodown), y tienen un marco por la parte superior e inferior.

Por cantidad de sprites en pantalla, y viendo el bestial flickering que hay en el keio flying squadron, se me hace dificil pensar en un metal slug, o en un blazing star para esta plataforma.

Si estamos hablando de un port 1:1 tenemos que ser mucho más detallistas, y en esas dos imágenes hay muchas cositas que no son iguales.

El Gran Talón de Aquiles de la MD (y por tanto del MCD, ya que comparten dispositivo gráfico (creo)) es que sólo tiene 4 paletas de 16 colores; además el color transparente para los sprites gasta un color.

No se como deben estar distribuidas, pero por decir algo:
1 paleta para el fondo
1 paleta para cada enemigo (2)
1 paleta para todo lo demás (caras, barras, letras)

Así que el fondo sólo debe tener 16 colores, si nos fijamos bien, 4 colores rojos se repiten en el volcán, en el suelo, en el camión, en el 4x4, etc En la versión de neogeo cada uno de estos elementos tiene sus propios colores. Ahora que lo he comentado seguro que saltará a la vista.
Los personajes si parecen usar los mismos colores y ser casi los mismos sprites. PERO tiene las mismas animaciones que en neogeo? (no lo se, sólo pregunto)

Después si te fijas la versión neogeo tiene 3 tipos de fuente de letras (inportante: IN GAME), la de MD sólo una. También se puede ver ahorro de memoria ROM (tb sprites?) en otros detalles.

La MD puede desplegar 80x32x32 pixels en sprites, o sea: 81920. Calculando POR ENCIMA en la imagen de neogeo, me sale que un personje ocupa unos 37000. Así que le va justo para los dos personajes y barras, caras, etc...



(a ver si modifico un emu para que muestre los cuadrados en los sprites, seria interesante...)

Después me he fijado que los juegos de lucha para snes/md no suelen tener casi scrolls. ¿Pasa lo mismo en neogeo? Fijaros que el Ristar tiene hasta 7 (o 12, según se mire) planos de scroll (algunos hardware, otros software). Las animaciones de los todos personajes deben ocupar tanto en la ROM que no hay espacio para mucho más, aunque el sistema podría dar más de si.

Como curiosidad, la versión neogeo es como más cartoon y en cambio la de Genesis es mucho más radical-gamberra. Una manera de contentar el público destino y ahorrarte unos colores.

En resumen, mejorar esto en MD va a ser muy laborioso, en cambio me parece que en neogeo no seria demasiado problema (hay juegos mejores, ¿no?).

Se agradecen MUCHO las aportaciones así pues siempre se aprende.

Desde luego, fotos estáticas siempre he pensado que no es el mejor patrón para comparar fiablemente, y aún así resaltan detalles como los que has comentado.

Respecto a juegos mejores de lucha a nivel técnico, pues obviamente, los Samurai más adelantados (el 4 por ejemplo; el V Special Unfixed puse un video muy espectacular de los Fatalities, donde ya se ve a nivel técnico un "grifón" de trabajo gráfico en lo que dura la "masacre"), y desde luego no puedo obviar los Last Blade 1 y 2, con algunos escenarios que quitan el hipo, amén de un nivel artístico y jugable tremebundo.

Vaya, no te recuerdo agradeciéndome MUCHO la aportación del video del genecyst... que ya no me estás?

Snes puede que no, pero UNA Megadrive sí podía con lo mismo que Neo-Geo:

Eso si que es una consolización de una MVS guapa...

caren103 escribió:Snes puede que no, pero UNA Megadrive sí podía con lo mismo que Neo-Geo:

NO SNK-neogeo. Todo el mundo sabe que el metal slug 4 es de playmore

Viendo lo que puede dar de si la "consolizacion casera" no entiendo por que SNK no opto directamente por meter una MVS pura en la AES... Con meterles una pegatina, una caja y un manual a los cartuchos de MVS ya tendrian el negocio listo... (en el fondo es asi, pero como los cartuchos de AES y MVS no son "identicos" fisicamente... no entiendo por que narizes hicieron esa diferencia... ¿quizas para que lo "casero" no fuera "tan barato" como en las recreativas para que el mercado de recreativas no se fuera al garete?, no se... es que en SNK para hacer juegos eran unos genios, pero para venderlos eran unos zoquetes...

chachin2007 escribió:Viendo lo que puede dar de si la "consolizacion casera" no entiendo por que SNK no opto directamente por meter una MVS pura en la AES... Con meterles una pegatina, una caja y un manual a los cartuchos de MVS ya tendrian el negocio listo... (en el fondo es asi, pero como los cartuchos de AES y MVS no son "identicos" fisicamente... no entiendo por que narizes hicieron esa diferencia... ¿quizas para que lo "casero" no fuera "tan barato" como en las recreativas para que el mercado de recreativas no se fuera al garete?, no se... es que en SNK para hacer juegos eran unos genios, pero para venderlos eran unos zoquetes...

Ahí está. SNK pensaba que el mercado domestico no sería un mal pellizco, pero que el groso de sus ingresos llegarían a través de los salones arcade. Por aquel entonces era impensable que los salones arcade fueran sustituibles, y de hecho, interesaba que no dejara de ser el negocio que estaba siendo.

...supongo que la existencia de una AES, hizo pensar a la gente que también quería esa calidad en su casa SI o SI... y lo que fué sin querer (MVS como negocio, y AES como anecdota que de publicidad), se convirtió en el germen que se cargó a toda una industría (la next gen siguiente fué el principio del fin).

chachin2007 escribió:Viendo lo que puede dar de si la "consolizacion casera" no entiendo por que SNK no opto directamente por meter una MVS pura en la AES... Con meterles una pegatina, una caja y un manual a los cartuchos de MVS ya tendrian el negocio listo... (en el fondo es asi, pero como los cartuchos de AES y MVS no son "identicos" fisicamente... no entiendo por que narizes hicieron esa diferencia... ¿quizas para que lo "casero" no fuera "tan barato" como en las recreativas para que el mercado de recreativas no se fuera al garete?, no se... es que en SNK para hacer juegos eran unos genios, pero para venderlos eran unos zoquetes...

Esa diferencia lo hicieron porque el precio del cartucho MVS de un juego era muy superior al del cartucho AES del mismo juego, y así evitaban que el dueño de un salón recreativo comprara la versión AES para conectarla a la placa MVS de la cabina arcade.

Una muestra más de la lógica del coleccionismo. El MVS era mucho más caro, y ahora es mucho más barato.

Yippie!

DevilKenMasters escribió:Una muestra más de la lógica del coleccionismo. El MVS era mucho más caro, y ahora es mucho más barato.

Yippie!

Lógico, la gente prefiere tener una AES en lugar de una MVS, en la cual las cajas, manuales y etiquetas no vienen de igual forma en MVS. Es el interés por la AES y sus mejores ediciones respecto a la MVS lo que hacen que se valoren más.

Tu lo has dicho, que se valoren, pero su valor real era otro totalmente distinto. De hecho la versión doméstica tiene su caja y manual pero la arcade tiene otra caja y también tiene pegatinas, flyers y polladas varias.

Pero es lo de siempre y no entraremos en lo mismo que luego nos cierran los hilos. Yo en cualquier caso celebro que los coleccionistas hayan infravalorado las mvs, que a mí personalmente me gustan más y encima me salen más baratas

caren103 escribió:

chachin2007 escribió:Viendo lo que puede dar de si la "consolizacion casera" no entiendo por que SNK no opto directamente por meter una MVS pura en la AES... Con meterles una pegatina, una caja y un manual a los cartuchos de MVS ya tendrian el negocio listo... (en el fondo es asi, pero como los cartuchos de AES y MVS no son "identicos" fisicamente... no entiendo por que narizes hicieron esa diferencia... ¿quizas para que lo "casero" no fuera "tan barato" como en las recreativas para que el mercado de recreativas no se fuera al garete?, no se... es que en SNK para hacer juegos eran unos genios, pero para venderlos eran unos zoquetes...

Esa diferencia lo hicieron porque el precio del cartucho MVS de un juego era muy superior al del cartucho AES del mismo juego, y así evitaban que el dueño de un salón recreativo comprara la versión AES para conectarla a la placa MVS de la cabina arcade.

Pero una cosa... si en MVS un juego le costava 100€ al pavo de las salones recreativos y en AES para el publico lo metian a 300€... ¿por que esa diferencia?..., si los juegos son lo mismo (por que son lo mismo) no entiendo por que en AES era tan caros..., no creo que los salones pagaran mas por un juego de MVS que de AES, por que de ser asi... comprarian una AES para cada recreativa y a chutar... ¿no?.
Yo creo que metieron los juegos en AES extremadamente caros para simplemente forrarse... por que claro... "Si quieres tener la recreativa en casa, ¡¡paga!!" y les salio el tiro por la culata..., encima para cuando se dieron cuenta del gran error y adoptaron un formato y unos precios mas "justos" (para el consumidor) la cagaron con el Hardware (en este caso, con los lectores de la consolas CD).
Estos de SNK en vez de bajarse los pantalones y dejar de vender juegos a 60.000 ptas de AES para venderlos a 20.000 ptas, decidieron pasar al CD "para la gente pobre", pero la gente pobre no queria pagar 15.000 pelas por un juego que cargaba LENTO y que era ligeramente inferior a los de AES (la que todo el mundo queria tener y no podia), asi la AES seguia siendo la joya de la corona y la imagen de "Coche caro" PARA LA GENTE RICA la mantenia SNK... pero esa imagen les costo la empresa...
Yo creo que SNK desarrollo grandes juegazos (sin duda) pero como empresa fue una autentica mierda... por que no tiene sentido sacar tres modelos de Neo geo CD para luego seguir haciendo juegos para la AES (la AES sobrevivio a las Neo geo CD's...) asi que lo de que el formato "cartucho" era caro, pues como que no tiene sentido...
Gracias a los niños ricos la AES les seguia dando pasta para ir aguantando los fracasos con el mercado "pobre"... pero no contaron con que incluso el mercado "rico" se centro en consolas como MD, SNES, PSX, Saturn...
Asi se fue SNK a la tumba economica...

68000 escribió:Es el interés por la AES y sus mejores ediciones respecto a la MVS lo que hacen que se valoren más.

Pues yo no creo k se valore mas la AES respecto a la MVS por "sus mejores ediciones" incluso diria k ese seria el ultimo motivo.

chachin2007 escribió:

caren103 escribió:

chachin2007 escribió:Viendo lo que puede dar de si la "consolizacion casera" no entiendo por que SNK no opto directamente por meter una MVS pura en la AES... Con meterles una pegatina, una caja y un manual a los cartuchos de MVS ya tendrian el negocio listo... (en el fondo es asi, pero como los cartuchos de AES y MVS no son "identicos" fisicamente... no entiendo por que narizes hicieron esa diferencia... ¿quizas para que lo "casero" no fuera "tan barato" como en las recreativas para que el mercado de recreativas no se fuera al garete?, no se... es que en SNK para hacer juegos eran unos genios, pero para venderlos eran unos zoquetes...

Esa diferencia lo hicieron porque el precio del cartucho MVS de un juego era muy superior al del cartucho AES del mismo juego, y así evitaban que el dueño de un salón recreativo comprara la versión AES para conectarla a la placa MVS de la cabina arcade.

Pero una cosa... si en MVS un juego le costava 100€ al pavo de las salones recreativos y en AES para el publico lo metian a 300€... ¿por que esa diferencia?..., si los juegos son lo mismo (por que son lo mismo) no entiendo por que en AES era tan caros..., no creo que los salones pagaran mas por un juego de MVS que de AES, por que de ser asi... comprarian una AES para cada recreativa y a chutar... ¿no?.
Yo creo que metieron los juegos en AES extremadamente caros para simplemente forrarse... por que claro... "Si quieres tener la recreativa en casa, ¡¡paga!!" y les salio el tiro por la culata..., encima para cuando se dieron cuenta del gran error y adoptaron un formato y unos precios mas "justos" (para el consumidor) la cagaron con el Hardware (en este caso, con los lectores de la consolas CD).
Estos de SNK en vez de bajarse los pantalones y dejar de vender juegos a 60.000 ptas de AES para venderlos a 20.000 ptas, decidieron pasar al CD "para la gente pobre", pero la gente pobre no queria pagar 15.000 pelas por un juego que cargaba LENTO y que era ligeramente inferior a los de AES (la que todo el mundo queria tener y no podia), asi la AES seguia siendo la joya de la corona y la imagen de "Coche caro" PARA LA GENTE RICA la mantenia SNK... pero esa imagen les costo la empresa...
Yo creo que SNK desarrollo grandes juegazos (sin duda) pero como empresa fue una autentica mierda... por que no tiene sentido sacar tres modelos de Neo geo CD para luego seguir haciendo juegos para la AES (la AES sobrevivio a las Neo geo CD's...) asi que lo de que el formato "cartucho" era caro, pues como que no tiene sentido...
Gracias a los niños ricos la AES les seguia dando pasta para ir aguantando los fracasos con el mercado "pobre"... pero no contaron con que incluso el mercado "rico" se centro en consolas como MD, SNES, PSX, Saturn...
Asi se fue SNK a la tumba economica...

Eso no era así entonces.

Un juego de MVS al dueño de un salón recreativo le podía costar mucho dinero, pero mucho más que lo que valía el mismo juego en versión AES, ya que el dueño del recreativo iba a sacar un rendimiento económico.

Para entenderlo mejor mediante una analogía: GOLTV.

Para particulares vale 15 euros al mes; para un bar, creo que 150 al mes.

De ahí que SNK quisiera impedir que se pudieran usar los cartuchos AES en los recreativos.

¿Pero como lo podia impedir?
¿Que le impedia al dueño de un recreativo comprar una Maca y meterle en las tripas una AES?
Si sabes algo de electronica no es dificil empalmar una consola a un monitor de recre... y los Pad's tres cuartos de lo mismo...

No es lo mismo hoy que hace 15 años.

Ni la documentación que hay hoy día (internet), ni la AES tiene "modo arcade" sin la bios adecuada... vamos, ni por asomo.