Xenocrisis para Super Nintendo/Famicom

@dr apocalipsis
Ya se puso los kiki kai como otros ejemplos.

Tengo entendido que el port que se hizo para PS Vita tampoco es bueno y tiene problemas de rendimiento. En esa plataforma están descartados los problemas de potencia, creo yo.

Señor Ventura escribió:@riffraff ¿Tu entiendes algo de lo que se dice?. Pregunto en serio.

Si crees que no estás inventándote otra historia, te animo a que implementes una demo en la que se pinte cualquier posición de la serpiente en un mapa con sólo 48 tiles únicos.
Ni siquiera tiene que ser para la SNES, una demo chusquera para PC vale.

Si te sale, igual hasta te contratan en Bitmap Bureau y te sacas una pasta

stormlord escribió:Antiguamente mogollón de juegos se hacían para Spectrum y luego se hacían los ports para Amstrad y MSX. ¿Qué pasaba?, exactamente lo mismo, y no nos quejábamos tanto. Con la edad nos hemos vuelto unos inconformistas de cojones xD.

Las narices no nos quejábamos. Juego porteado de Spectrum a Amstrad con esa falta de colores, lo poníamos a parir...

@riffraff
Pero no es el mismo chip . Aunque desde luego me hacen con eso un Doom Ray Tracing en SNES y les tiro mi dinero !!

No le veo nada del otro jueves a la serpiente del xenocrisis
Minuto 0,30:

Hay otra serpiente que sale en el duelo posterior con el final boss de contra 3/ super probotector todavía más grande y rápida, pero no he encontrado ningún vídeo, seguro que más de uno sabéis.
O mismamente el gusano del r-type 3, que llegan al límite por línea pero son más grandes y con más segmentos.

Si es por falta de "velocidad" o lo que sea para refrescar tiles, pues que hubieran simplificado algo el movimiento. Mejor eso que el parpadeo.

Yo apunto más bien a los problemas clásicos, falta de tiempo y/o conocimientos para optimización, sumado a que es bastante posible que hayan usado un lenguaje de alto nivel, tipo C y no hayan podido rascar más (pasa lo mismo con la versión mega).

sgonzalez escribió:No le veo nada del otro jueves a la serpiente del xenocrisis
Minuto 0,30:

Hay otra serpiente que sale en el duelo posterior con el final boss de contra 3/ super probotector todavía más grande y rápida, pero no he encontrado ningún vídeo, seguro que más de uno sabéis.
O mismamente el gusano del r-type 3, que llegan al límite por línea pero son más grandes y con más segmentos.

Si es por falta de "velocidad" o lo que sea para refrescar tiles, pues que hubieran simplificado algo el movimiento. Mejor eso que el parpadeo.

Yo apunto más bien a los problemas clásicos, falta de tiempo y/o conocimientos para optimización, sumado a que es bastante posible que hayan usado un lenguaje de alto nivel, tipo C y no hayan podido rascar más (pasa lo mismo con la versión mega).

Más de medio boss es un fondo. El gusano sólo tiene un patrón de movimiento y las tiles que lo componen son completamente estáticas.
A pesar de eso, flickea a cholón y más feo que la serpiente del Xenocrisis.

Y volvemos a la excusa de los programadores vagos y el lenguaje utilizado cuando están usando un ARM dopadísimo.

Cualquier cosa menos acepta las limitaciones de SNES.

dr apocalipsis escribió:Cualquier cosa menos acepta las limitaciones de SNES.

Una vez más, a la serpiente del Xeno Crisis le faltan secciones cuando no debería haber problemas en mostrarlas todas.
Eso no es culpa de las limitaciones de la SNES:

@dr apocalipsis porque hay que aceptar una chapuza? que cada consola tiene sus limyaciones todos estamos de acuerdo ,no se salva ninguna .

se me olvido pocky and rocky 2 que lo han mencionado antes y el mismo contra que han puesto,juegos de la etapa comercial de la consola sin añadidos tan tochos como una raspberry y poniedo bastante mas chicha en pantalla ,el pocky and rocky 2 es una pasada ,con algun plano de scroll aparte ,escenarios animados y los sprites no es que se muevan mal ni mucho menos ,lo contrario .

riffraff escribió:

dr apocalipsis escribió:Cualquier cosa menos acepta las limitaciones de SNES.

Una vez más, a la serpiente del Xeno Crisis le faltan secciones cuando no debería haber problemas en mostrarlas todas.
Eso no es culpa de las limitaciones de la SNES:

Ya que no tenemos acceso a un debugger ni a un emulador que nos deje ver las tripas, sólo podemos ponernos a contar metasprites a ojo, tener en cuenta que la SNES sólo soporta sprites cuadrados, fijarse en que la inmensa mayoría de metasprites no son cuadrados y ya empezar a darse cuenta de porque entonces se está superando el límite de sprites de SNES.

Tenías 2 opciones:

A) Lo que se ha hecho, respetar el artwork original, basado en la fexibilidad de Megadrive para poder hacer sprites rectangulares y de todos los tamaños a la vez, y tener flickering porque no puedes poner tantos en SNES como en Megadrive.

B) Redibujar y reducir el artwork de la serpiente para adaptarlo a sprites cuadrados y sólo 2 tamaños de sprites.

Ninguna opción hubiese sido aceptable para vosotros. Porque jamás admitiréis que la SNES no pueda hacer una conversión 1:1 de algo de la Megadrive.

A partir de ahí ya cada cual culpe al lenguaje, a los programadores o se invente configuraciones con prioridades, fondos o sistemas de culling que ningún hardware de la época puede hacer.

La verdad es que es flipante.

@dr apocalipsis quien piede algo 1:1 de megadrive?
lo bonito seria adaptarlo a las particularidades de la consola ,en algunas cosas mejor en otras peor .
adaparalo a la resolucion de snes ,añadir mas colores y efectos que la consola tiene .
la snes tiene un complejo sistema llamado hdma que podria dar resultados muy buenos y diferentes ,eso seria bonito y por supuesto tendrian que currar .
nadie quiere que sea como la de megadrive ,para eso ya esta la version megadrive

dr apocalipsis escribió:sólo podemos ponernos a contar metasprites a ojo, tener en cuenta que la SNES sólo soporta sprites cuadrados, fijarse en que la inmensa mayoría de metasprites no son cuadrados y ya empezar a darse cuenta de porque entonces se está superando el límite de sprites de SNES.

Ni de coña se está superando el límite de sprites en esta zona, por ejemplo:


Si casi no hay sprites

titorino escribió:@dr apocalipsis quien piede algo 1:1 de megadrive?
lo bonito seria adaptarlo a las particularidades de la consola ,en algunas cosas mejor en otras peor .
adaparalo a la resolucion de snes ,añadir mas colores y efectos que la consola tiene .
la snes tiene un complejo sistema llamado hdma que podria dar resultados muy buenos y diferentes ,eso seria bonito y por supuesto tendrian que currar .
nadie quiere que sea como la de megadrive ,para eso ya esta la version megadrive

Y todo eso se ha hecho.

Hay más colores en pantalla.
Hay efectos de color (los mal llamados efectos de transparencia).
Se ha adaptado el campo de juego a la resolución del modo en que se podía hacer, ya que está basado en generación aleatoria y se tiene que hacer en cuadrados, no había otra opción que quitar 2 columnas enteras.
Se han añadido más voces.

Lo único que se podía haber hecho y no se ha hecho ha sido reducir el tamaño de los sprites. Y hubiese traído críticas igual.

Estáis siendo obcecadamente injustos con el port al que más mimo se ha puesto de lejos.

@riffraff y dale con la burra al trigo.

Esos sprites no se están descartando por límite por scanline. Estoy harto de explicarlo.

dr apocalipsis escribió:Esos sprites no se están descartando por límite por scanline. Estoy harto de explicarlo.

No, no lo has hecho. ¿Puedes explicar por qué se están descartando, que no sea mala programación o "un despiste"?
Porque vamos, dudo mucho que se estén sobrepasando los 128 sprites en ese pantallazo.

riffraff escribió:

dr apocalipsis escribió:Esos sprites no se están descartando por límite por scanline. Estoy harto de explicarlo.

No, no lo has hecho. ¿Puedes explicar por qué se están descartando, que no sea mala programación o "un despiste"?
Porque vamos, dudo mucho que se estén sobrepasando los 128 sprites en ese pantallazo.

Pues mira, muy fácilmente, por el límite de 16KB que tiene SNES para sprites, que en Megadrive son 64KB.

Seguramente la serpiente entre en VRAM entera en Megadrive y en SNES no.
A partir de ahí, para poder mantener el rendimiento a 60fps puede estar descartando sprites para los que no tenga tiempo a cargar todos los tiles en vez de mostrarlos glitcheados.

Aunque el segundo jugador no esté en imagen, debe tener sus tiles reservadas en todo momento.

Megadrive puede almacenar muchísimas más tiles únicas para sprites que SNES.

O puede que estén usando muchos más sprites de los que tú te piensas, por lo que he comentado de que tienen una disposición muy ineficiente para los tamaños disponibles en SNES.

¿Que tú prefieres decir que están metiendo flickering en un menú traducido a posta? Pues tú mismo.
Anda que no hay ejemplos de la época de menús traducidos descuadrados o con caracteres faltantes porque no había las facilidades que hay hoy en día, y menos en estas consolas, para gestionar texto.

dr apocalipsis escribió:

riffraff escribió:

dr apocalipsis escribió:Esos sprites no se están descartando por límite por scanline. Estoy harto de explicarlo.

No, no lo has hecho. ¿Puedes explicar por qué se están descartando, que no sea mala programación o "un despiste"?
Porque vamos, dudo mucho que se estén sobrepasando los 128 sprites en ese pantallazo.

Pues mira, muy fácilmente, por el límite de 16KB que tiene SNES para sprites, que en Megadrive son 64KB.

Seguramente la serpiente entre en VRAM entera en Megadrive y en SNES no.
A partir de ahí, para poder mantener el rendimiento a 60fps puede estar descartando sprites para los que no tenga tiempo a cargar todos los tiles en vez de mostrarlos glitcheados.

Aunque el segundo jugador no esté en imagen, debe tener sus tiles reservadas en todo momento.

Megadrive puede almacenar muchísimas más tiles únicas para sprites que SNES.

O puede que estén usando muchos más sprites de los que tú te piensas, por lo que he comentado de que tienen una disposición muy ineficiente para los tamaños disponibles en SNES.

• Las secciones del medio de la serpiente caben en un sprite de 32x32 (16 tiles).
  Como tienen 3 posiciones diferentes (el resto son espejos), las secciones ocupan 16x3=48 tiles.
• Lo mismo pasa con la cola de la serpiente. Como sólo hay una, 16 tiles.
• Vamos a suponer que la cabeza de la serpiente está muy mal hecha y hay que usar un sprite de 64x64 (64 tiles).
• Los protas caben en un sprite de 32x32 (16x2=32 tiles).

En total, 160 tiles, o 5KB.

La SNES permite copiar casi 6KB a VRAM en un V-Blank. Como los fondos del Xeno Crisis son estáticos, tienes todo el V-Blank para actualizar sprites, así que el tamaño de la VRAM no es ningún problema: da tiempo a copiar de ROM a VRAM casi todo lo que se muestra en pantalla en un V-Blank.
Con toda la VRAM que sobra puedes almacenar los tiles de las balas, de las explosiones y seguramente de gran parte de la serpiente.

En definitiva, que la VRAM para sprites no debería ser un problema.

dr apocalipsis escribió:¿Que tú prefieres decir que están metiendo flickering en un menú traducido a posta? Pues tú mismo.

Yo no dije eso, dije que seguramente lo hayan dejado pasar porque no les sea rentable arreglarlo.

dr apocalipsis escribió:Anda que no hay ejemplos de la época de menús traducidos descuadrados o con caracteres faltantes porque no había las facilidades que hay hoy en día, y menos en estas consolas, para gestionar texto.

¿Tienes ejemplos de juegos de la época de la SNES con menús con flickering?

riffraff escribió:

• Las secciones del medio de la serpiente caben en un sprite de 32x32 (16 tiles).
  Como tienen 3 posiciones diferentes (el resto son espejos), las secciones ocupan 16x3=48 tiles.
• Lo mismo pasa con la cola de la serpiente. Como sólo hay una, 16 tiles.
• Vamos a suponer que la cabeza de la serpiente está muy mal hecha y hay que usar un sprite de 64x64 (64 tiles).
• Los protas caben en un sprite de 32x32 (16x2=32 tiles).

En total, 160 tiles, o 5KB.

La SNES permite copiar casi 6KB a VRAM en un V-Blank. Como los fondos del Xeno Crisis son estáticos, tienes todo el V-Blank para actualizar sprites, así que el tamaño de la VRAM no es ningún problema: da tiempo a copiar de ROM a VRAM casi todo lo que se muestra en pantalla en un V-Blank.
Con toda la VRAM que sobra puedes almacenar los tiles de las balas, de las explosiones y seguramente de gran parte de la serpiente.

En definitiva, que la VRAM para sprites no debería ser un problema.

Entonces estarías usando sprites de 32x32 para las balas.

Te acabas de quedar sin VRAM antes de pegar un solo tiro.

riffraff escribió:¿Tienes ejemplos de juegos de la época de la SNES con menús con flickering?

No, me lo acabo de inventar.
Nunca jamás de los jamases han existido problemas de descuadres y desajustes en las traducciones al español en consolas de 16 bits y posteriores.

Devuelve el juego.

dr apocalipsis escribió:Entonces estarías usando sprites de 32x32 para las balas.

Te acabas de quedar sin VRAM antes de pegar un solo tiro.

Como acabo de decir, te sobran más de 10KB de VRAM para cachear los tiles de las balas, de las explosiones y seguramente de gran parte de la serpiente.

Y la mayoría de las balas deberían caber en un sprite de 16x16, no de 32x32.

dr apocalipsis escribió:

riffraff escribió:¿Tienes ejemplos de juegos de la época de la SNES con menús con flickering?

No, me lo acabo de inventar.
Nunca jamás de los jamases han existido problemas de descuadres y desajustes en las traducciones al español en consolas de 16 bits y posteriores.

Devuelve el juego.

Te he preguntado por ejemplos de menús con flickering, no por ejemplos de descuadres ni desajustes.

dr apocalipsis escribió:Estáis siendo obcecadamente injustos con el port al que más mimo se ha puesto de lejos.

Así es, yo creo que ni en los '90 se hacían ports con tanta fidelidad como con éste juego, y siendo además un juego que exige, incluyendo detalles exclusivos de Snes.

Hay un obcecamiento también con lo de aprovechar todo lo que la máquina se pueda permitir, sólo porque sí y sin ninguna razón aparente, metiendo no sé cuantos planos aunque no tengan lugar, mil colores en todas partes, modo 7, efectos HDMA... de paso podría ser también un beat'm up, tener un poquito de plataformeo, toques rpg, lucha 1 vs 1, y así ya todos contentos. En MD también podría haber mostrado un plano más, por ejemplo, y no se hace porque no es la idea, me parece un absurdo la búsqueda porque sí de todas esas cosas, no puedo evitar pensar que no son más que los complejos de la gente.

riffraff escribió:

dr apocalipsis escribió:Entonces estarías usando sprites de 32x32 para las balas.

Te acabas de quedar sin VRAM antes de pegar un solo tiro.

Como acabo de decir, te sobran más de 10KB de VRAM para cachear los tiles de las balas, de las explosiones y seguramente de gran parte de la serpiente.

Y la mayoría de las balas deberían caber en un sprite de 16x16, no de 32x32.

No, has hecho tus cuentas con 2 tamaños: 32x32 y 64x64.

El menor de ellos se iría para las balas, aunque ya puestos a soltar burradas, lo mismo usamos hasta el de 64x64 porque la SNES no tiene límites. Por mucho que estuviese en su mayoría vacío visualmente, esa miríada de cuadros de 8x8 que los componen los consumes igual tanto en VRAM, como en sprites como en tiempo de proceso.

Con 4 o 5 macrosprites de ese tamaño también te acabas de violar el límite de pixels de sprite por línea.

Por ilustrar lo que acabas de proponer:


Acabas de dejar seca a la SNES sin pegar un sólo tiro.

dr apocalipsis escribió:

riffraff escribió:

dr apocalipsis escribió:Entonces estarías usando sprites de 32x32 para las balas.

Te acabas de quedar sin VRAM antes de pegar un solo tiro.

Como acabo de decir, te sobran más de 10KB de VRAM para cachear los tiles de las balas, de las explosiones y seguramente de gran parte de la serpiente.

Y la mayoría de las balas deberían caber en un sprite de 16x16, no de 32x32.

No, has hecho tus cuentas con 2 tamaños: 32x32 y 64x64.

El menor de ellos se iría para las balas, aunque ya puestos a soltar burradas, lo mismo usamos hasta el de 64x64 porque la SNES no tiene límites. Por mucho que estuviese en su mayoría vacío visualmente, esa miríada de cuadros de 8x8 que los componen los consumes igual tanto en VRAM, como en sprites como en tiempo de proceso.

Con 4 o 5 macrosprites de ese tamaño también te acabas de violar el límite de pixels de sprite por línea.

Por ilustrar lo que acabas de proponer:


Acabas de dejar seca a la SNES sin pegar un sólo tiro.

Cuando hablaba de un sprite de 64x64, me refería a 4 sprites de 32x32 (sería estúpido usar sprites de 64x64).
No sé por qué te agarras a un clavo ardiendo para intentar llevar razón

Por lo que he oído, el juego utiliza sprites de 16x16 y de 32x32.
Muchas balas caben en sprites de 8x8, pero aún así he preferido hacer las cuentas con lo que he oído.

Y sigo esperando los ejemplos de menús con flickering

Minuto 1:03:20


Gusanos/serpientes disparos, colores y transparencias por doquier sin la más mínima ralentización.
Si se supera el límite de sprites por línea (mostrando el triple o más) pero el efecto es mucho más liviano que lo visto en xenocrisis.

Me remito a mi mensaje de antes.
Falta de tiempo y/o conocimientos para optimizar sumando a que igual que en Megadrive, habrán usado un lenguaje de alto nivel tipo C que impide el aprovechamiento 100% de los recursos de la máquina.

@riffraff
No hay ningún juego en super famicom con flickering en un menú de ese tipo, en ninguna traducción al español, tampoco, te lo dice uno que a jugado/testeado la gran mayoría de catálogo del sistema; referente a descuadre de texto, si claro, incluso en juegos oficiales traducidos, pero nada de flickering, incluso cuando hay texto encima de gráfico moviendose en un plano de "fondo".

@Sgonzalez
Encima el super aleste, es slow rom...

La serpiente flickea,tanto en snes como en megadrive,de distinta manera(como he puesto en las fotos).Tampoco me parece tan grave,para un.juego amateur y en su primera incursión en snes.
Lo que no entiendo,es lo.del menú.
Utilizar un arm?.Supongo que cuestión de economía y amortización de tiempo.

En cuanto a la versión más tocha,de las que he probado,las de neogeo,me parecen las mejores(incluso que la de n64).Pero su control,al igual que en md,para mi,algo insalvable.

-Se pueden usar sprites de 8x8 para las balas, y 32x32 para los enemigos (esto durante las pantallas contra los jefes). El resto de pantallas donde los enemigos son mas pequeños puedes usar una configuración de 8x8 para las balas, y 16x16 para los enemigos.

-No tienes que transferir todo lo que hay en pantalla, pueden reutilizarse sprites, flipearlos horizontal y/o vericalmente

riffraff escribió:Si crees que no estás inventándote otra historia, te animo a que implementes una demo en la que se pinte cualquier posición de la serpiente en un mapa con sólo 48 tiles únicos.
Ni siquiera tiene que ser para la SNES, una demo chusquera para PC vale.

Si te sale, igual hasta te contratan en Bitmap Bureau y te sacas una pasta

Pues hombre, diciéndome que me invento historias cuando hablo de 48 tiles de sprites, y entiendes que estoy hablando de animar la serpiente actualizando 48 tiles del plano, es para plantearse si sabes lo que estás diciendo como para corregir a nadie.

La serpiente tiene tres tipos de cuerpos diferentes. La cabeza y la cola se transfieren, y de los 5 fragmentos restantes, se copian en memoria los que coincidan, cuando lo hagan (también cuando requieran flipearlos vertical u horizontalmente).

Pero hablamos de 3 fragmentos de su cuerpo con varias posiciones cada uno, y de ellas no todas son almacenadas, sino que son las versiones "flipeadas" de un sprite "base". Igual todas las animaciones de la serpiente se logran con 3 o 4 KB de sprites instalados en vram de un límite de 16KB. Sobra mucho espacio, y dejas libre el tiempo de DMA para otras cosas (o para transferir otros gráficos, o para usar la cpu, aunque aquí ni exista porque para eso está la raspberry).

Para entender este concepto es recomendable ver el proceso de programación del "micro mages" de NES, que lo explican muy bien:
https://www.youtube.com/watch?v=ZWQ0591PAxM&t=24s

Señor Ventura escribió:Pues hombre, diciéndome que me invento historias cuando hablo de 48 tiles de sprites, y entiendes que estoy hablando de animar la serpiente actualizando 48 tiles del plano, es para plantearse si sabes lo que estás diciendo como para corregir a nadie.

Como venías de inventarte la historia de usar un fondo diferente para cada sección de la serpiente para no sobrepasar el límite de sprites por scanline, supuse que estabas inventando otra historia con el mismo fin. Si no es así, lo siento, mea culpa.

Como ya expliqué en otro post, no debería haber problema en copiar a VRAM en el V-Blank las secciones del medio de la serpiente que se ven en pantalla, porque se deberían poder copiar casi todos los tiles de sprites que se ven en pantalla. Pero eso no va a evitar que se sobrepase el límite de sprites por scanline más a menudo que en Mega Drive.

De nuevo vuelves a hacer lo mismo. Hablas de inventarme usar un plano por cada fragmento de la serpiente, cuando no has entendido lo que he dicho.

No es necesario transferir nada, con mas o menos 3KB de tiles para sprites totalmente instalados en vram, y flipeandolos donde se necesite, puedes hacer todas las animaciones para su movimiento sin problemas.

Por otro lado, es el port con la serpiente mas grande, mas que la original, está desproporcionada. Manteniendo la misma relación de aspecto que el resto de versiones ese boss no debe presentar parpadeos NUNCA.

En el caso actual con el tamaño actual, los parpadeos se pueden reducir mucho también, incluso puede existir la forma de eliminar cualquier parpadeo involucrando UN PLANO en el dibujo de la serpiente, no para uno de los fragmentos de su cuerpo, sino para VARIOS.

Esto seguiría el principio de superponer dos o mas secciones de un mismo plano en la misma horizontal mediante el hdma, aunque esto requiere de una cantidad notable de cpu adicional, pero la posibilidad es real.

Señor Ventura escribió:De nuevo vuelves a hacer lo mismo. Hablas de inventarme usar un plano por cada fragmento de la serpiente, cuando no has entendido lo que he dicho.

Y repites el invento:

Señor Ventura escribió:Esto seguiría el principio de superponer dos o mas secciones de un mismo plano en la misma horizontal mediante el hdma, aunque esto requiere de una cantidad notable de cpu adicional, pero la posibilidad es real.

HDMA no permite superponer dos o más secciones de un mismo plano en la misma horizontal. Ése es el invento. Para nada "la posibilidad es real".

La serpiente no es más grande en Snes.
La pantalla es más pequeña en Snes.

Han pasado 30 años y seguimos con el bulo de que los sprites son más grandes en Snes.

Y casi estamos volviendo otra vez a la trifulca de cuando se anuncio el juego ...
Cada máquina es diferente y tiene sus pros y sus contras ( afortunadamente , no como hoy en dia )así que no tiene porqué comportarse igual un juego . Además han tenido la deferencia de meter algún extra como transparencias y efectos que no están en otros sistemas con lo que es un port bajo mi punto de vista bastante currado.
Que hayan usado un súper dopaje ? Pues puede , pero a día de hoy es muchísimo más barato y sencillo meter un chip de esos que hacer un SA1 o parecido.
Además ya dijeron que con ese chip querían evitar la piratería a si que es bastante entendible que ese chip se use incluso para el sonido .
Que es cierto que es un juego que para las características técnicas de SNES no se adecúe muy bien . Si pero hay que mirar que ha salido y si hay suerte se harán más juegos o incluso juegos exclusivos para SNES .

El tema del sonido me llamó bastante la atención dada la calidad del SPC, bicheando comprobé que varios usuarios daron por sentado que SNES no podría cargar con la música del juego, es algo que debido a mi ignorancia me ha chocado bastante, por el hecho en sí y porque finalmente el trabajo de Bitmap Bureau parece haberles dado la razón sobre el papel.

https://gamefaqs-gamespot-com.translate ... _tr_pto=sc

Mcnichoj
¿Van a portar este juego a todas las consolas imaginables?

Mcnichoj, Espero que no. Definitivamente no quiero un port de Super Nintendo. El chip de sonido SPC-700 no puede reproducir esa banda sonora. Un puerto PS1 sería más ideal considerando la disposición de los botones del controlador.

En NesDev comentaron lo mismo que vosotros estáis debatiendo.

Por lo que ha dicho el desarrollador, el coprocesador está ahí principalmente para hacer que sea mucho más difícil piratear el juego como razón principal, lo que aparentemente fue un gran problema con las versiones Genesis y Neo Geo. También dijeron que habrían podido hacer que el juego se ejecutara en SNES estándar, pero habría llevado más tiempo, así que supongo que esto les ahorró un poco de tiempo y molestias en última instancia. Y alguien más mencionó que también se está usando para material tipo MSU-1 y como mapeador para permitir un tamaño de cartucho más grande, lo cual probablemente sea esencial debido a que aparentemente incluye básicamente todas las muestras de audio de Neo Geo que no estaban presentes en el Génesis. original. No tengo ningún problema con ambas cosas y, de hecho, aprecio su decisión dado lo que está permitido aquí.

La SNES fue diseñada con este tipo de mejora de cartucho en mente desde el primer día y específicamente para que fuera un proceso relativamente fácil, ciertamente en comparación con la mayoría de los otros sistemas de la época que en realidad no fueron diseñados con esta mejora directa de cartucho en mente y, por lo tanto, no lo aproveché mucho en absoluto, y este es solo uno de los muchos ejemplos de un desarrollador que lo usa según lo previsto por lo que puedo decir, lo cual está bien para mí.

Estoy feliz de ver un juego de SNES comercial nuevo, completamente completo y de alta calidad en 2023. Y estaré feliz de ver muchos más si eso sucede alguna vez, y espero que así sea, tantos como sea posible. de hecho.

Y, aunque es prácticamente el mismo juego que el original, pero con una vista un poco más pequeña y muchas más muestras de voz, una buena ventaja de la versión de SNES sobre muchas de las otras versiones y ciertamente en cualquier sistema de la era de los 90 o anterior. , es que los controles se pueden mapear correctamente y se sienten muy bien en ese controlador SNES predeterminado, para el cual un juego como este es ideal. Pero estoy de acuerdo en que definitivamente podrían y, en mi opinión, deberían haber hecho más para aprovechar las capacidades únicas de SNES aquí, especialmente en cosas como agregar muchos más colores y tal vez un poco de transparencia adecuada aquí y allá. Aunque, como hemos visto con los otros puertos, eso nunca sucedería de todos modos, así que no puedo preocuparme demasiado por que no suceda aquí tampoco.

I-rem escribió:El tema del sonido me llamó bastante la atención dada la calidad del SPC, bicheando comprobé que varios usuarios daron por sentado que SNES no podría cargar con la música del juego, es algo que debido a mi ignorancia me ha chocado bastante, por el hecho en sí y porque finalmente el trabajo de Bitmap Bureau parece haberles dado la razón sobre el papel.

El chip de sonido de la SNES es casi completamente autónomo. Tiene una RAM muy limitada de 64kb, que almacena su programa y los samples, y apenas puedes hacer nada con él una vez iniciado. De hecho, los famosos tiempos de carga entre niveles de SNES suelen venir por ahí. Hacer streaming como hace la Megadrive no está sobre la mesa y pasar una BSO tan diseñada sobre la síntesis como es la de Xenocrisis a los microsamples de SNES no hubiese dado muy buenos resultados tampoco.

Es normal que hayan optado por esta solución teniendo el chip externo y dejar el SPC para los efectos y las voces.

@dr apocalipsis a lo mejor estoy equivocado pero hay por ahi algunos archivos de sonido para snes que imitan el sonido fm con bastante acierto
con samples.
los que he escuchado de sonic o street of rage diria que cuesta diferenciarlos

Dr Apocalipsis escribió:

I-rem escribió:El tema del sonido me llamó bastante la atención dada la calidad del SPC, bicheando comprobé que varios usuarios daron por sentado que SNES no podría cargar con la música del juego, es algo que debido a mi ignorancia me ha chocado bastante, por el hecho en sí y porque finalmente el trabajo de Bitmap Bureau parece haberles dado la razón sobre el papel.

El chip de sonido de la SNES es casi completamente autónomo. Tiene una RAM muy limitada de 64kb, que almacena su programa y los samples, y apenas puedes hacer nada con él una vez iniciado. De hecho, los famosos tiempos de carga entre niveles de SNES suelen venir por ahí. Hacer streaming como hace la Megadrive no está sobre la mesa y pasar una BSO tan diseñada sobre la síntesis como es la de Xenocrisis a los microsamples de SNES no hubiese dado muy buenos resultados tampoco.

Es normal que hayan optado por esta solución teniendo el chip externo y dejar el SPC para los efectos y las voces.

Te agradezco la explicación, entre que no conozco el tema y que se me olvida lo poco que sé, la casa sin barrer vislumbré que podría venir por ese lado, que MegaDrive genera la música en tiempo real con un muy bajo coste en tiempo de proceso y tamaño de memoria, mientras SNES funciona necesitando almacenar los samples de sonido que van a 'reproducirse'.

Es muy curioso que en el 95% de títulos de lucha Vs de SNES, la voz digitalizada del ganador hace que la acción se congele por un instante, hasta donde conozco sólo en Turtles Tournament Fighters y los MK esto no ocurre.



y por lo general a mayor compresión tiene el sonido mas prolongado es el parón, entiendo que debe guardar una relación más o menos directa con lo que me has explicado.

Titorino escribió:@Dr Apocalipsis a lo mejor estoy equivocado pero hay por ahí algunos archivos de sonido para snes que imitan el sonido fm con bastante acierto
con samples.
los que he escuchado de sonic o street of rage diria que cuesta diferenciarlos

creo que lo que hicieron es 'samplear' el sonido o bancos de sonido para que se reproduzcan las muestras, pero el Chip en ningún momento es capaz de generar sonidos de esa forma, en FM o PSG, es un poco imagino como con las renderizaciones, donde todo se crea y procesa en un sistema externo mucho más potente para darle a la consola todo el trabajo ya hecho.

Hace unos días vi este tutorial sobre cómo hacer música en SNES.

@I-rem si se que el chip no es capaz de generar fm ,es a base de muestras ,pero el resultado es bastante bueno ,en algunos casos inapreciable .
el sonido la manera mas rapida es por donde han tirado ,la compleja seria samplear la bso y que el spc700 lo reprodujera ,pero el dinero y el tiempo es oro .
no es mala decision si quieres sacarle tajada ,se ve que han palmado pasta con las versiones pirataedas y de esta manera es casi imposible tener el de snes pirata
otra cosa interesante es el msu1 pero no se si seria posible meterlo fisicamente en un cartucho

Titorino escribió:@I-rem si se que el chip no es capaz de generar fm ,es a base de muestras ,pero el resultado es bastante bueno ,en algunos casos inapreciable .
el sonido la manera mas rapida es por donde han tirado ,la compleja seria samplear la bso y que el spc700 lo reprodujera ,pero el dinero y el tiempo es oro .
no es mala decision si quieres sacarle tajada ,se ve que han palmado pasta con las versiones pirataedas y de esta manera es casi imposible tener el de snes pirata
otra cosa interesante es el msu1 pero no se si seria posible meterlo fisicamente en un cartucho

Ya, era una obviedad parece claro lo que bien habéis estado debatiendo; han suplido con tecnología externa el tiempo que se hubiera necesitado para que la consola pudiese ejecutar ciertos aspectos del juego por ella misma, supongo que picar el código necesario era completamente inviable -e ilógico hasta cierto punto- por eso mismo que explicas, el tiempo es oro.. es como si tienes que desplazarte a 25 Km de tu casa careciendo de vehículo propio, puedes ir andando si la vía del trayecto lo permite, pero si coges un autobús ahorraras un tiempo y una energía extraordinarios. Dentro de esta analogía, Bitmap Bureau han optado por coger un taxi, lo más caro e 'invalidante' para la consola/persona, pero lo más rápido y eficaz en todos los sentidos y demás aspectos.

Como muy bien has dicho, a nivel de estratégia es inteligente, porque si bien de forma inicial tienen que afrontar un gasto extra considerable, de cara a un futuro es una inversión segura que entiendo, generará réditos.

Hombre si es una Pico son 4$ por chip y eso venta a particular, que a ellos les costará bastante menos fácilmente . Tampoco es un desembolso grande y además actúa de sistema anti piratería con lo que ese pequeño sobre coste está más que amortizado .

Hookun escribió:Hombre si es una Pico son 4$ por chip y eso venta a particular, que a ellos les costará bastante menos fácilmente . Tampoco es un desembolso grande y además actúa de sistema anti piratería con lo que ese pequeño sobre coste está más que amortizado .

Analizado fríamente parece ser la estrategia más redonda, en la que sobra el 'romanticismo' de querer sacarle el mayor partido a la consola para que pueda demostrar todo lo que tiene dentro en pleno 2024, deseable por la mayoría de nosotros y lo que ha generado este debate.

y sí, el sonido 'Yamaha' (Sintesis FM) suena de maravilla en SNES se me pasó decirlo y no me quedaba tranquilo sin expresarlo.

I-rem escribió:Analizado fríamente parece ser la estrategia más redonda, en la que sobra el 'romanticismo' de querer sacarle el mayor partido a la consola para que pueda demostrar todo lo que tiene dentro en pleno 2024, deseable por la mayoría de nosotros y lo que ha generado este debate.

Una cosa es demostrar todo lo que puede hacer la SNES (con un coprocesador 20 años más moderno) y otra es que no se corrijan fallos gráficos evitables.

RiffRaff escribió:

I-rem escribió:Analizado fríamente parece ser la estrategia más redonda, en la que sobra el 'romanticismo' de querer sacarle el mayor partido a la consola para que pueda demostrar todo lo que tiene dentro en pleno 2024, deseable por la mayoría de nosotros y lo que ha generado este debate.

Una cosa es demostrar todo lo que puede hacer la SNES (con un coprocesador 20 años más moderno) y otra es que no se corrijan fallos gráficos evitables.

Si, no me quise mojar, pero revisitando pesos pesados de la consola (la mayor parte de ellos superando los 28 años de antigüedad), con franqueza, hay aspectos de Xeno Crisis que no acaban de comprenderse, al menos desde mi ignorancia, parecen chocantes.

No sé porqué me vino este juego 'trasnochado' en cuanto a catálogo a la memoria, tal vez porque sin ser ninguna maravilla tenía momentos que aún estando ya en 1996 me parecieron bastante meritorios, En las explosiones del primer corte del video creo se ve flickering en forma de cuadrados, pero está justificado por todo lo que se está moviendo..

@I-rem
Pues hasta donde conoces, conoces poco, ya que por ponerte un ejemplo claro, el street fighter 2 world warrior, no sufre ningún paron, al igual que Clayfighters, etc , eso depende del tipo de compresión.

@Titorino
Muy posible que utilicen el msu , y una compresion del wav media, lo cual no creo que ocuparan mas de 150 megas.

Les e reportado el fallo del inicio de la música del Boss 2, y lo están revisando...a ver qué me dicen.

I-rem escribió:y sí, el sonido 'Yamaha' (Sintesis FM) suena de maravilla en SNES se me pasó decirlo y no me quedaba tranquilo sin expresarlo.

Esas pistas están hechas con trackers que imitan el sonido de las consolas viejas partiendo de SoundFonts que generan pasando canciones a midi para 'robar' luego los instrumentos.

La inmensa mayoría, salvo cuando lo indican, no van en hardware real.

Edit:

@VempireX El que se ve que conoce poco, eres tú. Él lo ha dicho bien.

Y no depende de ningún tipo de compresión, porque la compresión de los samples soportada por el SPC700 siempre es la misma. El SFA2 es otro ejemplo de parones para cargar samples del anunciador antes y después del combate. Si en otro juego te caben en memoria las voces de los peleadores y el anunciador (más la música y los efectos, claro), pues no habrá parón, evidentemente. Pero en el caso de los ports casi nunca era el caso.

O había parón o se omitía directamente.

dr apocalipsis escribió:

I-rem escribió:y sí, el sonido 'Yamaha' (Sintesis FM) suena de maravilla en SNES se me pasó decirlo y no me quedaba tranquilo sin expresarlo.

Esas pistas están hechas con trackers que imitan el sonido de las consolas viejas partiendo de SoundFonts que generan pasando canciones a midi para 'robar' luego los instrumentos.

La inmensa mayoría, salvo cuando lo indican, no van en hardware real.

Edit:

@VempireX El que se ve que conoce poco, eres tú. Él lo ha dicho bien.

Y no depende de ningún tipo de compresión, porque la compresión de los samples soportada por el SPC700 siempre es la misma. El SFA2 es otro ejemplo de parones para cargar samples del anunciador antes y después del combate. Si en otro juego te caben en memoria las voces de los peleadores y el anunciador (más la música y los efectos, claro), pues no habrá parón, evidentemente. Pero en el caso de los ports casi nunca era el caso.

O había parón o se omitía directamente.

🤣🤣🤣🤣🤣🤣
Que sabré yo , que precisamente al catálogo que más e jugado es el de super famicom, 🤣🤣🤣🤣🤣🤣
Hablo de conocer el catalogo, en la cantidad más concretamente, no qué no suceda dicha descompresión y parón, que sigo diciendo que no es en el 95%, como ha dicho él, has intentando dejarme como un ignorante, comparando la velocidad con el tocino, comprensión lectora, nula.

VempireX escribió:

dr apocalipsis escribió:🤣🤣🤣

🤣🤣🤣
Que sabré yo , que precisamente al catálogo que más e jugado es el de super famicom, 🤣🤣🤣

Eso es un hack corriendo en emuladores, fiera.

VempireX escribió:@I-rem
Pues hasta donde conoces, conoces poco, ya que por ponerte un ejemplo claro, el street fighter 2 world warrior, no sufre ningún paron, al igual que Clayfighters, etc , eso depende del tipo de compresión.

@Titorino
Muy posible que utilicen el msu , y una compresion del wav media, lo cual no creo que ocuparan mas de 150 megas.

Les e reportado el fallo del inicio de la música del Boss 2, y lo están revisando...a ver qué me dicen.

Calma Compañero, soy consciente, sé que conozco poco, intenté explicarlo al entrar a comentar en el hilo, con todo quise referirme a Street Fighter II Turbo, donde hay voces de victoria, Street fighter 2 World Warrior no las tiene. y sí, llevas razón, no ocurre en el 95% de los juegos, pasa en torno al 45% a lo sumo, quien tiene boca se equivoca y quien tiene dedos ni te cuento (en el buen sentido).

Si te fijas, tanto en la victoria como en el 'Perfect' del bonus del coche, se produce una microparada, esa misma parada está presente en otros varios juegos de lucha Vs de Snes como por ejemplo Fighters History, es lo que traté de comentar, no para tirar contra la SNES, que es junto con MS mi consola preferida, sino en referencia a lo que nos explicó Dr.Apocalipsis antes sobre el funcionamiento del Chip y en referencia a que no me parece lógico que ocurra en esos juegos concretos cuando en otros no pasa. Dentro de mi pequeño mundo, tal vez la complejidad que entraña programar en SNES de forma optimizada sea el motivo, y regreso a los retratos monocromo del HUD de muchos juegos y otros detalles que pienso, demostraban cierto pasotismo -en parte justificado por los apresurados tiempos de producción y entrega- que podrían haber tenido algunas compañías como Capcom.

Tú te has centrado en los que no tienen parada, y te lo agradezco, ahora pongo los que si la tienen, y creo que no me dejo casi ninguno.

Se paran las nubes


Se detienen las chispas/aceite del motor


Se detienen las personas del escenario


Se para toda la escena


Se produce una parada tras el .K.O de uno de los luchadores, como si tuviera que 'cargar' las voces.

Dr Apocalipsis escribió:
Esas pistas están hechas con trackers que imitan el sonido de las consolas viejas partiendo de SoundFonts que generan pasando canciones a midi para 'robar' luego los instrumentos.

La inmensa mayoría, salvo cuando lo indican, no van en hardware real.

Edit:

@VempireX El que se ve que conoce poco, eres tú. Él lo ha dicho bien.

Y no depende de ningún tipo de compresión, porque la compresión de los samples soportada por el SPC700 siempre es la misma. El SFA2 es otro ejemplo de parones para cargar samples del anunciador antes y después del combate. Si en otro juego te caben en memoria las voces de los peleadores y el anunciador (más la música y los efectos, claro), pues no habrá parón, evidentemente. Pero en el caso de los ports casi nunca era el caso.

O había parón o se omitía directamente.

Muchas gracias por arrojar luz sobre este tema el motivo me queda mucho más claro, y entiendo que en los casos en los que aun con anunciador no hay parón, como por ejemplo World Heroes 2 o Fatal Fury 2, se gestionaba de otra manera, por ejemplo en Power Instinc y Samurai Shodown se 'alternan' paradas aprovechando el recurso estilístico-visual del K.O, o eso he interpretado.

@Dr apocalipsis

🤣🤣🤣🤣🤣🤣
Mejor así?
No hay nada como picarle al código para optimizar...😼 , te dejo el gatito a modo de fiera,

@I-rem
Totalmente, y no, ahora te quedas corto, , seguramente esté por allá en el 70% , más o menos , en cuestión de VS, y no solo en VS, en muchos estilos más del catálogo, es una evidencia , en varios casos, muy visual; solo quería especificar, no era nada de tocar las "canicas" ni nada por el estilo, solo informar un poco más, y compartir 😉
Postdata:
Por cierto, siguiendo el tema "parones", la versión de mega de Xenocrisis, también los tiene, muy bien camuflados pero que , para mí, no le quitan calidad a dicha versión, me quejo más de esta del hilo, entre otras cosas, por qué barata no me a salido, 😅

VempireX escribió:@Dr apocalipsis

🤣🤣🤣

🤣🤣🤣
Mejor así?
No hay nada como picarle al código para optimizar...😼 , te dejo el gatito a modo de fiera,

Te estás coronando, máquina.

Ese hack usa el MSU1 para reproducir la música, dejando libre toda la RAM del SPC para los efectos y las voces.

Buen ridículo te acabas de cascar después de venir perdonando vidas.

Picar código dice el figura.

dr apocalipsis escribió:Buen ridículo te acabas de cascar después de venir perdonando vidas.

¿Dónde están tus excusas para justificar el flickering de los sprites de la serpiente?
¿Y tus ejemplos de menús de SNES con flickering?

El que va de "perdonavidas" seguramente seas tú, "máquina".

riffraff escribió:

dr apocalipsis escribió:Buen ridículo te acabas de cascar después de venir perdonando vidas.

¿Dónde están tus excusas para justificar el flickering de los sprites de la serpiente?
¿Y tus ejemplos de menús de SNES con flickering?

El que va de "perdonavidas" seguramente seas tú, "máquina".

Uf, así mejor. Caretas fuera.

Ni con un bando ni con el otro, buen bingo te estás cascando.

dr apocalipsis escribió:

riffraff escribió:

dr apocalipsis escribió:Te estás coronando, máquina.

Ese hack usa el MSU1 para reproducir la música, dejando libre toda la RAM del SPC para los efectos y las voces.

Buen ridículo te acabas de cascar después de venir perdonando vidas.

¿Dónde están tus excusas para justificar el flickering de los sprites de la serpiente?
¿Y tus ejemplos de menús de SNES con flickering?

El que va de "perdonavidas" seguramente seas tú, "máquina".

Uf, así mejor. Caretas fuera.

Ni con un bando ni con el otro, buen bingo te estás cascando.

Ni bingo ni pollas.

No se trata de "bandos", sino de tratar con respeto al resto de usuarios incluso cuando se equivocan, como tú.